Hacker News Reader

> Unreliable datagrams? WebRTC

It's was an interminable wait for WebRTC data channels.

Is there a trivial way to get a WebRTC connection to a server now, without pretending that server is a peer and doing the whole handshake dance?

Yeah I just wanted to do a client-server app on a UDP-like socket, but WebRTC had so much complexity that it put me off.

It's gotten better now, but WebTransport is the solution we've needed for a while.

Do you still see challenges with doing WebRTC on a server? I work on https://github.com/pion/webrtc so would love to hear what could be better :)

We’ve done some cool things with Pion, like running GIMP server-side and streaming it to a browser[1]. So thanks!

I’m not the one who worked directly with Pion so I don’t have direct feedback on it, but one thing I think would do a lot of good for WebRTC data channels becoming widespread is client and server nodejs bindings that abstract away all the complexity so that it is as easy as using websockets. If developers could implement this stuff without having to learn acronyms like TURN and STUN, I think it could be pretty popular.

[1] https://twitter.com/drifting_corp/status/1552773567649091584

And are you going to run a dedicated signaling service and do all that STUN karate to just connect the peer to a publicly available server?

> dedicated signalling

For my small projects I run my HTTP + WebRTC in the same server. My signaling is one POST. Maybe I am missing the complexity, but I don't feel any additional pain compared to running any network service?

> STUN Karate

Mind explaining more? You don't use STUN for connecting to a world routable host.

If you need it I use https://github.com/pion/turn and run my STUN server embedded in my HTTP server. I do do anything but point my `PeerConnection` at `my-service.com`

What I mean is that compared to, for example, WebSockets and WebTransport, WebRTC is more difficult to use (not through third-party libraries but "native" WebRTC data-channel API). But you are right and I was wrong, STUN is not necessary.

God, I wish I could find something like this for .NET.

You don't need STUN to connect to a publicly available WebRTC server.

I don't know of one. In my remote browser app where I stream the remote browser viewport over webRTC I just use simple-peer on the server and exchange connection info over websocket. It works well.

But then I test every xth frame to see if the peer or the socket is faster and switch to that. Websocket is often faster, but not always, so in practice I end up splitting the stream over both websocket and webrtc in real time.

> There seems to be not too much interest in or hype about WebTransport.

I feel like this is partially because the main value of the API comes from working better on lower-quality networks, rather than providing the ability to do something completely brand new.

> FF and Safari don't support it yet.

For what it's worth, Mozilla are positive about it [0] and are actively involved in the standards process. I don't believe the WebKit team has stated their position, though there are Apple people who are involved in the standards process too.

> I think it's missing a killer app. But I am not sure what WebTransport would enable that isn't already possible with current APIs.

When we started out working on WebTransport, there were two major use cases we had in mind: live media and web games. IETF MoQ working group [1] will hopefully address the first one. I don't know whether anyone is using it for building games, but I don't actually have that much visibility into what's going on in that space.

[0] https://mozilla.github.io/standards-positions/#webtransport [1] https://datatracker.ietf.org/wg/moq/about/

> Chrome on Android doesn't either

Interesting, do you have a source? Or did you try it?

> I am not sure what WebTransport would enable that isn't already possible with current APIs. Unreliable datagrams? WebRTC. Reliable bidirectional communication? WebSockets. WebTransport probably would make some of the usecases easier or more efficient but it's value proposition isn't well communicated or better yet, demonstrated.

The article does seem to answer these questions.

Can I Use[1] gives mixed messages on this. Seems like it is either partially supported or fully supported and one of the entries is just misleading?

[1]https://caniuse.com/?search=webtransport

The information there is indeed incorrect. I have updated my comment accordingly.

  > Interesting, do you have a source? Or did you try it?

https://caniuse.com/webtransport

  > The article does seem to answer these questions.

Not for me. There's no usecase mentioned that is not possible today unless you count using it from inside a worker as a usecase I guess.

I wonder btw why they compare WebTransports datagrams to WebSockets reliable streams. The equivalent to WebSockets would be the reliable Streams API of WebTransport. The issue with Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol.

> https://caniuse.com/webtransport

Yeah, it seems there's an older entry in there that's confusing. Not sure.

> There's no usecase mentioned that is not possible today

WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods.

> Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol.

Yes, and solving it within the protocol is simpler and more efficient.

> It needs a bunch of examples

Agreed, that would be nice.

  > Yeah, it seems there's an older entry in there that's confusing. Not sure.

I have just tried it on Chrome 103 on Android 12 and WebTransport worked. The information on caniuse.com is indeed incorrect.

  > WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods.

Yup, that's why I want to see it widely supported. Any simplification is good for the web. Though WebTransport unfortunately does not improve on every aspect of the existing APIs. It also has limitations that WebRTC does not have like P2P or easily piping media for using in MediaStreams.

> There seems to be not too much interest in or hype about WebTransport. FF and Safari don't support it yet. MDN does not contain a single mention of WebTransport.

Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin"

Well, it’s been in the works for years (since at least 2019 from recollection). It’s made it’s way through the IETF and W3C, and it’s been implemented in Chrome and Edge since the start of the year.

It won’t see adoption until firefox adopts it and HTTP/3 starts gaining traction. But I’d say it’s a lot further along than the “coffee stained napkin” stage. It’s older than covid.

> Well, it’s been in the works for years

So?

> It’s made it’s way through the IETF and W3C

It's status at W3C is "editor's draft"

> and it’s been implemented in Chrome and Edge since the start of the year.

Which makes it a Chrome-only non-standard.

> It’s older than covid.

Ah. The new definition of standards I see. The only thing that matters is how long it's been in development. Not the checks notes reality and the actual standards track.

> Ah. The new definition of standards I see. The only thing that matters is how long it's been in development. Not the checks notes reality and the actual standards track.

There's a process to get features like webtransport into browsers and available everywhere. The process started with some proposals at W3C, continued with some discussions and specs being written up at both the IETF and the W3C. The work more-or-less concludes with broad browser support and applications being written using the spec.

The process takes years and its nearly complete. Webtransport has been in the works since at least 2019. Support has landed in Chrome and Edge. Hopefully we'll soon see the spec be ratified, get implementations in Firefox and Safari and then we can start using it in production software.

You said:

> Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin"

We've come a long way from "a draft on a coffee-stained napkin". A draft on a coffee-stained napkin wouldn't have shipping code in Chrome. Just because you can't use it yet in Firefox doesn't mean there hasn't been a helluva lot of work put into making WebTransport come to life so far, from a whole lot of people who have done a lot more work improving the web than most of us will ever know.

> To be clear: I like WebTransport and want to see it supported widely

Given all you've said, why? Why do you like it? I am trying to understand its purpose but you haven't really articulated its value proposition either. How could it have value if there are better alternatives to both things it offers?

Good question :)

When it comes to reliable streams and WebTransport vs WebSockets I really don't see much improvement. Where I do see a simplification is when it comes to WebTransport vs WebRTC data channels. It's just a simpler API and protocol.

Even reliable streams benefit from webtransport.

Right now (as I understand it) WebSocket is HTTP1.1 only - which means if you’re using HTTP2/HTTP3 and want to use websockets, the websocket connection will create a separate TCP connection just for WS. This is slow to start - both due to needing another handshake and TLS dance. And you can run into a bunch of problems due to per-domain browser connection limits.

Reliable streams over webtransport will solve these problems. They’ll be faster, more reliable and a better fit for HTTP/3.