4 ms·

> 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

by 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.
- fivea 5y ago
  > There is a (high) probability users will close the tab after waiting for over a minute for MBs of JS to download and parse. I'm not sure what leads you to believe that a SPA requires "MBs of JS" to work. I've worked on a popular SPA deployed to multiple regions and with tons of localization data, and the total payload stayed well below 1MB. Plenty of dynamic HTML content, specially images, require far more than that. In fact, this very discussion on HN, a very spartan dynamic HTML page, currently requires over 250kB as it dumps all the threads regardless of whether you read them or not. As a contrast, Reddit's frontpage takes 750kB.
  - _xnmw 5y ago
    Wow, the fact that you compare Reddit to HN, and you consider the Reddit SPA to be "better" means you have a fundamentally different notion of better. For me, Old Reddit and Hacker News load fast, feel snappy and native, and work better in every way, while the new Reddit SPA is sluggish, full of random network errors and bugs that I encounter regularly just clicking around, and takes up a ton of memory/CPU just to browse a discussion site. And Reddit's frontpage size is 1.3 MB according to one check I did which checks the size of all network calls after loading, etc. and that's WITHOUT all the lazy-loaded content below the fold.
    - justsomehnguy 5y ago
      > And Reddit's frontpage size is 1.3 MB Ugh, the two chat scripts are 944KB + 1.30 *MB* alone [0] Full page load (without touching anything at all) is 12.87MB (6.58 on wire) with 273 requests. [0] https://imgur.com/a/bHf9CQb https://imgur.com/a/bHf9CQb
  - southerntofu 5y ago
    > Plenty of dynamic HTML content, specially images, require far more than that. (...) this very discussion on HN, a very spartan dynamic HTML page, currently requires over 250kB There's the difference: HTML-first approach will be able to draw everything using very little resources by the time i've loaded a few hundred kilobytes. With JS bundles i first have to wait for the scripts to load, then the dance of unreliable network-roundtrips starts and can fail in mysterious ways unknown the the browser UI. Images will not prevent the browser from drawing the window, and they can be lazy-loaded if you consider that's better UX (of course the browser can decide to override that setting to respect user preferences). Time to full render is orders of magnitude better on simple HTML/CSS (what browsers were designed to render) than with a crap bundle that's going to trigger network connections and DOM changes (so full page redraws) in mysterious ways. Also, i love when my refresh and back button in the browser UI do what they're supposed to do. I'm not saying it's impossible with an SPA, that's just something most SPAs i stumble upon are completely incapable to respect. I encourage you to run the experiment. Take out an old Pentium 4 with 2G RAM, setup Firefox and in the developer bar (f12) turn on network's throttling. It will not be a realistic simulation as you would need packet loss (which other tools can simulate) but it will certainly help you measure performance and make informed decisions.
midrus 5y ago
> This is not the case with SPAs, LOL. I'm yet to see a single SPA which can tolerate a bad network. You certainly have better tools to do it, but it still takes a ton of effort and nobody does it. So it ends up failing in worse ways because now the application just stalls and you don't even get the standard browser errors/timeouts. Unless SPAs are built as "offline first" I haven't seen a single one which works better than a traditional MVC app in such conditions.
- deleted 5y ago
  [deleted]
- datavirtue 5y ago
  Yeah, have fun building an "offline first" app if your scope is anywhere in excess of Postman.
Ducki 5y ago
What exactly are the "multitude of drawbacks", that basic CRUD pages suffer from?
- tekknik 5y ago
  Im not the OP and not sure about multitude but one problem for a successful app is bandwidth usage from transferring redundant chunks of HTML, and potentially JS and CSS
  - southerntofu 5y ago
    Assets like JS/CSS can be cached, and unless you're doing something very convoluted HTML overhead should be pretty low. I mean HTML was standardized in the 90s when we had <100Kb/s (not KB/s) bandwidth so i understand if you have a "successful app" you're always going to need to deal with scaling, but it's not exactly a problem for most of us and caching reverse proxies are very easy to operate and stable nowadays.
    - tekknik 5y ago
      So you’ve said that you don’t have this problem because your not a successful app? Or are you denying that there’s duplicate HTML, and sometimes JS and CSS being sent? 100k for 100 users is 10mb and bandwidth is one of the easier ways to save costs.
burnished 5y ago
Could you link to some of the stuff that you are mentioning, maybe an interesting article if you remember one offhand? I think what you are saying is controversial due to the other child comments, which is intriguing because I think what you are saying is interesting and I am hoping you might point me to a larger discussion on the topic.
- lwansbrough 5y ago
  Caching via service workers and the app manifest would be two places to start.
bwilliams 5y ago
The advantages you listed are potential advantages but the reality is often different. Those features don't come for free, and given the number of SPA's out in the wild it's rare that functionality like offline mode or gracefully degrading when running into faulty network connections are actually built, let alone maintained. Most of the time SPA's degrade very poorly and instead of breaking they often appear as if they're somewhat working but the site is actually in a broken state and will need a complete refresh to become usable again.
acdha 5y ago
> 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. That's the sales pitch but here's what actually happens for the vast majority of time: the user gets frustrated because after 5 minutes the SPA finishes failing to load and all they have a blank page or, if it's a site they visit so frequently that all of its dependencies tree are still in the browser's cache, they get the UI shell but nothing works. As a bonus, the assumption that the megabytes of JavaScript would manage state often means that core web functionality like the back button or reloading do not work so while a CRUD user would be able to hit reload and get the expected result as soon as their network connection improves, the SPA user will have to start over from the beginning. It is technically possible to build things which work offline but in the real world that doesn't work for most applications for a number of reasons: 1. The app depends on things which need to make network requests — you can give a nicer error page but that's not going to make your users happy. 2. The developers ship updates often enough that cached versions aren't current — e.g. you might have all 50MB of dependencies in the cache but if the user got the HTML referencing different URLs, that doesn't matter. 3. The developers forgot to test that they allow long-term caching or serve-stale on their assets. 4. There's a big difference between being completely offline where the interface status shows down and high latency / packet loss. The most frustrating experience for the users are the latter because things act like they're going to work and if they were doing an activity which changes state it might not be clear whether something succeeded or not. The offline API doesn't work for that and it's almost certain that your SPA doesn't really handle it because: 5. Statistically nobody tests in those degraded conditions so they end up with the Twitter-style SPA where it loads the core of the UI structure but then nothing renders. This is better than a server timeout page only in that it allows you to try to convince the user to be less frustrated. The reason why this is almost always better for server-side rendering comes down to the increased client footprint of an SPA. With an SPA you're depending on an enormous amount of code to load and run before the user sees anything and there's a lot more that can go wrong in ways you didn't handle, which is why it's so common to learn something is an SPA when you get a “successful” blank page. Servers certainly can have problems but most of the moving parts are under your control so you have better visibility and control, and there's no better way to handle degraded conditions than to depend on them less. If the network is slow, trimming your transfer by 1-2 orders of magnitude is going to do more than almost anything else to improve the user experience.

by fivea 5y ago

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.
fivea 5y ago
> There is a (high) probability users will close the tab after waiting for over a minute for MBs of JS to download and parse. I'm not sure what leads you to believe that a SPA requires "MBs of JS" to work. I've worked on a popular SPA deployed to multiple regions and with tons of localization data, and the total payload stayed well below 1MB. Plenty of dynamic HTML content, specially images, require far more than that. In fact, this very discussion on HN, a very spartan dynamic HTML page, currently requires over 250kB as it dumps all the threads regardless of whether you read them or not. As a contrast, Reddit's frontpage takes 750kB.
- _xnmw 5y ago
  Wow, the fact that you compare Reddit to HN, and you consider the Reddit SPA to be "better" means you have a fundamentally different notion of better. For me, Old Reddit and Hacker News load fast, feel snappy and native, and work better in every way, while the new Reddit SPA is sluggish, full of random network errors and bugs that I encounter regularly just clicking around, and takes up a ton of memory/CPU just to browse a discussion site. And Reddit's frontpage size is 1.3 MB according to one check I did which checks the size of all network calls after loading, etc. and that's WITHOUT all the lazy-loaded content below the fold.
  - justsomehnguy 5y ago
    > And Reddit's frontpage size is 1.3 MB Ugh, the two chat scripts are 944KB + 1.30 *MB* alone [0] Full page load (without touching anything at all) is 12.87MB (6.58 on wire) with 273 requests. [0] https://imgur.com/a/bHf9CQb https://imgur.com/a/bHf9CQb
- southerntofu 5y ago
  > Plenty of dynamic HTML content, specially images, require far more than that. (...) this very discussion on HN, a very spartan dynamic HTML page, currently requires over 250kB There's the difference: HTML-first approach will be able to draw everything using very little resources by the time i've loaded a few hundred kilobytes. With JS bundles i first have to wait for the scripts to load, then the dance of unreliable network-roundtrips starts and can fail in mysterious ways unknown the the browser UI. Images will not prevent the browser from drawing the window, and they can be lazy-loaded if you consider that's better UX (of course the browser can decide to override that setting to respect user preferences). Time to full render is orders of magnitude better on simple HTML/CSS (what browsers were designed to render) than with a crap bundle that's going to trigger network connections and DOM changes (so full page redraws) in mysterious ways. Also, i love when my refresh and back button in the browser UI do what they're supposed to do. I'm not saying it's impossible with an SPA, that's just something most SPAs i stumble upon are completely incapable to respect. I encourage you to run the experiment. Take out an old Pentium 4 with 2G RAM, setup Firefox and in the developer bar (f12) turn on network's throttling. It will not be a realistic simulation as you would need packet loss (which other tools can simulate) but it will certainly help you measure performance and make informed decisions.

midrus 5y ago

> This is not the case with SPAs, LOL. I'm yet to see a single SPA which can tolerate a bad network. You certainly have better tools to do it, but it still takes a ton of effort and nobody does it. So it ends up failing in worse ways because now the application just stalls and you don't even get the standard browser errors/timeouts. Unless SPAs are built as "offline first" I haven't seen a single one which works better than a traditional MVC app in such conditions.

deleted 5y ago
[deleted]
datavirtue 5y ago
Yeah, have fun building an "offline first" app if your scope is anywhere in excess of Postman.

Ducki 5y ago

What exactly are the "multitude of drawbacks", that basic CRUD pages suffer from?

tekknik 5y ago
Im not the OP and not sure about multitude but one problem for a successful app is bandwidth usage from transferring redundant chunks of HTML, and potentially JS and CSS
- southerntofu 5y ago
  Assets like JS/CSS can be cached, and unless you're doing something very convoluted HTML overhead should be pretty low. I mean HTML was standardized in the 90s when we had <100Kb/s (not KB/s) bandwidth so i understand if you have a "successful app" you're always going to need to deal with scaling, but it's not exactly a problem for most of us and caching reverse proxies are very easy to operate and stable nowadays.
  - tekknik 5y ago
    So you’ve said that you don’t have this problem because your not a successful app? Or are you denying that there’s duplicate HTML, and sometimes JS and CSS being sent? 100k for 100 users is 10mb and bandwidth is one of the easier ways to save costs.

burnished 5y ago

Could you link to some of the stuff that you are mentioning, maybe an interesting article if you remember one offhand? I think what you are saying is controversial due to the other child comments, which is intriguing because I think what you are saying is interesting and I am hoping you might point me to a larger discussion on the topic.

lwansbrough 5y ago
Caching via service workers and the app manifest would be two places to start.

bwilliams 5y ago

The advantages you listed are potential advantages but the reality is often different. Those features don't come for free, and given the number of SPA's out in the wild it's rare that functionality like offline mode or gracefully degrading when running into faulty network connections are actually built, let alone maintained. Most of the time SPA's degrade very poorly and instead of breaking they often appear as if they're somewhat working but the site is actually in a broken state and will need a complete refresh to become usable again.

acdha 5y ago

> 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. That's the sales pitch but here's what actually happens for the vast majority of time: the user gets frustrated because after 5 minutes the SPA finishes failing to load and all they have a blank page or, if it's a site they visit so frequently that all of its dependencies tree are still in the browser's cache, they get the UI shell but nothing works. As a bonus, the assumption that the megabytes of JavaScript would manage state often means that core web functionality like the back button or reloading do not work so while a CRUD user would be able to hit reload and get the expected result as soon as their network connection improves, the SPA user will have to start over from the beginning. It is technically possible to build things which work offline but in the real world that doesn't work for most applications for a number of reasons: 1. The app depends on things which need to make network requests — you can give a nicer error page but that's not going to make your users happy. 2. The developers ship updates often enough that cached versions aren't current — e.g. you might have all 50MB of dependencies in the cache but if the user got the HTML referencing different URLs, that doesn't matter. 3. The developers forgot to test that they allow long-term caching or serve-stale on their assets. 4. There's a big difference between being completely offline where the interface status shows down and high latency / packet loss. The most frustrating experience for the users are the latter because things act like they're going to work and if they were doing an activity which changes state it might not be clear whether something succeeded or not. The offline API doesn't work for that and it's almost certain that your SPA doesn't really handle it because: 5. Statistically nobody tests in those degraded conditions so they end up with the Twitter-style SPA where it loads the core of the UI structure but then nothing renders. This is better than a server timeout page only in that it allows you to try to convince the user to be less frustrated. The reason why this is almost always better for server-side rendering comes down to the increased client footprint of an SPA. With an SPA you're depending on an enormous amount of code to load and run before the user sees anything and there's a lot more that can go wrong in ways you didn't handle, which is why it's so common to learn something is an SPA when you get a “successful” blank page. Servers certainly can have problems but most of the moving parts are under your control so you have better visibility and control, and there's no better way to handle degraded conditions than to depend on them less. If the network is slow, trimming your transfer by 1-2 orders of magnitude is going to do more than almost anything else to improve the user experience.