The duality of Hacker News.
QUIC is really cool technology. It can solve a wide range of problems that aren't necessarily HTTP based.
However, HTTP/3 is using QUIC as a patch over badly designed websites and services.
QUIC doesn't solve the problem, it provides another path around the source of the problems. This blog was written by Akamai, a CDN that makes profits off the problem of "my website is too fat to lose quickly anymore". I don't blame them, they should sezie the opportunity when they can, but their view is obviously biased.
QUIC makes most sense for sites that can optimise it, like the Googles, Cloudflares, and Akamais of the world. For the average website, it's just another technology decision you now need to make when setting up a website.
Most "modern bloated" SPAs are tiny. The default MSS for most TCP implementations is 1460 bytes, that's 1.42 kB max per packet. Just the TCP handshake packets themselves (3 * 1460) can hold almost as much data as it takes to get a standard SPA. This says nothing about the TLS handshake itself which adds another 3 packets to connection establishment. Most SPAs send small and receive small payloads; a compressed JSON exchange can easily fit in a single packet (1.42 kB.)
The actual amount of bandwidth on the wire between a server-side rendered "fast" app and a "modern bloated" SPA isn't very different, the difference is in how they send and receive data. SSR pages send a thin request (HTTP GET) and receive a large payload; generally the payload is much larger than the connection establishment overhead, so they make good use of their connection. On the other hand, a naive SPA will involve opening and closing tens or even hundreds of connections which will lead to a huge waste (6 packets per TLS+TCP connection) of overhead. QUIC makes it possible to have small connection-oriented request/response semantics on the internet with minimal fuss.
That said the problem with rants like GP's comment is that they don't serve to illuminate but serve to push on us, the readers, the author's agitated emotional state. Instead of having a discussion about bandwidth and connection overheads, or even trying to frame the discussion in terms of what "waste" really is, we get emotional content that begs us to either agree with an upvote or disagree with a downvote with nothing of substance to discuss. Any discussion website is only as strong as its weakest content and if content like this continues to get lots of upvotes shrug
I have no idea in what reality you live where you encounter SPAs of a few Kbs. Don’t even know what to say if that’s your experience.
> That said the problem with rants like GP's comment is that they don't serve to illuminate but serve to push on us, the readers, the author's agitated emotional state.
You are absolutely right there. I will try to refrain from these “frustration posts” in the future. Sorry about that.
Let's look at a SPA version of HN [1] and compare it against base HN. This base SPA page fetches 21 KiB of data. The base version of HN fetches 36 KiB of data. Most SPAs are much less information dense and have a lot more CSS and media than non-SPA websites. In a world without SPAs these sites would not be leaner, they would instead just insert tons of CSS style links and img tags to fetch the media themselves, resulting in the same amount of bandwidth.
If your argument is that websites should be leaner regardless, well in my experience most users would rather put up with a slow good-looking page than a fast spartan one. It's a hallmark of a nerd that's willing to cut corners just to get access to the information they want.
Again I was just venting and that sucks. Yelling at the cloud(s).
Not everything that shines is gold my friend.
But I concede my comments are really ranty. Sorry about that. It's frustration.