3 ms·

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

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.

trasz 4y ago
>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?
- chrismorgan 4y ago
  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.)
  - trasz 4y ago
    “Oxidizer”, perhaps? ;-)
mwcampbell 4y ago
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.
- chrismorgan 4y ago
  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).
  - mwcampbell 4y ago
    > 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.

trasz 4y ago

>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?

chrismorgan 4y ago
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.)
- trasz 4y ago
  “Oxidizer”, perhaps? ;-)

mwcampbell 4y ago

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.

chrismorgan 4y ago
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).
- mwcampbell 4y ago
  > 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.