5 ms·

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 capabi

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.

tonyedgecombe 3y ago
>Better UX for slow networks Yet the reality seems to be very poor UX from SPA's on a slow or intermittent connection.
leosanchez 3y ago
> 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
- jauntywundrkind 3y ago
  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.
  - zelphirkalt 3y ago
    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.
    - ivan_gammel 3y ago
      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.
    - jauntywundrkind 3y ago
      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.
- jonfw 3y ago
  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
filleokus 3y ago
> 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.
- ivan_gammel 3y ago
  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.
- lelanthran 3y ago
  > 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.
  - filleokus 3y ago
    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.
eddd-ddde 3y ago
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.
- ivan_gammel 3y ago
  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.
  - rokkitmensch 3y ago
    "They just haven't done SPA right enough!"
    - ivan_gammel 3y ago
      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.
simonhamp 3y ago
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.
treyd 3y ago
> 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) > 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.
infamia 3y ago
> 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.
- ivan_gammel 3y ago
  > 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.
  - infamia 3y ago
    > 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.
acdha 3y ago
> 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.
- rokkitmensch 3y ago
  Amen. LCP and TTI are the only things that matter. Fix your render loops, kids.

tonyedgecombe 3y ago

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

leosanchez 3y ago

> 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

jauntywundrkind 3y ago
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.
- zelphirkalt 3y ago
  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.
  - ivan_gammel 3y ago
    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.
  - jauntywundrkind 3y ago
    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.
jonfw 3y ago
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

filleokus 3y ago

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

ivan_gammel 3y ago
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.
lelanthran 3y ago
> 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.
- filleokus 3y ago
  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.

eddd-ddde 3y ago

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.

ivan_gammel 3y ago
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.
- rokkitmensch 3y ago
  "They just haven't done SPA right enough!"
  - ivan_gammel 3y ago
    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.

simonhamp 3y ago

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.

treyd 3y ago

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

infamia 3y ago

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

ivan_gammel 3y ago
> 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.
- infamia 3y ago
  > 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.

acdha 3y ago

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

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