> I would have preferred if the author gave a way deeper answer of this rather important question.
Like the paragraghs that come after it?
Like the paragraghs that come after it?
In fact the real answer is hidden here:
> If you need something that works "out of the box" with common server setups, and with broad web client support, WebSockets is a better choice today.
Given that the article emphasizes it supports reliable and unreliable modes, seems to me that the overarching goal is "single interface for everything that's not /HTTP\/[12]/".
Maybe it's just that QUIC is slightly better than TCP/HTTP.
Probably the real Google reason is "make another thing that Apple and Mozilla have to build", and "eventually they'll die or move to Chromium".
The objective is to make a websockets equivalent for HTTP/3 which can take advantage of h3’s features. The headline features are UDP support and proper multiplexing with other parallel requests.
It’s like websocket but it works over h3 and optionally unreliable. And it’s faster.
And it’s sort of like webrtc data channels but it’s much more “webby” - it’s server-client not p2p. It works over http, and it’s not a huge inconsistent mess.
https://web.dev/webtransport/#is-webtransport-a-replacement-...