Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

So first Google (Chrome team) foobar'd HTTP (and HTML and CSS and ...) into overengineered crap to replace TCP with vague promises of pushed resources and multiplexing only necessary to handle absurdly bloated CSS, images, and fonts there for CDNs by Google et al to sensor your traffic and visit data in the first place, then they admitted server push, as the other touted advantage, being not well thought out after all. The effect being to derail most F/OSS HTTP libs, web servers, and TCP/IP stacks due to sheer complexity and conflicting goals. Wish we'd call Google's destructive efforts towards the web as what they are.

View on HN

You are grossly misrepresenting the situation. Google has played a significant role in HTTP/2 and HTTP/3 development, and they did provide the starting point in each case, but they have not controlled it, and what has come out of IETF after collaboration with many interested parties is significantly different from what Google first proposed. And Google is far from the only party that wants, uses and will benefit from HTTP/2 and HTTP/3.

And once talking about all this, the Chrome team is one of the less important parts of Google in bringing about HTTP/2 and HTTP/3.

Yes, HTTP/2 and HTTP/3 are more complex than HTTP/1, but these are not the ways Google is harming the web—these are the good parts of what Google is helping to improve the web.

You are yearning for the simple and inefficient days of yore, but those days are gone. The internet is a part of society now, and keeping it inefficient and slow does no one any good.

Your tirade is misguided and significantly factually inaccurate.

>And Google is far from the only party that wants, uses and will benefit from HTTP/2 and HTTP/3.

So would it happen if Google wasn't involved?

Google served as a well-placed catalyst, due to their broad interests. I don’t doubt that it would have taken longer to happen had they not been involved (though what “involved” means is fiddly, given that being deliberately not-involved would act as a significant retarding force, given the popularity of their browser), but I do believe that it would still have happened eventually.

(The word catalyst isn’t quite right because Google took part in the reaction, but it’s the closest word to what I want that I can immediately think of.)

“Oxidizer”, perhaps? ;-)

The GP got the facts wrong, but IMO we shouldn't dismiss the sentiment. In particular:

> You are yearning for the simple and inefficient days of yore

The simpler our systems are, the more we can understand them, and the more reliable we can make them. And more often than not, a system that's simple from top to bottom, and kept as small as possible, is efficient. Yes, I do kind of miss the days when HTTP was understandable enough that I could write my own HTTP server directly on top of a TCP socket API. TLS is a necessary evil to protect users from bad actors, but I'm not so sure about HTTP/2. In one of my Rust projects, I just switched from reqwest to ureq (yes, partly prompted by this discussion), and saved ~600K in a release build (already optimized for size). That's 600K of removed code that can't cause bugs anymore. And I know that in my particular use case, HTTP/1.1 will be good enough.

It’s worth noting that HTTP/2 is only a part of the difference there—reqwest is generally designed to spend more code on better correctness and performance and starts with async, whereas ureq is designed for simplicity and is synchronous-only, which all tends to lead to less code. For the point in question, it would be interesting to compare reqwest minus HTTP/2 support, or ureq with HTTP/2 support.

On the matter of reliability: I’d honestly expect HTTP/2 and HTTP/3 to end up more reliable than HTTP/1 (my guess is that HTTP/2 probably already is, but HTTP/3 won’t be just yet), because binary protocols require more careful implementation and generally leave much less room for bad implementation, whereas text protocols are simple enough that the average quality of implementation is much lower (because barely-skilled developers can make something that mostly works without even looking at the specs).

> text protocols are simple enough that the average quality of implementation is much lower (because barely-skilled developers can make something that mostly works without even looking at the specs).

And to be fair, the HTTP server that I did in fact write as a teenager in the late 90s (in the MOO programming language) was firmly in that category. I'm sure my mild wishing for those days is just nostalgia.

>replace TCP with vague promises of pushed resources

Server Push was introduced in HTTP/2. TCP was replaced later, in QUIC and HTTP/3. The goal of replacing TCP was not to improve Server Push. Chrome never even implemented Server Push for HTTP/3.

Disclosure: I work at Google but not on Chrome.

Even without Push, HTTP/2 is ridiculously faster than HTTP 1.1. Removing the parts that didn't work hardly seem like "overengineering". In fact, it's the opposite.

Well said. HTTP/1.1 or below is HTTP for the people, mostly developed by academia not "tech" companies or their service providers, e.g., CDNs. HTTP/2 and 3 are HTTP for "tech" companies and their service providers.

If the technical limits of HTTP/1.1 limit the amount and effectiveness of online advertising and behavourial tracking, or if it limits the amount of time people may potentially waste on the "interactive" attention-grabbing www, then that is a benefit, IMHO. To put it another way, if the technical deficiencies of HTTP/1.1 limit the viability of "tech" companies then this is a benefit, because "tech" companies are responsible for attaching surveillance to commercial and recreational web use that I would prefer not to support.

HTTP/1.1 and below were for a less commercial web not controlled by Google.

You want websites to load slower and be worse to stick it to tech companies?

Websites "load" very fast for me because I do not use Chrome. I retreive data/information from the www without running Javascript, processing CSS or auto-loading resources. I have no trouble making online purchases, conducting online banking, etc. with a popular browser when that is necessary. The only regret is having to use a browser controlled by an advertising company (or supported by one) for those tasks. HTTP/1.1 works great for me.

I hope you realize what you do is extremely uncommon and that "the people" don't want the web to be like that where there is no styling, no images, no videos, limited interactivity, etc.

Hey at least they’re killing it. Which would be, under the frame you’ve laid out here, a kind of progress?

>The effect being to derail most F/OSS HTTP libs, web servers, and TCP/IP stacks due to sheer complexity and conflicting goals.

If you're trying to imply HTTP/2 and HTTP/3 have this goal, then I am glad you are not writing any HTTP libraries. I am sick and tired of everyone rolling their own shoddy, incomplete HTTP/1.1 libraries with string splitting and regex. I safely assume any HTTP library that does not support at least HTTP/2 is exactly this.

I'm glad the "complexity" of HTTP/2 and HTTP/3 means less people are trying to make a half-assed implementation. By the time you get to actually sending stuff with HTTP/3, you'll be deep enough that you won't just forget the whole 3xx series of response codes.

This seems like a weird argument to make: complexity of a spec as some kind of gatekeeper to prevent people from rolling their own implementation?

The fact of the matter is that these people will probably still not use HTTP/2, but rather stick with their broken HTTP/1.1 implementation, and therefor forever requiring browsers to support this.

Nit: I think you mean FUBAR. :)

On a technology forum, `foobar` seems like an appropriate replacement.

Reply on news.ycombinator.com