6 ms·

And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). It's really the best way to do things: SPAs are gre

And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). It's really the best way to do things: SPAs are great for applications, but for 99% of websites server-side rendering only has advantages.

Spivak 5y ago
Wait what? Other than "the client blocks JS" which is niche beyond niche the SPA is the one that actually performs better with a spotty network. Fully offline or "occasionally connected" is half the reason to use an SPA. Just as an example once downloaded FB messenger is fully functional over an unreliable network.
- marcosdumay 5y ago
  Hum... I have never seen a SPA perform well with a spotty network. Yeah, I get what you are trying to get, that an SPA can retry failures, prioritize resources better, reload less data... They just never do that competently, as it is a shitload of work, and the "once downloaded" part is irrelevant, because people only ever load a couple of pages on most sites visits.
- southerntofu 5y ago
  Did you try it? Try with 256Kb/s and 20% packet loss (and if your networking tooling allows it, bursts of >1s downtime every 20s) and tell me which one performs better. Yes that's actual conditions in which many people access the Internet in 2021 whether it's on cellular or crappy xDSL. I've yet to see a single SPA that can deal with such conditions, while native HTML/CSS will work like a breeze in any web browser. For bonus points, browser UI can tell you which requests take a long time and/or refresh any page while maintaining a cache, something most SPAs are really bad at doing, and you get SEO/interoperability for free due to your markup being a curl call away from any client.
fivea 5y ago
> And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). What? No. Not at all. If you're behind a subpar network, your dynamic HTML web app does not load/refresh/update at all, and your users start to get frustrated because your crappy webpage is broken and fails to even do the most basic things. This is not the case with SPAs, and some of the most pressing problems they solve: perceived performance, resilience to faulty network connections, and overall improved UX. Let's put it this way: with SPAs you can design your app to work even without a working network connection. That's how resilient SPAs are to networking issues. How do you pull that off with dynamic HTML? > but for 99% of websites server-side rendering only has advantages. No, not really. Unless you cherry-pick what goes into the 99%, even basic CRUD, form-driven pages the dynamic HTML way suffers from a multitude of drawbacks that are no longer issues in SPAs, both technical and organizational.
- scns 5y ago
  > If you're behind a subpar network There is a (high) probability users will close the tab after waiting for over a minute for MBs of JS to download and parse.
  - cerved 5y ago
    in an SPA, that's cached, so not the second time
    - acdha 5y ago
      Have you measured this carefully? All of yours users will notice it on the first visit, so you need to think about that first impression but it’s also rarely the case that people load your page so frequently that everything stays in the cache forever. Mobile devices have small caches which purge more frequently than most developers think and that’s also true of CDN nodes, and continuous deployment acts as a ceiling for long-term caching. When I’ve measured this for real users on moderately busy sites (6 figure daily users, not Google-scale) the reported first page load times tracked the cold cache times for most users (70+%) even for people who’d visited before. If they were geographically clustered (news story, etc.) the cache hits on CDN nodes would be high but you couldn’t count on that.

Spivak 5y ago

Wait what? Other than "the client blocks JS" which is niche beyond niche the SPA is the one that actually performs better with a spotty network. Fully offline or "occasionally connected" is half the reason to use an SPA. Just as an example once downloaded FB messenger is fully functional over an unreliable network.

marcosdumay 5y ago
Hum... I have never seen a SPA perform well with a spotty network. Yeah, I get what you are trying to get, that an SPA can retry failures, prioritize resources better, reload less data... They just never do that competently, as it is a shitload of work, and the "once downloaded" part is irrelevant, because people only ever load a couple of pages on most sites visits.
southerntofu 5y ago
Did you try it? Try with 256Kb/s and 20% packet loss (and if your networking tooling allows it, bursts of >1s downtime every 20s) and tell me which one performs better. Yes that's actual conditions in which many people access the Internet in 2021 whether it's on cellular or crappy xDSL. I've yet to see a single SPA that can deal with such conditions, while native HTML/CSS will work like a breeze in any web browser. For bonus points, browser UI can tell you which requests take a long time and/or refresh any page while maintaining a cache, something most SPAs are really bad at doing, and you get SEO/interoperability for free due to your markup being a curl call away from any client.

fivea 5y ago

> And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). What? No. Not at all. If you're behind a subpar network, your dynamic HTML web app does not load/refresh/update at all, and your users start to get frustrated because your crappy webpage is broken and fails to even do the most basic things. This is not the case with SPAs, and some of the most pressing problems they solve: perceived performance, resilience to faulty network connections, and overall improved UX. Let's put it this way: with SPAs you can design your app to work even without a working network connection. That's how resilient SPAs are to networking issues. How do you pull that off with dynamic HTML? > but for 99% of websites server-side rendering only has advantages. No, not really. Unless you cherry-pick what goes into the 99%, even basic CRUD, form-driven pages the dynamic HTML way suffers from a multitude of drawbacks that are no longer issues in SPAs, both technical and organizational.

scns 5y ago
> If you're behind a subpar network There is a (high) probability users will close the tab after waiting for over a minute for MBs of JS to download and parse.
- cerved 5y ago
  in an SPA, that's cached, so not the second time
  - acdha 5y ago
    Have you measured this carefully? All of yours users will notice it on the first visit, so you need to think about that first impression but it’s also rarely the case that people load your page so frequently that everything stays in the cache forever. Mobile devices have small caches which purge more frequently than most developers think and that’s also true of CDN nodes, and continuous deployment acts as a ceiling for long-term caching. When I’ve measured this for real users on moderately busy sites (6 figure daily users, not Google-scale) the reported first page load times tracked the cold cache times for most users (70+%) even for people who’d visited before. If they were geographically clustered (news story, etc.) the cache hits on CDN nodes would be high but you couldn’t count on that.