Hacker News Reader

Comment by ivan_gammel | Hacker News Reader

Client-side rendering has a lot of benefits not mentioned in the article.

1. Adaptive design: it’s easier to adjust user experience to the client device capabilities. SPA frameworks take the job of ensuring browser compatibility, but it’s not just it.

2. Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page headers, footers and other common parts).

3. Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect. SPA can auto-retry, just showing the spinning wheel longer. Browser will show the timeout page, and who knows if the backend can correctly recover on refresh.

View on HN

> Less traffic in data-rich apps

Hmm. Of course it can be true in certain circumstances, but I would be surprised if on average the (compressed) size of the js bundle + subsequent JSON API request is smaller than html * the number of pages visited in a session.

Even if you are careful (and most sites are definitely not) overfetching JSON can easily happen due to API's not delivering exactly what you need etc.

Plus, in many circumstances both js bundle + json or HTML text gets dwarfed by images or other media.

Imagine rendering some complex data model to image on server vs downloading json and rendering it on client. Yes, SVG does exist, but it doesn’t cover all cases.

> Even if you are careful (and most sites are definitely not) overfetching JSON can easily happen due to API's not delivering exactly what you need etc.

I've seen the term BFFE used: Backend for Front-end, which is where the backend is a set of APIs, and for those specialised requests that the front-end makes, endpoints are created on (maybe) a new domain/machine/whatever that simply makes the correct Backend calls, aggregates and consolidates the data, and then serves it to the front-end.

It makes a lot of sense for the front-end to be able to create a single endpoint that does 4+ requests and some data manipulation rather than for front-end to wring their hands and continue making 4+ requests each time they need that specific data.

Yeah, and for a while (perhaps still?) grapqhl solved some of these issues as well. People did (do?) "schema stitching" to essentially have a BFF without really writing that much code.

I have a really bad network, SPAs are consistently worse in UX than a regular site. There are tons of SPAs that won't even show me a loading indicator when navigating, a regular site will have the browser spinner telling me to wait.

That’s not an argument against SPAs, that’s an argument for investing more time on product discovery stage to understand that this is actually a requirement. When implemented with relatively small effort, it does have better UX.

"They just haven't done SPA right enough!"

Yes. Engineers are as guilty of enshittification as managers and shareholders. If „good enough“ replaces „well-built“, no solution choice will save you. The very same engineers will build a backend that sucks.

> Better UX for slow networks

Don't you think the case can be made against SPA's w.r.t slow networks ?

Angular, react add hundreds of KB's to frontend bundle which give bad UX especially in slow networks

But then after 20s loading or whatever, it's cached and your experience every moment thereafter & if you return later is speedier.

If the app has optimistic updates, actions may even feel instant.

If your app really cares, it'll have an offline mode/be local-first. Then you you pretty much need an SPA or some kind of heavier front end.

After 20s ... you have lost 50% of your visitors, because they think the damn thing is never going to finish loading on their connection and you will have triggered connection loss anxiety on multiple levels.

Also this is assuming, that one does not want to take all the things of that website and burn them after use, which is not a safe assumption to make on most websites, considering all the ads and trackers on today's typical websites.

An offline still working app sounds great. Unfortunately very few aspire to reach that point. Most already break to various degrees when you hit the back button.

Not every frontend is a marketing website where conversion is a concern. Marketing websites aren’t apps anyway, they shouldn’t have any backend - SSG is better than SSR for them.

Normally I'd agree about 20s being too long.

But I'm specifically talking about users on slow links. They often know they don't have a first class connection out, and have established a different set of expectations.

If your site is actually good enough to be one the users return to (and who here wants to build a site where that's not the case?), they all appreciate the site loading very fast the next time.

once it's cached though, loading new pages or new data is trivial.

It really depends on the use case- if I'm navigating my banking website, I would prefer a longer load time up front if it made it navigating between accounts really fast. If I'm checking my power bill, I'm probably only going to view one page so I just want it loaded ASAP

> Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page headers, footers and other common parts).

This statement is way too overly broad. JSON is terrible for tabular data, since you have to include the field names in each row. HTML will be much better for data heavy sites in this case. Also, as others have mentioned, you still need to download and process the JS needed to display the data (libraries, likely styli ng, etc.).

> Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect.

1. Offline and autoconnect are lovely ideas, but most js devs don't care enough/aren't permitted the time to write with this sort of resilency in mind. In practice it isn't really an advantage.

2. When a SPA does fail, it is often worse than a back end framework. The browser will tell you the request failed and a very general reason why. Whether it worked or not is abundantly clear. Most SPAs just sit there and silently die, while you stare at the screen waiting to see if it will actually do something.

3. Most of the mobile devices you're talking aren't that powerful, so loading them down with a bunch of JS to run, makes for a really bad for UX.

> JSON is terrible for tabular data

Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead.

>When a SPA does fail, it is often worse than a back end framework.

This is not an argument against SPA, it’s an argument to invest in UX. When done right, SPA and native clients do deliver better UX than SSR/generic browser. The effort to achieve that is not huge, in fact this behavior can be built as a reusable component.

> Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead.

Now you hydration, your JS to run, and a custom serialization/deserialization format (and a custom parser) to maintain.

> This is not an argument against SPA, it’s an argument to invest in UX. When done right, SPA and native clients do deliver better UX than SSR/generic browser. The effort to achieve that is not huge, in fact this behavior can be built as a reusable component.

We're well over a decade into SPAs and we're still seeing these problems/errors. I routinely see SPAs keeling over without any feedback built by large, richly resourced. The tool has something to do with it if so many different people and organizations are failing.

> This is not an argument against SPA, it’s an argument to invest in UX.

ZIRP-era thinking. Gotta get by with less of everything now, unless you're a growth/hyperscaler snowflake, in which case the advice doesn't apply to us common-or-garden engineering shops.

A lot of UX gains can be achieved in a lean way with minimal effort. It is unfortunate, that the state of the industry is such, that half of „senior“ engineers only mastered CRUD and 90% of engineering and product managers are just random people without essential knowledge or skills required for their jobs. ZIRP era thinking is to assume that money will and only money can solve the problem of building a decent product.

Time is the other variable!

> HTML will be much better for data heavy sites in this case

I've never seen HTML be smaller than json for data representation. For any kind of data. Ever.

[Snip SPAs reasons that aren't inherent to SPA]

> Most of the mobile devices you're talking aren't that powerful, so loading them down with a bunch of JS to run, makes for a really bad for UX.

Even mobile CPUs are more powerful than your average cloud vCPU. They get refreshed much more frequently if for no other reason than the batteries give out.

That doesn't even take into consideration the fact that the server is rendering x requests vs the client's one.

Any spend on server hardware to make it fast will never make up for the network latency vs a well built SPA that can avoid refetching some data again entirely.

Page one, server render is faster. Every subsequent navigation will favor a well built SPA.

> well-built

hell of a caveat you casually slipped in there, comrade.

> 2. Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page headers, footers and other common parts).

I’ve very rarely seen this not be significantly skewed in the other direction. The stuff you mentioned is tiny and compresses well, and unlike the many megabytes of JavaScript almost all SPAs ship it doesn’t block rendering.

> 3. Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect. SPA can auto-retry,

SPAs are far less likely to get to the point where they can display that spinner on a marginal network. Any time I have had coverage, JavaScript-heavy sites are notably the worst experience especially because unlike SSR a reload only works if you have the 5% of SPA developers who correctly implemented state handling.

Amen. LCP and TTI are the only things that matter. Fix your render loops, kids.

> Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect. SPA can auto-retry, just showing the spinning wheel longer. Browser will show the timeout page, and who knows if the backend can correctly recover on refresh.

It's more often the converse in my experience. If you have a slow or flaky connection, making many API requests to get all the data your SPA needs to fulfill an interaction yields worse UX than just asking a server to process it all and give back a final result for the interaction. The round trips are the killer there.

>Better UX for slow networks

Yet the reality seems to be very poor UX from SPA's on a slow or intermittent connection.

All rendering, ultimately, is client-side. That's inescapable.

So whatever mechanisms you choose to make adaptive designs, lower your throughput and account for slow networks can be done without an SPA.

Reply on news.ycombinator.com