Complicated protocol, unfriendly to hackers, offering huge corporation some millisecond savings to enforce their walled garden supremacy.
Example: I run a service without a CDN, but I only host it on dedicated servers located in Europe. Per-request latency is OKish for users in the US, but my service makes dozens of subrequests to the same origin when loading pages (images, XHR calls). Without HTTP/2, the user-experience for US customers would be abysmal and I'd be forced to reach for a CDN which has a PoP closer to them.
HTTP/2
Besides the performance improvements brought in HTTP/2 via compression of headers and ability to multiplex streams it also enables full-duplex communication (à la WebSockets) [1]. This is used for example in gRPC, making the protocol far more versatile than given credit.
[1] No, I'm not talking about Server Push.
HTTP/3
HTTP/3 should bring benefits in wireless connections where TCP disconnections are frequent. QUIC handles connection identification so frequent TCP disconnects or even changing IPs would impact much less an HTTP/3 connection. I don't have the benchmarks but I would expect HTTP/3 to shine in this scenario which is bound to be more and more relevant with mobile devices, 5G, etc... In ideal, wired network, conditions HTTP/3 is probably not going to bring any improvement maybe even worse performance considering how much effort must have gone to optimizing TCP.
For me, both upgrades have a raison d'être but that doesn't mean that they displace HTTP/1.1 of all use cases. If you don't care about the performance improvements or need full-duplex no need to use HTTP/2, if you are not targeting mobile networks no need for HTTP/3. Luckily protocol negotiation should be quite seamless.
On top of that, HTTP/2 itself can do full-duplex communication so it can be used as a replacement of WebSocket, no negotiation or protocol upgrade involved. This capability is rarely used though but is, for example, leveraged by gRPC which is able to do bidirectional streaming [1].
millisecond savings for all their users, which adds up to saving man-years every day. It is literally preventing people wasting lifetimes of effort looking at loading spinners.
If you can do better, propose it, but don't force other people to waste lifetimes of effort otherwise.
It had major benefits like pure text protocol, that one could use even by doing telnet to webserver (I did that when I needed to debug some pesky issues), starting with HTTP 2.0 it all goes to binary protocol (there is a text one, but almost no browser supports it :( ).
And now, on top of that replace years of performance tuning TCP out of the window and use UDP, and invent TCP features on top of UDP.
Yes, it is faster (few percent, this is not a 50% increase, it is a mere 3%), but the benefits will be reaped by the largest of corporations.
Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not.
I was expecting HTTP 3.0 to get us huge benefits, but the numbers that were posted few days ago in hacker news are so underwhelming that I just don't care for it at all.
And cost of development is high.
When HTTP 1.1 fails, your browser shows you a proper error message. When HTTP 2/3 fails, it is always "a protocol format violation". What violation? Why? Who knows.
> I don't agree that this particular concern is large enough to slow adoption
Sure thing. Kerberos is still alive and kicking. SMB 1 is built into every appliance. SOAP is the protocol of choice for corporations...
Complexity never slows down adoption of <insert name of utter turd technology>, because such technology is generally being pushed down people's throats by someone else. If Google does not push HTTP 3 slower, it's adoption won't slow down. The quality of tech plays no role in that.
A protocol format violation notice could tell you what was wrong it just hasn't been developed to the full extent to do so. Give browsers and tools time to develop and be built to properly debug the connection.
If the users see the benefit then the companies that the developers work for will find a new competitive advantage, which benefits the developers (higher profit, better job security, etc).
It's impossible for one group to benefit without the other group also benefitting.
What isn't?
But you're also ignoring the fact that these benefits will also be reaped by end-users - and more by people who have poor connections to the Internet.
>Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not.
The Internet is for End Users,[0] not for developers. UX >>> DX.
And I wrote that big corporations, because those have millions of users, if users download faster then they can server even more users on smaller amount of hardware. 3% less hardware, that might be big if you are big.
And considering it is developed by Google and pushed into Chrome they will get that benefit sooner than others.
But to consider those rare instances to be equal or exceeding the value of a significant across-the-board performance increase is ridiculous. As are your attempts at populism: even against specific arguments how the benefits are more meaningful for smaller websites, you repeat the assertion that “the benefits will be reaped by the largest of corporations”. At least you have the decency to immediately contradict yourself.
Extraordinary claims require extraordinary proof.
Thanks
I think we’d see faster websites more often if developers had worse computers, or they invested more time in testing in resource constrained environments. I really don’t think react (or similar) is the core problem.
There's already a "browser platform framework", it's standard, built into your browser and very fast.
Trying to re-implement the browser inside the browser using Javascript is a recipe for disaster. (Indeed: witness the "modern" web.)
I get that something more enterprisey-feeling with more knobs for programming in the large is more agreeable to the assembly-line programmer in large IT shops, but if you want your browser apps to act nice you'll have to suck it up and program natively without the overhead of a framework.
I think this is quite an important point. If the protocol is so complex such that creating custom implementations is prohibitive then that's an issue, and also perhaps a 'smell'
I had enough weekends wrecked by someone thinking they can implement HTTP themselves, only to find out that no, they couldn't, and that was for cases that didn't even hit corners. A netcat "HTTP server" demo is cute, but the power of the computer is that we make tools to make tools that can cover things like HTTP/2 reasonably fast - and much more correct.
If I find someone's "quick and dirty HTTP client library", I generally lose hope that redirects are handled. Anything more complex than that (and there's a lot!) is pipe dream.
Simple doesn't always mean better.
The text nature makes it easy to implement a broken client or server in a hobbled development environment, yes. It also creates a legacy of brammage that is impossible to fix without significant break in protocol like HTTP/2 is.
Shortly speaking, Postel's Law Considered Harmful (in network protocols, at least)
Isn't also HTTP/3 a significant break in protocol compared do HTTP/2 ?
OSI stack is better, but usually you'd build on top of higher-level components of it, not "supposedly text but honestly binary" protocol like HTTP.
Being YOLO resulted in it taking over 15 years for email to not have random crashes involving my native language (and it's pretty simple, as it has no multibyte requirements).
YOLO is how the internet has been broken through multi-level NAT, because ca 1980 someone convinced other that for "temporary test deployment" only 32bits will manage.
YOLO is why transition to IPv6 takes ages even when higher level protocol wouldn't even notice, because ~1983 in panic someone made an emergency, student-made port of TOPS-20 TCP/IPv4 interface and we're left picking the pieces forever.
And yes, HTTP and other "text" protocols are essentially binary protocols, because you end up dealing with whatever binary constant form someone put into client/server code. If someone goes too far into treating it as text when sending, suddenly you have a problem of dealing with missing record terminators. Standard header names could be just as well binary, except there's extra variation both possible (if you want to follow Postel's law), and spec (details of encoding).
I've always appreciated that most IETF protocols are text-oriented with line-buffered commands, and the option to speak the protocol directly in this fashion contributed enormously to my own understanding of SMTP, POP3, IMAP, IRC, NNTP, HTTP, FTP et al, and I always regretted not being to do the same with LDAP, SNMP, or BGP.
I recommend that internal network services use HTTPS, there's plenty of reason not to lower your standards internally.