Hacker News Reader

Comment by GordonS | Hacker News Reader

Another old'ish guy here, and I feel the same way.

I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.

In SSR (Server-Side Rendered) projects (typically ASP.NET Core for me nowadays, but I've used others too), things are just so much simpler, with fewer moving parts. A sprinkling of JavaScript is all that's needed, and even then a lot is reusable between projects. And now IE has finally died, jQuery is no longer needed, and browser support for ES6 is good, even writing JavaScript is less miserable than it used to be.

View on HN

Is it not simpler because the applications themselves are simpler? I mean, when you say that client frameworks like angular and svelte have their place with complex UX/UI interactions.

Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.

> your domain is simpler

This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.

I use miro and figma as examples of products that would be extremely hard to build as a traditional SSR app.

> your domain is simpler.

So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.

OP said:

> My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.

Therefore, it follows that OP finds SSR is simpler, but only because OP only uses SSR for simple problems.

Non-complex UI/UX != Simple problems. Also, most problems people have don't need complex UI/UX.

Having to refresh the page every time you make a change or open a modal is a terrible user experience.

Watching widgets/components freeze after an interaction because of a poorly-handled race condition in the JavaScript, dropped or mis-handled/scheduled async requests, and inconsistent cross-component state management isn't any better. It's arguably worse, because now the user has to guess as to whether something is wrong with the application or not and then refresh anyway.

What makes it a terrible user experience?

https://sr.ht/ is faster than most SPAs I know and it refreshes the page a lot

It's not faster despite being in WiFi

This is trivial with a sprinkling of JavaScript - our pages do update as required after form POSTs, for example.

Nonsense :)

Users don't really know what they want, and I'd wager that most are willing to accept a page refresh if they understood the immense productivity gains that developers like achieve, for a worse "user experience".

> Users don't really know what they want

Users do not care about "immense developer productivity"

This is a false-dichotomy/straw man. The conversation is about a javascript-heavy approach being overkill. I haven’t seen many arguing for noscript here.

Implementing a form that autosubmits and updates an element takes very little js.

You can replace a chunk of innerHTML faster than a full page reload, using a near-trivial piece of vanilla JS.

But a full page reload also clears out memory "leaks", old state accidentally kept around in caches, clinging to DOM nodes discarded long ago, but themselves still referenced by an old copy of a data structure, etc. If you go for a SPA, or even something in between, suddenly being careful about your data structures becomes a major concern to long-term app use, carrying a whole new category of debugging.

Reply on news.ycombinator.com