It even has mention as being the spiritual successor to WebSocket for certain cases in mdn docs:

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...

"if your application requires a non-standard custom solution, then you should use the WebTransport API"

That's a pretty convincing use-case. Why use something standard if it can be non-standard custom instead!

Your projects require holistic and craft solutions. Simple, working ways are the wrong path!

WebTransport is great but it's not in safari yet.

> No need for WebSockets there as well. Check out WebTransport.

Isn't WebTransport basically WebSockets reimplemented in HTTP/3? What point where you trying to make?

> Isn't WebTransport basically WebSockets reimplemented in HTTP/3?

No.

> No.

Thanks for your insight.

It seems you need to urgently reach out to the people working on WebTransport. You seem to know better and their documentation contradicts and refutes your assertion.

https://github.com/w3c/webtransport/blob/main/explainer.md

He said "basically" which should be interpreted as "roughly"? Then it seems his assert is roughly correct?

Maybe? Isn't WebSockets basically TCP? Roughly? I wrote that WebSockets provide reliable bi-directional streams, but it actually doesn't. It implements message framing. WebTransport also doesn't support "unreliable streams", it's actually called "datagrams". WebTransport doesn't even have to be used over HTTP/3 per the latest spec, so is it basically WebSockets reimplemented in HTTP/3? No.

> (...) but WebTransport also supports unreliable streams and a bunch of other things.

If you take some time to learn about WebTransport, you will eventually notice that if you remove HTTP/3 from if you remove each and every single feature that WebTransport touts as changes/improvements over WebSockets.

Last time I've checked none of the common reverse proxy servers (most importantly nginx) supported WebTransport.