[kungato]

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

[ricardobeat]

> 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.

[debaserab2]

> 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]

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.

[piranha]

> 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/ and look for element `#initial`.

[ricardobeat]

Indeed. Still a clear win!

[tluyben2]

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.

[IggleSniggle]

I’m with you, but I do like applications that can continue to operate seamlessly without a connection or with an intermittent connection. Although for these I would also expect them to persist state across refreshes with IndexDB or similar. Basically, I want my applications to work similarly to a git workflow, with merges and conflict resolution with the server only required when you hit “Save” (but maybe preemptively noticed, depending on workflow).

[krzepah]

Maybe implement authentification properly and store a refresh token that you can use to trigger auth on app load.

[tluyben2]

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]

There is a great article that went uncommented on HN about Architectural Decision Records.

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

[tluyben2]

> Stop crying around on HN and go dev your feature

Not reddit here, people like to talk about and ponder eachother's opinions.

[krzepah]

Honestly I like HN but the constant talk about PWA vs pure HTML apps has became tiresome and unproductive. I haven't seen a single argument that's properly stated about why we shouldn't do them.

Having argument alike "Oh I have to dev that feature therefor X sucks" is not a good enough opinion that i would like to read here neither.

[hliyan]

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]

This site also has almost no state at all per-user.

[7786655]

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.

[wwright]

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.

[recursive]

Any time you vote a comment, that's state as well.

[ric2b]

> 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.

[cuddlecake]

"The performance benefits are evident" is a bit too authoritative to me. Would you mind giving a summary of the performance benefits?

[lr4444lr]

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

[dwheeler]

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]

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.