Hacker News Reader

Comment by kungato | Hacker News Reader

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

View on HN

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

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

Indeed. Still a clear win!

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

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.

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.

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

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.

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

> Stop crying around on HN and go dev your feature

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

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.

People implement different ways of doing things all the time; they have to get ideas somewhere and they also have to see their work is worthwhile for others. You might or not like the current state; you just suck it up, I get that, we all do. We also can complain and try to do something about the things we do not like. Every new software is created for some reason; money opportunity, interest, scratching an itch or trying to get rid of pet peeves. Nothing wrong with that and personally I like to read about people’s issues with software; it keeps me confident that ‘this’ is not ‘it’, because if it was, I would become a full-time pizza chef. In the meanwhile, obviously I suck it up and build things; I can still hope for better. For me personally, Phoenix and Blazor(server and maybe client) show that I am not the only one annoyed by the stuff ‘everyone uses’.

Noone (well...) sits behind HN crying while doing nothing; but it is a platform where people go who actually make the changes or at least talk about them without dismissing them with ‘just use node/react and stfu’ or, almost the opposite, ‘just use wordpress and stfu’ like much of reddit and other programming forums (as far as there are).

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

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.

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

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.

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

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.

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

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

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

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.

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.

Reply on news.ycombinator.com