We are soon coming full circle when this generation's programmers realize they can render html templates server-side.
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.
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.
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.
Some early ISPs I worked with started with 56K leased lines. The latency there was like night-and-day compared to a 56k modem.
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.
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.
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.
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.
- the argument is that most of what you probably want is better than nothing.
Although I can imagine sites thus prioritising ads even more…
In other words, pretty often the initial load is the only one.
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.
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.
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.
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.
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.
It should work, but it's never so in practice.
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.
Naturally it has to be more clusmy than just using one of the boring SSR that exist since 2000.