Counterexamples: DNS and it's silly, idiosyncratic compression; FTP and its absolutely batshit control/data channel connections; the ASN.1/BER nightmare of SNMP. Also consider the "simple, plaintext protocols" that should not have been: the r-utils, for instance, had to be supplanted by encrypted binary protocols; NNTP failed, and ultimately ended up centralizing Internet discussion on sites like this, because it was doggedly optimized for text and inevitably abused for binary sharing.

The moral of my story is: those old protocols were bad, practically all of them.

> NNTP failed, and ultimately ended up centralizing Internet discussion on sites like this, because it was doggedly optimized for text and inevitably abused for binary sharing.

That's not really why it failed though, since those binaries are in separate newsgroups that most servers simply don't carry.

The issue is more about spam and lack of moderation, which makes it somewhat unfriendly to newcomers, since one has to do the spam/troll filtering locally. This over time lead to most newsgroups slowly dying out.

It's 100% of why they failed. NNTP providers that didn't provide full feeds were loudly boycotted. Customers and users left those providers. Ask me how I know! Doing competitive full-feed NNTP was one of the most annoying and least useful things I've worked on.

I have been running a (non-binary) usenet server for quite some time too.. Don't underestimate the annoyance of spam and trolls. They kill pretty much anything once active moderation disappears. Once they exceed a certain fraction people tend to get very annoyed and jump ship for anything where they have interact less with them. Over time only trolls are left in the newsgroup (in many newsgroups they haven't really left to this day).

I consider binary newsgroups and the rest to be two almost unrelated things. Plenty of non-binary usenet servers were doing just fine, but of course no one would really pay for them.

Fair warning: even by my standards, this is an area where I have strong opinions (I loved Usenet, and ran a Freenix-competitive full-feed site in the 1990s). I'll just leave this here:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

I'm not saying I can refute what you're saying, just that I think my claim about "binary vs. plaintext" being problematic with respect to NNTP is well-founded.

HTTP is a simple, plaintext protocol.

(I've implemented producton-grade HTTP libraries many times. HTTP being a one-size-fits-all protocol means the existing libraries are ridiculously specialized and overspecced.)

HTTP 3 isn’t plain text.

HTTP 3 isn't HTTP.

HTTP is the universal protocol because the mental model of "verb-metadata-payload" fits almost everything you can imagine, and the socket handshake/framing parts are obvious and very performant. This is why HTTP is used everywhere from pushing stock quotes to industrial automation.

HTTP 2 and 3 aren't universal protocols, they solve a very specific problem of serving static content to browsers for Google-scale websites.

In effect, HTTP 2 and 3 are exactly the kind of niche one-problem protocol that HTTP was supposed to replace.

This is a pretty facile analysis. HTTP2 is faster, more flexible, and more reliable than HTTP1. HTTP2 also eliminates the need for several silly performance hacks in HTTP1. The differences might not matter for your static site, but they matter a lot for larger applications, and, more importantly, they open the door for using HTTP2 in situations where today people would be building their own clunky ad-hoc protocols; that's the opposite of the phenomenon you describe with respect to the two protocols.

HTTP3, more the same! The performance wins of HTTP3 won't matter at all for most typical web applications. But typical web applications aren't the point of HTTP3.

> HTTP2 is faster,

No.

> ...more flexible,

No.

> ...and more reliable than HTTP1

No.

Like I said in another comment - I'd wager the majority of HTTP use cases have nothing to do with a browser or HTML/CSS/JS.

HTTP2 might be nicer when you're serving static content to a browser; debatable, but I'll give the benefit of the doubt.

In all the other vast domains of HTTP usage HTTP2 does nothing good.

My concerns have nothing to do with HTML/CSS/JS, but rather the suitability of HTTP as a transport for arbitrary client server protocols --- the subject of this thread. For general transports, multiplexing alone is an obvious win over HTTP.