7 ms·

We are soon coming full circle when this generation's programmers realize they can render html templates server-side.

RedShift1 5y ago
But there is something to be said for SPAs and slow connections. All the HTML and JS code is loaded beforehand and afterwards only raw data is exchanged. If the API calls can be limited to one call per user action/page visit, the experience would be better because only some API data has to be transferred instead of an entire HTML page. So your initial page load would be slow because of all the HTML and JS, but afterwards it should be faster compared to having server side rendered pages.
- handrous 5y ago
  I very rarely see a "Web App" that's faster due to this. Take Gmail: plain-HTML gmail transfers and renders a whole page faster than full-fat Gmail does most of the things it does, which involve merely "some API data". The activity/loading indicators on normal Gmail display longer than the full-page load on plain-HTML gmail. This had some validity in the early days of AJAX when common practice was to respond with HTML fragments and it was mostly just a work-around for Frames not being very good at a bunch of things they should have been good at. These days, not so much.
  - zozbot234 5y ago
    Makes sense. Roundtrips will kill you on slow connections, and the average SPA does lots of back-and-forth roundtrips. Then the JS code has to tweak hundreds or thousands of DOM nodes in a completely serial fashion to reflect the new data. Much faster in practice to either download or generate (preferably via WASM) a single chunk of raw HTML and let the browser rerender it natively.
    - handrous 5y ago
      It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies allocated, now, depending on how the parsing works), modify that for whatever your in-browser data store is, and/or copy it in there, or copy it to "local state", or whatever (three copies), render the data to the shadow DOM (four copies), render the shadow DOM to the real DOM (five copies). Some of those stages very likely hide even more allocations of memory to hold the same data, as it's transformed and moved around. Lots of library or pattern choices can add more. It adds up.
      - wonnage 5y ago
        Especially with graphql being the new hotness I wonder if it's time to replace JSON with a binary format like Thrift. The old argument was that REST+JSON was simple and easy to debug but that goes out the window with GQL anyway. JSON is just a terrible fit for GQL schemas. I regularly deal with metadata enum fields that are repeatedly serialized causing massive bloat. Sure it gets gzipped away, but you still have all those copies after decompression and parsing.
        RedShift1 5y ago
        If you were sending HTML those copies and parsing would be there anyway?
      - Dylan16807 5y ago
        Even so, if we look at gmail all the data needed for the email list is 20-100KB. The bloat is caused by bad design, not the extra copies.
        pdimitar 5y ago
        When 99% of all SPAs I ever used are that painfully slow (sometimes even on 4G) then obviously that way of work encourages people to make bad design. So we should uproot the problem and not dance around it.
    - toast0 5y ago
      It really depends on both latency and bandwidth. A reasonable POTS modem does ok on latency, but bad on bandwidth. So roundtrip is fine until you send too much data (which is real easy, modern initial segment limit of 10 combined with a 1500 mtu is more than a second of download buffer). If you kept the data small, many round trips would be okish. On the other hand, traditional geosynchronous satellite always has terrible latency, so many round trips is bad regardless of the data size... One big load would be a lot better there.
      - giantrobot 5y ago
        POTS modems don't do great on latency either. I never managed under about a quarter second latency on dial-up. The first hop (your modem'd DAC and the ISP modem's ADC) was usually around 75-100ms all by itself. So even today with pretty fast networks (compared to the heyday of modems) you're easily looking at base latency of a quarter second.
        icedchai 5y ago
        Modem latency was crap. That was another reason a 64K single channel ISDN connection felt so much faster, even though the bandwidth wasn't that much more. ISDN latency was wayyy better since it was digital: 10 to 20ms vs 200ms minimum with an analog modem. Some early ISPs I worked with started with 56K leased lines. The latency there was like night-and-day compared to a 56k modem.
        giantrobot 5y ago
        My first experience with an ISDN connection was mind blowing. I had only ever used analog modems prior. So I'm just expecting faster downloads for large files and pages would load faster. It was a 64k line so I was expecting it to be twice as my modem at home. Web pages just appeared (modulo Netscape connection limitations). A fresh page load felt as fast as a cached page load on my analog modem. It was nuts. It was most noticeable in a handful of games of Quake I played. I got to experience the joy of being a Low Ping Bastard and actually landing a few hits on people.
    - swiley 5y ago
      They also handle errors by having the user reload the page which means everything starts over. My experience growing up is that you don't notice the issues on sane pages written by hobbyists/professors/researchers and then you go to something built by google and everything falls apart.
  - RedShift1 5y ago
    It only works if the webapp can keep its calls limited to 1 per page/user action. Lots of webapps make multiple roundtrips (additional fetches triggered by earlier requests so they can't be done in parallel) making it slow even on fast connections (looking at you Quickbooks Time).
    - robertlagrant 5y ago
      This is exactly why BFFs exist.
      - RedShift1 5y ago
        What's a BFF?
        robertlagrant 5y ago
        https://samnewman.io/patterns/architectural/bff/ https://samnewman.io/patterns/architectural/bff/
- doliveira 5y ago
  As someone who has lived with actual slow connection and budget phones, I don't think I've ever seen this promise fulfilled. It should work, but it's never so in practice.
- masklinn 5y ago
  There really is not. SPAs generally means tons more assets being loaded and hard errors on on unreliable connections. On a web page, missing a bit of the page at the end is not an issue, you might have somewhat broken content but that's not a deal-breaker. With an SPA, an incompletely loaded API call is just a complete waste of the transferred bytes. And slow connections also tend to have much larger latencies. Care to guess what's an issue on an SPA which keeps firing API calls for every interaction? > So your initial page load would be slow because of all the HTML and JS, but afterwards it should be faster compared to having server side rendered pages. The actual effect is that the initial page load is so slow you just give up, and if you have not, afterwards it's completely unreliable. Seriously, try browsing the "modern web" and SPAs with something like a 1024 DSL with 100ms latency and 5% packet loss, it's just hell. And it's the sort of connections you can absolutely find in rural places.
  - RedShift1 5y ago
    Won't loading an entire HTML page be just as bad on such a connection? There's a lot more data to transfer.
    - misnome 5y ago
      > On a web page, missing a bit of the page at the end is not an issue, you might have somewhat broken content but that's not a deal-breaker - the argument is that most of what you probably want is better than nothing. Although I can imagine sites thus prioritising ads even more…
    - ratww 5y ago
      Not at all, unless there is an absurd amount of content on the page that is unrelated to the data being fetched (like title, footer, sidebar). An HTML-table, for example, is in the same ballpark size-wise as a JSON representation of the same data. And that's without taking into account the fact the JSON can potentially carry more information than necessary. Facebook is an example of a website where there is such an absurd amount of content that's not the focus of the page: the sidebars, the recommendations, the friend list of the chat, the trends, the ads. It sorta makes sense for them to have an SPA (although let's be frank: most people in slow connections prefer "mobile" or "static" versions of those sites). The impetus for SPAs was never really speed. The impetus for SPAs is control for developers, by allowing navigation between "pages" but with zero-reloads for certain widgets. It was like 90s HTML frames but with full control of how everything works.
- lhorie 5y ago
  > So your initial page load would be slow because of all the HTML and JS, but afterwards it should be faster compared to having server side rendered pages TFA is arguing that a user on a bad connection won't even make it to a proper page load event in the first place. It's probably also worth mentioning that the "gains" from sending only data on subsequent user actions are subject to devils in details, namely that response data isn't always fully optimized (e.g. more fields than needed), and HTML gzips exceptionally well due to markup repetitiveness compared to compression rate of just arbitrary data. Generally speaking you can rarely make up in small incremental gzip gains what you spent on downloading a framework upfront plus js parse/run time and DOM repaint times, especially on mobile, compared to the super fast native streaming rendering of pure HTML.
- ufmace 5y ago
  In theory I guess, but I'd bet that basically every SPA is using enough JS libs that the initial load is much bigger than a bunch of halfheartedly-optimized basic HTML. I bet somebody somewhere has written a SPA-style page designed to be super-optimized in both initial load and API behavior just because, but I don't think I've ever seen one.
  - contriban 5y ago
    I agree with the general sentiment, but if you used Facebook and YouTube you know they respond immediately on tap, even if the view hasn’t completely loaded. They are SPA-style pages. Unfortunately they are the exception as there are a lot of awful SPAs that focus on looking cool while they’re barely usable. Looking at you, Airbnb.
    - 10000truths 5y ago
      Facebook and YouTube can afford to use SPAs without worrying too much about performance penalty because they invest massive amounts of effort into highly optimized and widespread content delivery networks, to the point where many ISPs literally host dedicated on-site caches for them.
      - robertlagrant 5y ago
        The nice thing about SPAs is you can push them out to the edge with a CDN quite easily.
        ric2b 5y ago
        Easily compared to what?
        robertlagrant 5y ago
        Compared to non-SPAs.
- ratww 5y ago
  > If the API calls can be limited to one call per user action/page visit, the experience would be better because only some API data has to be transferred instead of an entire HTML page HTML pages are not that big, though, unless you put a lot of content around the data. Not to mention JSON can be wasteful, and contain more data than needed. And lots of SPAs require multiple roundtrips for fetching data. And even if you do have lots of content around your data, there are alternatives, like PJAX/Turbolinks that allow you to only fetch only partial content, while still using minimal JS compared to a regular JS framework.
- grishka 5y ago
  In practice, there's rarely "afterwards". You visit some website once because someone sent you a link. You load that one page and that's it. You read the article and close it. By the time you visit that website again, if you ever do, your cache will be long gone, so you're downloading the 2-megabyte JS bundle again. In other words, pretty often the initial load is the only one.
- marcosdumay 5y ago
  Just enable your web server's deflate middleware and you'll see that raw data sizes aren't very different from fully formatted HTML.
- goodpoint 5y ago
  Not at all: HTML compresses extremely well. CSS/favicon/etc are cached. If you get rid of javascript frameworks used for SPA, the overhead of delivering a handful of HTML tables and forms instead of some JSON is negligible.
  - phil294 5y ago
    > a handful of HTML tables and forms But that depends on the use case, doesn't it. Static sites may as well be huge, and now you need to send all of the surrounding html over, when only a small table or form would need updating. So I am not so sure about your point. The greater the complexity of the displayed page, the more sense it makes to use a SPA network-wise. (edit: mostly covered in sibling comments) You have a point about compression though. I now wonder what the situation would look like if we had (had) native HTML imports, as that would greatly help with caching.
    - goodpoint 5y ago
      > now you need to send all of the surrounding html over, when only a small table or form would need updating No, you don't. For something like the upvote button on HN you can do an ajax call with a line of javascript. In the context of the conversation this is very far from bloated SPAs. HN is a good example: each thread page consists mostly of comments. Reusing the same DOM across different pages would do very little. Gmail is another: the default UI is a heavy SPA. The "plain html" mode is not. And it's faster.
      - phil294 5y ago
        Yeah, you are right. I was thinking of JS-free sites for some reason
nunez 5y ago
That’s already kind of happening. Google and Mozilla both have “accelerator” services that render pages in their data centers; something similar to what opera was doing years ago. I also think Node supports server side rendering. A parking web app I used out in Lincoln NE takes advantage of that.
- easrng 5y ago
  I know about Google's compression proxy but what's Mozilla doing? I found something called Janus but it looks like it was discontinued. Opera Mini is still around and there's also the Firefox-based browsh.
pjmlp 5y ago
We are already there, https://nextjs.org/docs/basic-features/pages https://nextjs.org/docs/basic-features/pages Naturally it has to be more clusmy than just using one of the boring SSR that exist since 2000.
CPLNTN 5y ago
Look up React Server Components

But there is something to be said for SPAs and slow connections. All the HTML and JS code is loaded beforehand and afterwards only raw data is exchanged. If the API calls can be limited to one call per user action/page visit, the experience would be better because only some API data has to be transferred instead of an entire HTML page. So your initial page load would be slow because of all the HTML and JS, but afterwards it should be faster compared to having server side rendered pages.

handrous 5y ago
I very rarely see a "Web App" that's faster due to this. Take Gmail: plain-HTML gmail transfers and renders a whole page faster than full-fat Gmail does most of the things it does, which involve merely "some API data". The activity/loading indicators on normal Gmail display longer than the full-page load on plain-HTML gmail. This had some validity in the early days of AJAX when common practice was to respond with HTML fragments and it was mostly just a work-around for Frames not being very good at a bunch of things they should have been good at. These days, not so much.
- zozbot234 5y ago
  Makes sense. Roundtrips will kill you on slow connections, and the average SPA does lots of back-and-forth roundtrips. Then the JS code has to tweak hundreds or thousands of DOM nodes in a completely serial fashion to reflect the new data. Much faster in practice to either download or generate (preferably via WASM) a single chunk of raw HTML and let the browser rerender it natively.
  - handrous 5y ago
    It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies allocated, now, depending on how the parsing works), modify that for whatever your in-browser data store is, and/or copy it in there, or copy it to "local state", or whatever (three copies), render the data to the shadow DOM (four copies), render the shadow DOM to the real DOM (five copies). Some of those stages very likely hide even more allocations of memory to hold the same data, as it's transformed and moved around. Lots of library or pattern choices can add more. It adds up.
    - wonnage 5y ago
      Especially with graphql being the new hotness I wonder if it's time to replace JSON with a binary format like Thrift. The old argument was that REST+JSON was simple and easy to debug but that goes out the window with GQL anyway. JSON is just a terrible fit for GQL schemas. I regularly deal with metadata enum fields that are repeatedly serialized causing massive bloat. Sure it gets gzipped away, but you still have all those copies after decompression and parsing.
      - RedShift1 5y ago
        If you were sending HTML those copies and parsing would be there anyway?
    - Dylan16807 5y ago
      Even so, if we look at gmail all the data needed for the email list is 20-100KB. The bloat is caused by bad design, not the extra copies.
      - pdimitar 5y ago
        When 99% of all SPAs I ever used are that painfully slow (sometimes even on 4G) then obviously that way of work encourages people to make bad design. So we should uproot the problem and not dance around it.
  - toast0 5y ago
    It really depends on both latency and bandwidth. A reasonable POTS modem does ok on latency, but bad on bandwidth. So roundtrip is fine until you send too much data (which is real easy, modern initial segment limit of 10 combined with a 1500 mtu is more than a second of download buffer). If you kept the data small, many round trips would be okish. On the other hand, traditional geosynchronous satellite always has terrible latency, so many round trips is bad regardless of the data size... One big load would be a lot better there.
    - giantrobot 5y ago
      POTS modems don't do great on latency either. I never managed under about a quarter second latency on dial-up. The first hop (your modem'd DAC and the ISP modem's ADC) was usually around 75-100ms all by itself. So even today with pretty fast networks (compared to the heyday of modems) you're easily looking at base latency of a quarter second.
      - icedchai 5y ago
        Modem latency was crap. That was another reason a 64K single channel ISDN connection felt so much faster, even though the bandwidth wasn't that much more. ISDN latency was wayyy better since it was digital: 10 to 20ms vs 200ms minimum with an analog modem. Some early ISPs I worked with started with 56K leased lines. The latency there was like night-and-day compared to a 56k modem.
        giantrobot 5y ago
        My first experience with an ISDN connection was mind blowing. I had only ever used analog modems prior. So I'm just expecting faster downloads for large files and pages would load faster. It was a 64k line so I was expecting it to be twice as my modem at home. Web pages just appeared (modulo Netscape connection limitations). A fresh page load felt as fast as a cached page load on my analog modem. It was nuts. It was most noticeable in a handful of games of Quake I played. I got to experience the joy of being a Low Ping Bastard and actually landing a few hits on people.
  - swiley 5y ago
    They also handle errors by having the user reload the page which means everything starts over. My experience growing up is that you don't notice the issues on sane pages written by hobbyists/professors/researchers and then you go to something built by google and everything falls apart.
- RedShift1 5y ago
  It only works if the webapp can keep its calls limited to 1 per page/user action. Lots of webapps make multiple roundtrips (additional fetches triggered by earlier requests so they can't be done in parallel) making it slow even on fast connections (looking at you Quickbooks Time).
  - robertlagrant 5y ago
    This is exactly why BFFs exist.
    - RedShift1 5y ago
      What's a BFF?
      - robertlagrant 5y ago
        https://samnewman.io/patterns/architectural/bff/ https://samnewman.io/patterns/architectural/bff/
doliveira 5y ago
As someone who has lived with actual slow connection and budget phones, I don't think I've ever seen this promise fulfilled. It should work, but it's never so in practice.
masklinn 5y ago
There really is not. SPAs generally means tons more assets being loaded and hard errors on on unreliable connections. On a web page, missing a bit of the page at the end is not an issue, you might have somewhat broken content but that's not a deal-breaker. With an SPA, an incompletely loaded API call is just a complete waste of the transferred bytes. And slow connections also tend to have much larger latencies. Care to guess what's an issue on an SPA which keeps firing API calls for every interaction? > So your initial page load would be slow because of all the HTML and JS, but afterwards it should be faster compared to having server side rendered pages. The actual effect is that the initial page load is so slow you just give up, and if you have not, afterwards it's completely unreliable. Seriously, try browsing the "modern web" and SPAs with something like a 1024 DSL with 100ms latency and 5% packet loss, it's just hell. And it's the sort of connections you can absolutely find in rural places.
- RedShift1 5y ago
  Won't loading an entire HTML page be just as bad on such a connection? There's a lot more data to transfer.
  - misnome 5y ago
    > On a web page, missing a bit of the page at the end is not an issue, you might have somewhat broken content but that's not a deal-breaker - the argument is that most of what you probably want is better than nothing. Although I can imagine sites thus prioritising ads even more…
  - ratww 5y ago
    Not at all, unless there is an absurd amount of content on the page that is unrelated to the data being fetched (like title, footer, sidebar). An HTML-table, for example, is in the same ballpark size-wise as a JSON representation of the same data. And that's without taking into account the fact the JSON can potentially carry more information than necessary. Facebook is an example of a website where there is such an absurd amount of content that's not the focus of the page: the sidebars, the recommendations, the friend list of the chat, the trends, the ads. It sorta makes sense for them to have an SPA (although let's be frank: most people in slow connections prefer "mobile" or "static" versions of those sites). The impetus for SPAs was never really speed. The impetus for SPAs is control for developers, by allowing navigation between "pages" but with zero-reloads for certain widgets. It was like 90s HTML frames but with full control of how everything works.
lhorie 5y ago
> So your initial page load would be slow because of all the HTML and JS, but afterwards it should be faster compared to having server side rendered pages TFA is arguing that a user on a bad connection won't even make it to a proper page load event in the first place. It's probably also worth mentioning that the "gains" from sending only data on subsequent user actions are subject to devils in details, namely that response data isn't always fully optimized (e.g. more fields than needed), and HTML gzips exceptionally well due to markup repetitiveness compared to compression rate of just arbitrary data. Generally speaking you can rarely make up in small incremental gzip gains what you spent on downloading a framework upfront plus js parse/run time and DOM repaint times, especially on mobile, compared to the super fast native streaming rendering of pure HTML.
ufmace 5y ago
In theory I guess, but I'd bet that basically every SPA is using enough JS libs that the initial load is much bigger than a bunch of halfheartedly-optimized basic HTML. I bet somebody somewhere has written a SPA-style page designed to be super-optimized in both initial load and API behavior just because, but I don't think I've ever seen one.
- contriban 5y ago
  I agree with the general sentiment, but if you used Facebook and YouTube you know they respond immediately on tap, even if the view hasn’t completely loaded. They are SPA-style pages. Unfortunately they are the exception as there are a lot of awful SPAs that focus on looking cool while they’re barely usable. Looking at you, Airbnb.
  - 10000truths 5y ago
    Facebook and YouTube can afford to use SPAs without worrying too much about performance penalty because they invest massive amounts of effort into highly optimized and widespread content delivery networks, to the point where many ISPs literally host dedicated on-site caches for them.
    - robertlagrant 5y ago
      The nice thing about SPAs is you can push them out to the edge with a CDN quite easily.
      - ric2b 5y ago
        Easily compared to what?
        robertlagrant 5y ago
        Compared to non-SPAs.
ratww 5y ago
> If the API calls can be limited to one call per user action/page visit, the experience would be better because only some API data has to be transferred instead of an entire HTML page HTML pages are not that big, though, unless you put a lot of content around the data. Not to mention JSON can be wasteful, and contain more data than needed. And lots of SPAs require multiple roundtrips for fetching data. And even if you do have lots of content around your data, there are alternatives, like PJAX/Turbolinks that allow you to only fetch only partial content, while still using minimal JS compared to a regular JS framework.
grishka 5y ago
In practice, there's rarely "afterwards". You visit some website once because someone sent you a link. You load that one page and that's it. You read the article and close it. By the time you visit that website again, if you ever do, your cache will be long gone, so you're downloading the 2-megabyte JS bundle again. In other words, pretty often the initial load is the only one.
marcosdumay 5y ago
Just enable your web server's deflate middleware and you'll see that raw data sizes aren't very different from fully formatted HTML.
goodpoint 5y ago
Not at all: HTML compresses extremely well. CSS/favicon/etc are cached. If you get rid of javascript frameworks used for SPA, the overhead of delivering a handful of HTML tables and forms instead of some JSON is negligible.
- phil294 5y ago
  > a handful of HTML tables and forms But that depends on the use case, doesn't it. Static sites may as well be huge, and now you need to send all of the surrounding html over, when only a small table or form would need updating. So I am not so sure about your point. The greater the complexity of the displayed page, the more sense it makes to use a SPA network-wise. (edit: mostly covered in sibling comments) You have a point about compression though. I now wonder what the situation would look like if we had (had) native HTML imports, as that would greatly help with caching.
  - goodpoint 5y ago
    > now you need to send all of the surrounding html over, when only a small table or form would need updating No, you don't. For something like the upvote button on HN you can do an ajax call with a line of javascript. In the context of the conversation this is very far from bloated SPAs. HN is a good example: each thread page consists mostly of comments. Reusing the same DOM across different pages would do very little. Gmail is another: the default UI is a heavy SPA. The "plain html" mode is not. And it's faster.
    - phil294 5y ago
      Yeah, you are right. I was thinking of JS-free sites for some reason

nunez 5y ago

That’s already kind of happening. Google and Mozilla both have “accelerator” services that render pages in their data centers; something similar to what opera was doing years ago. I also think Node supports server side rendering. A parking web app I used out in Lincoln NE takes advantage of that.

easrng 5y ago
I know about Google's compression proxy but what's Mozilla doing? I found something called Janus but it looks like it was discontinued. Opera Mini is still around and there's also the Firefox-based browsh.

pjmlp 5y ago

We are already there, https://nextjs.org/docs/basic-features/pages https://nextjs.org/docs/basic-features/pages Naturally it has to be more clusmy than just using one of the boring SSR that exist since 2000.

CPLNTN 5y ago

Look up React Server Components