[1] Although satire is dead, killed by people actually espousing extreme views on the internet, I still indulge but am forced to explicitly tell the reader: this is ridiculous satire. Of course we should solve the root of the problem and not invent/adopt technology that enables our bad habits.

No, it's not, multi-dimensional optimization and improvement-in-depth is good, actually.

Look back at the small site hosted in Bangalore - That's an Indian version of me. A hacker whose projects can't run on self-hosted Wordpress, who only bought a VPS because their home ISP is not reliable.

With HTTP/1, most of America can't load their site, it times out. With HTTP/2, it takes 2,500 ms. With HTTP/3, it takes 1,000.

A _petty_ software upgrade allows this imagined Indian blogger to gain an audience on _another continent_ without buying more servers, without using a CDN, and without taking advertising deals to afford more stuff.

You know 3 things I hate about the web? Advertisements, CDNs, and having to buy servers.

I promise this is purely geographical, not political - How often do you connect to servers outside the USA and Europe? I mean trading packets with a computer. YouTube uploads don't count because they have a CDN. For me, the answer is "almost never".

The Internet is supposed to be global, but computers are made of matter and occupy space, so connections to nearer servers are still better, and they always will be. But QUIC makes the far-away connections a little less bad. That is a good thing.

That shouldn't happen. Do you have a real site in mind there?

> No, it's not, multi-dimensional optimization and improvement-in-depth is good, actually.

That can be true at the same time as "it's sad that we need this"

Other protocols may work much better in such conditions, for example popular messengers can send and receive text, metadata and blurry image previews just fine. In some cases even voice calls are possible, but not a single website would load ever.

I think HN crowd won't notice the changes. I hope that the protocol would improve experience for smartphone users without reliable 4G connection.

Your messenger isn't sending tens of megabytes for every message.

> metadata and blurry image previews just fine.

One might wonder why they don't just send the 4 MB JPEGs instead of those down scaled to hell previews if they work so well.

> . In some cases even voice calls are possible

Not only kilobytes of data, but kilobytes of data where transmission errors can be completely ignored. I have been in enough VoIP calls to notice how "well" that works in bad conditions.

Everything points to putting websites on a diet being the correct solution.

> And if the connection drops, then it almost certainly won't recover and full page reload is necessary.

I would consider that a browser bug. No idea why the connection wont just timeout and retry by itself.

It would help a lot but it's not a full solution. You also need to stop TCP from assuming that every lost packet is because of congestion, or it will take a slow connection and then underload it by a huge factor.

I mean no, but it can be unreasonable to expect that physical limits get beaten if you have in mind that some people just have a few hundred to a thousand KM between their computer and the server they access.

E.g., in my hometown I may get latencies of 200 ms and more to a few sites, especially simpler ones that have no CDN but are a single server on the other end of the world. Don't get me started if I'm travelling between Vienna and South Tyrol using the train, in some parts (cough Germany) the internet is really spotty and latency spikes up to 10 to 20s are (sadly) rather normal for a few minutes here and there.

Now, with HTTP 1.1 over TCP and TLS involved the setup time already gets me to almost a second of wait time (more than the few tens of ms my finger needs to leave the Enter key) in the former setup and in the latter I may need 30 to 60s, or it even just times out when travelling by train and being in a bad spot, connectivity wise.

QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times (none) compared to TCP (even with TCP fast-open).

So simple websites can profit too from QUIC, initial load time can get reduced a lot, browsing them is finally doable also on remote, spotty connections. Also, I happen to develop applications that are delivered as web app, they just tend to acquire a certain complexity even if one tries to stay simple, so loading that faster even if nothing is already cached is a welcome thing to me.

Bloated page still will be slow, sure faster than with HTTP 1.1 but still slow, and I definitively would like to see that getting improved, but that's not really related to the issues that QUIC improves on, as simple websites win too when using it; it's just less noticeable there if you already have a somewhat OK connection.

In summary: Why not invent a new protocol if you can significantly reduce overhead for everyone, especially if it can coexist with the simple and established one.

Pretty sure I said nowhere that we shouldn't invent new and better protocols. QUIte the contrary (pardon the pun).

What I am saying is: We should not need to rely on new protocols to make up for the fact that we send more and more garbage, we should send less garbage.

If we can get less garbage, and new and improved protocols, all the better!

But if all we do is invent better protocols, the result will be that what buries the internet in garbage now, will use that better protocol to bury us in even more garbage.

You're saying it's good to make sites smaller, and I agree. You're saying QUIC is good, and I agree.

What do you want? To just complain that bad sites exist? Is this "what-aboutism" for programmers?

I'm sorry, usrbinbash. I'm sorry that bad things happen, and I wish I could make you happy.

How about for people to recognize that this performance gift is easily squandered, and talk about how we're going to prevent bloat so that we can preserve the good performance.

hmmm abit skeptical on the less round-times. Are the all the round-times in TCP to ensure the integrity of the connection. With UPD it is my understanding that no confirmation of receiving packet is issued. So a server can send out a signal, but never can be sure if the client got it. I can see it can be great for multiplexing/broadcasting, but the switch the whole http protocol over like this, I can't imagine there won't be tons integrity and security issues.

HTTP over QUIC will probably do a similar number of round-trips compared to HTTP over TCP, but it will do much fewer than HTTP over TLS over TCP. There's no getting away from SYN/SYN-ACK/ACK for a reliable protocol, but QUIC can put certificate negotiation information directly here, instead of the TLSoTCP approach of SYN/SYN-ACK/ACK/ClientHello/ServerHello/ClientKeyExchange/ServerKeyExchange.

Additionally, QUIC supports multiple streams over a single physical connection, and correctly implements packet ordering constraints and retries for them. TCP supports a single stream over a connection: any delayed packet will delay the entire stream. In QUIC, a delayed packet will only delay packets from the same logical stream, packets from other streams can still be received successfully on the same connection.

This feature is heavily used by HTTP/3: HTTP/2 introduced a concept of HTTP streams, but all HTTP streams were run over the same TCP connection, so over a single TCP stream: a slow packet on HTTP/2 stream 1 will delay all packets from HTTP/2 streams 2, 3 etc. With QUIC, an HTTP/3 stream is a QUIC stream, so a single slow request will not blkc other packets from other requests from being received.

so we are using a slightly older version of QUIC than the RFC and using go-quic on server and client. and this is what i see when creating a connection:

    Client: Initial (1284 bytes) includes client hello
    Server: Retry (166 bytes) includes retry token
    Client: Initial (1284 bytes) including retry token and client hello
    Server: Server Hello/Encrypted Extensions/Cert 
    Request/Certificate/Certificate Verify/Finished (1284 bytes) 
    Client: Certificate/Certificate Verify/Finished (1284 bytes)

https://datatracker.ietf.org/doc/html/rfc9000#section-8.1

probably what go-quic does is not optimal because you don't always have to validate the address.

   Prior to validating the client address, servers MUST NOT send more
   than three times as many bytes as the number of bytes they have
   received.  This limits the magnitude of any amplification attack that
   can be mounted using spoofed source addresses.  For the purposes of
   avoiding amplification prior to address validation, servers MUST
   count all of the payload bytes received in datagrams that are
   uniquely attributed to a single connection.  This includes datagrams
   that contain packets that are successfully processed and datagrams
   that contain packets that are all discarded.

    A server might wish to validate the client address before starting
   the cryptographic handshake.  QUIC uses a token in the Initial packet
   to provide address validation prior to completing the handshake.
   This token is delivered to the client during connection establishment
   with a Retry packet (see Section 8.1.2) or in a previous connection
   using the NEW_TOKEN frame (see Section 8.1.3).

The infrastructure inertia part isn't even so much a question of technical infeasibility, but greed. So much spending was slotted to carriers to improve their networks, but instead of investing in capacity and protocol upgrades, it all went to lobbying/exec bonuses.

If SCTP really ran on UDP. I'd have no reason to be salty, because we'd already be using it.

> I'd have no reason to be salty, because we'd already be using it.

Direct OS support is a big deal, and UDP gets messed with too. If someone made SCTP-over-UDP the default mode, while changing nothing else, I don't think it would affect adoption at all.

I think you have an overly rosy view of the time. Yes, some things were fast, especially if you had an unusually good connection, but the average person's experience of the internet was much slower and less reliable.

This site, which we're on, delivers pages of comments (this very comment thread is around 50K of comment text) almost instantly.

The Washington Post homepage loads in 600ms for me. 20K of text. Images load within about another 500ms. Their lead article right now is one of those visual feature ones with animations that trigger on scroll, so after the text first appears after 600ms, it takes a second or so longer for the layout to finish. But a routine text article page, I have a scrollable, readable text view within 500ms.

CNN.com, a fraction slower, for a little less text, but a lot more pictures. When I click into one of their articles, within a few seconds, it starts streaming me 1080p video of their news coverage of the article. Imagine that on your 'fast functional 90s and early 00s' web.

Or let's pick a technical resource. go.dev's landing page? No noticeable delay in loading for me, and that page has an embedded form for trying out Go code.

Or reactjs.org, say? Loads up in 200ms for me, and then subsequent navigations on site among documentation pages take about 60ms.

How about a government resource? irs.gov? The homepage maybe loads a little slower than I'd like, but FAQ pages are pretty responsive for me, with text appearing almost as soon as I've clicked the link.

I'm not cherrypicking, these were the first few websites that came to mind to test to see if things are really as bad as you're portraying. And my impression is... you know? It's not that bad?

I am not arguing that there aren't bad sites out there, but we need to stop pretending that the entire world has gone to hell in a handcart and the kids building websites today don't care about optimization. Substantive websites deliver substantive content efficiently and effectively, with a level of functionality and visual flair that the 90s/00s web could only have dreamed of.

Every website which loads way more content than its use case justifies. If the high quality of my device and ubiquitous broadband is the only reason that something appears to be loading fast, that's not good.

>Or let's pick a technical resource. go.dev's landing page? No noticeable delay in loading for me

Among other things, that's because this is a website loading what it has to, instead of everything and the kitchen sink. 885kB in total, and most of that are the images of "companies using go".

But I just picked a few obvious high profile information-oriented sites and none of them had that problem. So… which websites are the bad ones?

Are you looking at the first site that comes up when you search for ‘chocolate chip cookie recipes’ and holding that up as an example that the web is a disaster area?

That’s like picking up a gossip magazine from the rack in the supermarket checkout line and complaining that American literature has really gone to the dogs.

Do you get substantively different experiences on those sites if you don't?

> The tech lead for Google's AMP project was nice enough to engage us on Twitter. He acknowledged the bloat, but explained that Google was "resource constrained" and had had to outsource this project

> This admission moved me deeply, because I had no idea Google was in a tight spot. So I spent a couple of hours of my own time making a static version of the AMP website. . .

> By cutting out cruft, I was able to get the page weight down to half a megabyte in one afternoon of work. This is eight times smaller than the original page.

> I offered my changes to Google free of charge, but they are evidently too resource constrained to even find the time to copy it over.

The bloat and slowness is generally due to incompetence. On one hand it’s merchandising stalking users with poorly written spyware and on the other hand the technology is dictated by the lowest common denominator of developers who cannot perform without monumental hand holding.

Does the end user really want or prefer the megs of framework abstraction? No, that’s immature trash from developers insecure about their jobs. This is the standard of practice and it isn’t going away. In hiring it’s seen as a preference as increased tool proliferation can qualify higher wages.

The only way that’s going to get better is by moving to an alternate platform with more challenging technical concerns than populating content.

With IPv6 and gigabit internet to the house becoming more common in the US there is less and less reason to require web servers, data centers, and other third party concerns. These are incredibly expensive and so long as the platform becomes progressively more hostile to their users emerging alternatives with superior on-demand capabilities will become more appealing.

That way it should be possible to turn off a lot of that garbage that is generic JS. Of course, then the problems becomes website built to not work if you don't have that stuff. I suppose the solution is a protocol where it's not possible to know, i.e any server-side state is disallowed so that you cannot track id users have seen your ads OR the such a response cannot be proven.

What utter arrogance. Developers are more often than not driven by time constraints and demands from higher up the food chain. What you call "bloat" is often not just the easier solution, but the only one.

Of course, "bloat" can come from neglecting the non-bloatiness. But to call this mainly a function of competence is in my opinion misguided.

Stepping back from the nonsense I believe this is a training disparity.

> The bloat and slowness is generally due to incompetence.

I'm sure this is true.

I'm also reminded of "office automation". Conventional wisdom was that new technologies would reduce the use of paper. However, for decades, paper usage went up, and it took a long time for the reduction to happen.

Curious, no?

Was increased paper usage an instance of Jevons Paradox? https://en.wikipedia.org/wiki/Jevons_paradox

I have questions.

So then why did paper usage eventually plummet?

Given long enough time frame, is Jevons Paradox a phase? 150 years after Jevons book The Coal Question, coal consumption is finally tanking. Decades after the start of data processing and office automation, paper usage finally tanked.

Is this generalizable?

Clearly software bloat (and by extension web page bloat) are catalyzed by better tools. Like the democratization of word processing (et al) begat more paper usage, IDEs (et al) begat more code production.

If there is a downside slope to Jevons "rebound effect" (efficiency -> lower cost -> higher consumption), what could it look like for software bloat? What are some possible causes?

For coal and paper, it was displacement by even cheaper alternatives.

What's cheaper than large, slow web pages? Or conversely, how do we raise the cost of that bloat?

Making a huge leap of reasoning:

My optimistic self hopes that the key resource is attention (people's time). Social media values each person's eyeballs at $100/yr (or whatever). So all the nominal costs of all those bloated web pages is pretty cheap.

My hope is the displacement of software bloat will be somehow related to maximizing people's cognitive abilities, making better use of attention. So replace web surfing, doom scrolling, and the misc opiates of the masses with whatever's next.

This hope is strongly rooted in Clay Shirky's works Cognitive Surplus and Here Comes Everyone.

Thanks for reading this far. To wrap this up:

I regard software bloat as a phase, not inevitable.

I imagine a futureperfect media ecosystem not dependent on ad supported biz models, the primary driver for web page bloat.

I have no idea if people smarter than me have studied the tail end of Jevon's Paradox. Or even how much predictive power the Paradox has at all.

I have no idea what the displacement may look like. Maybe patronage and subscriptions. Or maybe universal basic income, so amateurs can self produce and publish; versus "platforms" exploiting user generated content and collaborative editing.

A bit of a scrambled thesis, I know. I'm writing to understand, sound out a new idea. Thanks for your patience.

My browsers shouldn't need to make 100 network connections and download megabytes to display a thousand words of text and some images. It should be about 1 network connection and maybe dozens of kilobytes (for images).

We are not complaining about the web version of productivity apps like email, spreadsheets, project management, etc. loading slowly. But a newspaper article should load faster than a social media feed, and often they don't.

...I mean it's to build a web application, but that's different.

I've been building web stuff since the 90s. Your memory of what it was like is flawed. Sites were slow to load. People complained about images because they took a while to load, and as soon as they completed the page jumped down and you lost your place. Moving from one page to another page on the same site required throwing all the HTML away and starting over, even in a web app like an email client (MSFT literally invented XMLHttpRequest to solve that). The HTML content itself was bloated with styles and font tags and table layouts. Often a tiny article would weigh in at 50KB just because it had been created in DreamWeaver or Hotmetal or something and the code was horrible.

Thr web didn't feel fast back then. It was hellishly slow. I had perf budgets to get sites loaded in under 8s (and that was just measuring the time to a DOMContentLoaded event, not the same as today's Core Web Vitals idea of loaded).

There's no doubt that the web is, in many places, bloated to shit. It's not worse though. It's significantly better. It's just that there's more work to be done.

Its not better if the only thing that keeps it afloat is the fact that broadband is ubiquitous by now (and that isn't even true for most of the world), and hardware got alot better.

The main difference is that many people started using the web after the gamification and bloatation took over, so they are used to adbanners flying in, random videos which start playing, and phone batteries going flat just by looking at a news article.

> It's just that there's more work to be done.

But is that extra work necessary? Look at this threads page on HN. It loads 402 kb worth of content: the html, a tiny amount of JS that isn't even minified (and doesn't have to because its so slim), a small css file, 3 small gifs and the favicon.

That's it. That's all the network-load required to display a usable, information-dense, not hard to look at and performant experience.

if something doesn't start loading in 5 seconds and you are still giving it time without jumping up and down, tcp gave you stockholm syndrome.

I'm not familiar with quic so I don't know how to feel about it, but we are in dire need of an alternative that doesn't require reimplementing the good parts of tcp over udp like every game and communication apps in the world do.

It has unreliable, unordered datagrams, and a huge number of TCP-like streams, all wrapped in the same TLS'd connection.

When I look at QUIC, I see old TCP protocols like IRC and telnet coming back. The difficulty of encryption pushed many applications into HTTPS so they could stay safe, even though HTTPS isn't a perfect fit for every app.

With QUIC saying "You're as safe as possible and you have basically a UDP and TCP portal to the server, have fun", I think we'll see some custom protocols built / rebuilt on QUIC that were lying dormant since the age when encryption was optional.

For instance, multiplayer games could probably just use QUIC as-is. Send the real-time data over the datagrams, and send the chat messages and important game state over the streams. Instead of some custom game communications library, and instead of connecting TCP and UDP to the same server, one QUIC library and one QUIC connection. Now it's within the reach of a solo indie developer who wants to focus on their game-specific netcode, and not on re-inventing networking ideas.

https://quicwg.org/datagram/draft-ietf-quic-datagram.html

They're working on it, I guess.

At least this (compared to unskippable commercials of past) I can bypass looking at.

But that is how 75% of the people reading this make their living...

Actually, in this case "we" means Google and a few other big companies whose aims are not the same as ours - they are the ones in charge. Sure, at times it happens that our interests are somewhat aligned (like page load times) but only as far as it serves them. For Google, a page without their code like ads/analytics is pretty much useless; for us, it's more useful because it doesn't track us and loads faster.

So yes, while they continue doing some work in that respect, I expect it will actually go worse with time as they are focused on average consumer bandwidth in the USA. Once G5 is well entrenched and broadband/fiber gets even faster, we can expect even more bloat on websites and there is not much "we" (=users and developers) can actually do about it.

What I really don't get is why bare html looks so awfully today and you have to add tons of js and css to get something acceptable.

No we don't.

As I have written before in this topic, HN is the perfect example. It pulls in a small css and js file, both of which are so slim, they don't even require minifying. The resulting page is small, looks good, is performant and most importantly does its jobs.

We don't need megabytes worth of cruft to display a good looking page.

It looks good for technical people. It does not look good for others.

I am also sure she would love these selfsame pages to load instantly when shes accessing them via her old cell phone at my uncles house where reception is bad and the device has to revert to 3G.

No, "other" people don't want bloat, tons of adds and "clever designs" (aka. a huge useless picture-banner that contains zero information) either.

https://www.bbcgoodfood.com/ - 12MB https://www.jamieoliver.com/ - 4.3MB https://www.deliciousmagazine.co.uk/ - 8.4MB

It seems their users didn't wanted them to be so barebone.

I am not saying people want bloat, but they won't accept HN-style simplicity. What I'd like to have is good looking sites with no CSS at all, just make them acceptable by default, and a lot of this bloat will simply go away.

The result: traffic congestion on 6 lanes.

https://en.wikipedia.org/wiki/Braess%27s_paradox

That will be the explanation, I’m not too optimistic.

Even Wikipedia begs for money it doesn't need.

Why not?

He never said experts shouldn’t design protocols, and nothing like that was anywhere near the point.

A good solution could have been AMP: https://amp.dev/

> mostly to spy on me

If only AMP was not beholden to an adcorp.

So it's already possible to achieve quite restricted subsets of what a website can do. The issue is agreeing on what subset is useful enough for many sites.