I grep'd for
websockets
the first line is:
> Is WebTransport a replacement for WebSockets? # Maybe.
Seriously? You start with maybe? I would have preferred if the author gave a way deeper answer of this rather important question.
> Is WebTransport a replacement for WebSockets? # Maybe.
Seriously? You start with maybe? I would have preferred if the author gave a way deeper answer of this rather important question.
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.
https://web.dev/webtransport/#is-webtransport-a-replacement-...
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.
1. Whether you use the Streams APIs (suitable for WebSocket use cases) versus the datagram APIs (not suitable as a general replacement).
2. The standard is relatively new, so the WebSocket ecosystem is currently more mature.
I would be more concerned if the author glossed over those fairly important distinctions to say “yes”.
If you use WebSocket, you are stuck with streams. You can migrate those to WebTransport. Then you also have the option of datagrams if those make sense for you.