5 ms·

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full ht

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

hliyan 6y ago
Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.
- wwright 6y ago
  This site also has almost no state at all per-user.
  - 7786655 6y ago
    Every time you collapse a thread, that's saved on the server. Then, if you return to the page, it will render those threads collapsed. So that's a decent amount of state.
    - recursive 6y ago
      Any time you vote a comment, that's state as well.
    - wwright 6y ago
      I disagree. It’s Boolean and flat (there is neither sequential nor nested logic around the state). It does recurse for each sub thread, but only in the case where there is no state. There’s also no business logic built around it, only display logic. It also is updated from exactly one location in the application. That said, it’s a very simple and effective design. It’s an excellent program. But it’s not a fair comparison against other applications which, for one reason or another, need significantly more advanced state.
- cuddlecake 6y ago
  "The performance benefits are evident" is a bit too authoritative to me. Would you mind giving a summary of the performance benefits?
- ric2b 6y ago
  > The performance benefits are evident. I mean, this website only loads a very small amount of text and has barely any user state besides a list of comments and posts. I would hope that it loads quickly.
ricardobeat 6y ago
> return the full html every time The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting. Note that with an SPA you need to send templates (in the js bundle) + data (json api) to the client, which by definition will be at least as large as static HTML for the same content: HTML is nothing more than the template and content already baked in. In practice the JS templates are much larger due to containing the entire application logic + compiler overhead. Finally, the benefit of having the templates already loaded is only realized over longer timespans, when probably half of your users are coming in with an empty cache anyway.
- piranha 6y ago
  > The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting. Mostly because of initial data. Index page is still on react, so you can go on https://kasta.ua/ https://kasta.ua/ and look for element `#initial`.
  - ricardobeat 6y ago
    Indeed. Still a clear win!
- debaserab2 6y ago
  > which by definition will be at least as large as static HTML for the same content Not really by definition - tables rendered on the server side are a good example of a payload that can easily be larger than template + dataset.
  - acdha 6y ago
    Transfer compression will usually take that down to the point where it's negligible. By the time you're talking enough data for this to matter, things like pagination will likely be far more important.
lr4444lr 6y ago
Because the user can't be trusted - on several levels.
- dwheeler 6y ago
  Treating 10KB of JavaScript as equal to 10KB of HTML is a big mistake. They transition over a network in the same amount of time, but HTML is far faster to process. Websites with large HTML sizes often display far faster than the same information that use JavaScript client-side frameworks. Often the framework is still trying to figure out which way is up, while the HTML version is already being displayed. It's a trade-off that isn't discussed enough.
  - withinboredom 6y ago
    I wrote a game engine with a DSL that renders as detail/summary html blocks. It wasn't hard to end up with a page that was hundreds (or thousands) of megabytes. Any given browser really had no issue until it was over several hundred megabytes.
tluyben2 6y ago
I have not seen a good case of this. Can you point out one? Managing state on the server is trivial; sessions and database and that is it. How does handling on the client work? Well it works if you double up on the server; it is a crime when there is some SPA that manages state client side; something goes wrong and it is stuck, press reload, state gone; login page. It is annoying to me as dev, it is creating serious anger for people who do not understand this. They press f5 and are logged out. Wtf. Or their shopping cart is now empty. So if you want to fix that you have to handle state on the client and then sync with the server; how is that better than just having it on the server? I am a backend dev but I see more and more of my frontend colleagues move stuff to the server: it is just easier to reason about imho. Sending over generated pieces of html that update divs I find a quite nice compromise: not the complexity while having updates without refresh. Intercooler sounds like that.
- krzepah 6y ago
  Maybe implement authentification properly and store a refresh token that you can use to trigger auth on app load.
  - tluyben2 6y ago
    It is absolutely fixable, but the extra complexity invites people not to fix it while on the server it works as default. I have integrated some very popular backends the past months and their portals are all SPAs and they all have this issue; hit refresh and you lost where you are, thrown back to login.
    - krzepah 6y ago
      There is a great article that went uncommented on HN about Architectural Decision Records. https://github.com/joelparkerhenderson/architecture_decision_record https://github.com/joelparkerhenderson/architecture_decision... The simplest of them include "consequences" of architectural decision. For PWA these include the development of that kind of features. Now to be absolutely honest. I prefer having a dedicated back-end that does one thing well and a front end that does one thing well. Even if I have to put in extra effort with few features just to have my source-code more dedicated and therefore cleaner to work with. The thing is that PWA not only included the front-end dev, they also reduced the complexity of back-end. And that's a huge win I'd pay with these kind of features happily. Stop crying around on HN and go dev your feature

hliyan 6y ago

Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.

wwright 6y ago
This site also has almost no state at all per-user.
- 7786655 6y ago
  Every time you collapse a thread, that's saved on the server. Then, if you return to the page, it will render those threads collapsed. So that's a decent amount of state.
  - recursive 6y ago
    Any time you vote a comment, that's state as well.
  - wwright 6y ago
    I disagree. It’s Boolean and flat (there is neither sequential nor nested logic around the state). It does recurse for each sub thread, but only in the case where there is no state. There’s also no business logic built around it, only display logic. It also is updated from exactly one location in the application. That said, it’s a very simple and effective design. It’s an excellent program. But it’s not a fair comparison against other applications which, for one reason or another, need significantly more advanced state.
cuddlecake 6y ago
"The performance benefits are evident" is a bit too authoritative to me. Would you mind giving a summary of the performance benefits?
ric2b 6y ago
> The performance benefits are evident. I mean, this website only loads a very small amount of text and has barely any user state besides a list of comments and posts. I would hope that it loads quickly.

ricardobeat 6y ago

> return the full html every time The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting. Note that with an SPA you need to send templates (in the js bundle) + data (json api) to the client, which by definition will be at least as large as static HTML for the same content: HTML is nothing more than the template and content already baked in. In practice the JS templates are much larger due to containing the entire application logic + compiler overhead. Finally, the benefit of having the templates already loaded is only realized over longer timespans, when probably half of your users are coming in with an empty cache anyway.

piranha 6y ago
> The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting. Mostly because of initial data. Index page is still on react, so you can go on https://kasta.ua/ https://kasta.ua/ and look for element `#initial`.
- ricardobeat 6y ago
  Indeed. Still a clear win!
debaserab2 6y ago
> which by definition will be at least as large as static HTML for the same content Not really by definition - tables rendered on the server side are a good example of a payload that can easily be larger than template + dataset.
- acdha 6y ago
  Transfer compression will usually take that down to the point where it's negligible. By the time you're talking enough data for this to matter, things like pagination will likely be far more important.

lr4444lr 6y ago

Because the user can't be trusted - on several levels.

dwheeler 6y ago
Treating 10KB of JavaScript as equal to 10KB of HTML is a big mistake. They transition over a network in the same amount of time, but HTML is far faster to process. Websites with large HTML sizes often display far faster than the same information that use JavaScript client-side frameworks. Often the framework is still trying to figure out which way is up, while the HTML version is already being displayed. It's a trade-off that isn't discussed enough.
- withinboredom 6y ago
  I wrote a game engine with a DSL that renders as detail/summary html blocks. It wasn't hard to end up with a page that was hundreds (or thousands) of megabytes. Any given browser really had no issue until it was over several hundred megabytes.

tluyben2 6y ago

I have not seen a good case of this. Can you point out one? Managing state on the server is trivial; sessions and database and that is it. How does handling on the client work? Well it works if you double up on the server; it is a crime when there is some SPA that manages state client side; something goes wrong and it is stuck, press reload, state gone; login page. It is annoying to me as dev, it is creating serious anger for people who do not understand this. They press f5 and are logged out. Wtf. Or their shopping cart is now empty. So if you want to fix that you have to handle state on the client and then sync with the server; how is that better than just having it on the server? I am a backend dev but I see more and more of my frontend colleagues move stuff to the server: it is just easier to reason about imho. Sending over generated pieces of html that update divs I find a quite nice compromise: not the complexity while having updates without refresh. Intercooler sounds like that.

krzepah 6y ago
Maybe implement authentification properly and store a refresh token that you can use to trigger auth on app load.
- tluyben2 6y ago
  It is absolutely fixable, but the extra complexity invites people not to fix it while on the server it works as default. I have integrated some very popular backends the past months and their portals are all SPAs and they all have this issue; hit refresh and you lost where you are, thrown back to login.
  - krzepah 6y ago
    There is a great article that went uncommented on HN about Architectural Decision Records. https://github.com/joelparkerhenderson/architecture_decision_record https://github.com/joelparkerhenderson/architecture_decision... The simplest of them include "consequences" of architectural decision. For PWA these include the development of that kind of features. Now to be absolutely honest. I prefer having a dedicated back-end that does one thing well and a front end that does one thing well. Even if I have to put in extra effort with few features just to have my source-code more dedicated and therefore cleaner to work with. The thing is that PWA not only included the front-end dev, they also reduced the complexity of back-end. And that's a huge win I'd pay with these kind of features happily. Stop crying around on HN and go dev your feature