What worries me is that some people involved in standardisation seem to be of the opinion that WebTransport supersedes WebSocket. WS has become my go-to transport when I just need to be able to reliably send messages back and forth, whether or not the web is involved at all, and I don't see WebTransport as a replacement for that use case. I hope WS sticks around forever.
Also, it's messed up that WT is only available in HTTPS. There are so many cool use cases for web technologies in local contexts where HTTPS is not a practical option, it's a shame most new technologies are arbitrarily banned from those use cases.
By making technologies available only in a "secure context", they're blocking them out of this whole category of use cases.
For the permanent installation case, it's typically easier to use mDNS domains since they're shorter. 'mediapc.local' is easier for guests to type than 'mediapc.local.mort.coffee' or whatever I'd end up with.
What would be a good solution is self-signed certificates, but that too is a non-option until all browser vendors downgrade the warning from a "Someone is trying to hack you!" style scare screen to a more informative "this is a self signed certificate, do you trust it?" style warning screen.
Gee thanks corporate overlords, whatever would we do without your cloying efforts to provide quote-unquote-"security"?
Having gone down the path of being able to just spin up "local" services that get a publicly routable (but most often firewalled off) ipv6 IPs and then good DNS integration is really neat... but still requires lots of technical chops. I wish that weren't the case
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
It's common to multiplex a WebSocket connection but you don't need that with WebTransport, while also avoiding head-of-line-blocking.
But yeah I wish WebTransport had a better TCP fallback. I still use WebSocket for that.
It doesn't imply that websockets would be deprecated by WebTransport. It's a goal to make WebTransport an easy choice.
> Also, it's messed up that WT is only available in HTTPS. There are so many cool use cases for web technologies in local contexts where HTTPS is not a practical option
WebTransport is relatively heavy compared to websockets. Once you consider all of the layers, HTTP/3, possible HTTP/2 fallback, and transports, adding TLS is minimal overhead for code size.
For contexts where setting up certificates is not practical, I assume the workaround will be to generate a self-signed certificate and then tell the client to ignore certificate validation problems.
See my response to the certificates thing here: https://news.ycombinator.com/item?id=45820782#45956556
I don’t think these are a fit for an entire HTTP/3 or HTTP/2 stack with WebTransport anyway.
WebSockets is fine for these applications and won’t be going away.
> See my response to the certificates thing here
If you don’t care about validating the certificate you can skip all of the renewals and DNS setup and everything else. The client will complain that it can’t verify the certificate against anything trusted and you tell the client that’s okay, just ignore it and continue.
If you don’t care about encryption then you also don’t care about setting up the certificate properly. You put something in there to enable the connection and then have the client ignore the fact that it’s not verified.
If your complaint is that browsers show warning signs for certs that can’t be validated and those might scare other users, that’s not going away.
As of one month ago, Java still didn't have HTTP/3 support. Though it's apparently coming in March (with JDK 26).
But yeah the HTTP/3 integration definitely makes WebTransport harder to support. The QUIC connection needs to be shared between HTTP/3 and WebTransport.
Since libwebrtc is all in C++ and 'trusted' it can do stuff like faststart or have error correction/bandwidth estimation that is codec aware.
WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.
Also, what client libraries are there for Python, Rust etc. for WebTransport? Does it work with any HTTP/3/QUIC implementation?
EDIT: Think also about webgl1/2, webgpu, webxr, websocket, webrtc, webauthn ...
WebRTC supports peer-to-peer UDP connections as well. Thus it's better for use cases like low-latency games, video calling, and secure direct communication between devices.
A better push might be to make WebRTC more simple and modern, but I'm not sure if any standards committees are working on this yet.
* RTP over QUIC is promising https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over...
Do you want a new PeerConnection API? Are you annoyed with the Offer/Answer model? Do you have beef with the protocols. The possibility are endless :)
Doesn't it require DTLS over UDP though?
It will help a ton with the low latency streaming we need to do in our eBPF based Linux performance tool. (https://yeet.cx)
ktpsns•2h ago
silverwind•2h ago
kaoD•1h ago
Messing with firewalls in what way?
baggy_trough•1h ago
CharlesW•1h ago
chrismorgan•2h ago
It’s like saying “I had a violin, why didn’t they make this new ‘orchestra’ thing behave the same way?”
If you’re willing to limit yourself to a single reliable bidirectional stream, abstracting over both WebTransport and WebSocket will be easy.
WebTransport, in its fullness, also pretty clearly depends on HTTP/3. Any implementation based on HTTP/1 or HTTP/2 (which is in progress) will lack unreliable delivery and independence of streams (due to using TCP), and possibly more features.
advisedwang•1h ago
KPGv2•1h ago
You can think about this with HTTP/1 vs HTTP/3: HTTP/3 isn't an extension of HTTP/1. It's radically different.