> Using WebTransport [...] means that you don't have to worry about head-of-line blocking, which can be an issue with WebSockets.
I'm gonna go out on a limb and say that head-of-line blocking is not what prevented wider adoption of Websockets.
> Additionally, there are performance benefits when establishing new connections, as the underlying QUIC handshake is faster than starting up TCP over TLS.
Huh? This isn't a problem for HTTP/3 in general, because there's only a single quic connection (as long as you're talking with a single endpoint). So creating new Websocket streams should just create a new quic stream within the same connection transparently – I mean... this is the main point of HTTP/3. This sounds like an argument against adding another almost identical standard. Can someone explain?
If they want datagrams (which I can kinda understand), why not just add that as an extension to the Websocket spec?
I'm gonna go out on a limb and say that head-of-line blocking is not what prevented wider adoption of Websockets.
> Additionally, there are performance benefits when establishing new connections, as the underlying QUIC handshake is faster than starting up TCP over TLS.
Huh? This isn't a problem for HTTP/3 in general, because there's only a single quic connection (as long as you're talking with a single endpoint). So creating new Websocket streams should just create a new quic stream within the same connection transparently – I mean... this is the main point of HTTP/3. This sounds like an argument against adding another almost identical standard. Can someone explain?
If they want datagrams (which I can kinda understand), why not just add that as an extension to the Websocket spec?