Hacker News Reader

Comment by smaddock | Hacker News Reader

I use WebRTC and WebSockets in a side project of mine [0]. WebRTC requires coordination of multiple services and fallbacks (relay servers) when peers can't establish a direct connection due to firewalls among other things.

STUN, TURN, and ICE are a few technologies you need to understand to get started with WebRTC. I'd guess most folks aren't familiar when first looking into it.

The complexity is worth it if you're determined to push most bandwidth costs to clients like I am.

If you want near 100% connectivity at a lower complexity, WebSockets are almost always preferred.

[0] https://github.com/samuelmaddock/metastream

View on HN

Additionally, during the 3 years I've had experience with WebRTC, I've come across at least 2-3 browser bugs causing compatibility issues when connecting peers cross-browser.

This is just not something you run into with WebSockets.

I'd recommend simple-peer for anyone who does choose to use WebRTC. The maintainers are usually able to smooth these issues out in a reasonable timeframe. <3

https://github.com/feross/simple-peer

I don't think the issues with WebRTC is the protocol, but the tooling. The community did a really good job of creating tooling for Websockets with stuff like https://github.com/crossbario/autobahn-testsuite. There is nothing like that for WebRTC.

We tried to do it, but the IETF event was cancelled https://twitter.com/steely_glint/status/1230447935307026432. I am hoping that in the next 6 months we can have something like that so that all the WebRTC implementations will work together a lot better.

I guess my question wasn't clear; why would they create a new seemingly unrelated spec to try to try to bring WebSockets up to where WebRTC is rather than just add the little tiny signalling bit to WebRTC? (Particularly since people are also simultaneously trying to bring QUIC transports to WebRTC data channels?) We shouldn't be maintaining so many separate protocol stacks and APIs in the browser. (Context: I use WebRTC in my day job, not as a side project, and have been working with it for years now ;P.)

The effort to bring QUIC to WebRTC is the kind of the same effort. The WebTransport is an outgrowth of that effort. They are not unrelated.

As for "too many protocols": QUIC is already in the browser. This is just giving you an API to it. Think of it like WebSockets for the HTTP3 world.

Reply on news.ycombinator.com