WebRTC is lowkey one of the most underrated technologies out there, ESPECIALLY WebRTC data channels.
WebRTC data channels are basically “UDP on the web” but they have lots of controls to change how reliable they are, so they can be used as TCP style connections as well.
I still don’t fully understand why more people don’t use them over something like QUIC. (I think I’ve asked this question before here, but I wasn’t really satisfied with the answers)
I sadly switched off of using them, but mostly because the ecosystem around there is super underdeveloped compared to the ecosystem around QUIC/quinn. There is a LOT of boilerplate involved that feels unnecessary.
But, if you’re making a multiplayer game in the web, it’s basically the best technology to use cuz it already works. And if you use a library like libdatachannel or pion, you could make the game in Go or C++ and compile it for both Steam and the web!
I am so happy that WebRTC has so many implementations. Every developer thinks differently, it's good to have a implementation that matches your mindset.
Sadly, SipSorcery is lagging behind as of now. We only have H.264 and VP8 support for video, data channels only have partial implementation (only reliable ordered), and the performance of data channels is far from what it could be.
But it is a great starting point for anyone working in C#.
Unfortunately, there's massive drift between WebRTC implementations. The status quo is Google's, which is used by Chrome: https://webrtc.googlesource.com/src/
And everyone else has to play catch-up.
A big source of the drift is having a common library for SDP parsing, but also necessary features like BWE, different encodings, etc.
For example, aiortc, python's WebRTC implementation, isn't quite at the level most would want. It isn't necessarily easy to tell, without clear benchmarks, which implementation is at-par with Google's.
Why do you consider it the status quo? It isn’t used in servers, embedded devices or software like OBS. Yes it’s popular because of usage in Chromium/Mobile, but I don’t believe that qualifies it as status quo.
aiortc is good enough to empower lots of businesses/projects! If anything comes up that really is a show stopper it will get addressed.
> I still don’t fully understand why more people don’t use them over something like QUIC
Dealing with NAT traversal especially with full-cone NATs is difficult and expensive - you have to maintain dedicated infrastructure of TURN servers for NAT and you have to proxy all your traffic through that, it's quite the overhead, especially since IPv4 addresses and bandwidth on AWS don't come cheap.
The horrible boilerplate and complexity is why people don't use it. Getting even simple usage examples seems to be a tall order for some use cases and LLMs are hopeless in trying to help with it.
P2P connections are also often blocked by ISPs for whatever reason, making it impossible to use without a fallback TURN server which defeats the entire purpose of the thing if you wanted to do scalable multiplayer without the server infrastructure. You're left sending over the whole stream with double the latency and have to eat all the bandwidth.
I have been working on a quic/webrtc application for a while, webrtc capabilities are severely underrated since everything pairs it with TCP signaling defeating the power of webrtc
My experience is WebRTC has an on-ramp problem, which this is partly to address, but it is significantly helped if you are thrown in the deep end to work on it with someone that knows the quirks already. The big thing I got from that process was to stop being afraid of reading the SDP, because a huge amount of the problems you will run into are really the result of SDP oddities. It is credit to people like the libwebrtc maintainers that the complex morass of MediaStreamTrack processing is as solid and performant as it is these days. (And extendable).
I share the view that it should form the basis of real time communication, humans involved or not, and a/v media involved or not. There seems to be some progress on applying absolute timestamps to frames, for example, however, at some point if we want to have rocket ships using it (and I do too) we will eventually need to have some way to reconcile divergent clocks used at different sources!
Sean is modestly not mentioning Pion here, which is the lower level library many golang people reach to for webrtc components, and deservedly so.
For JavaScript developers "simple-peer" npm package is very popular and makes WebRTC very simple. I don't think its' an on-ramp problem, holding it back, it's just that most apps don't necessarily benefit from P2P coms, and also I'd hazard a guess not many people know about WebRTC, yet. Just guessing.
In JS it's amazingly easier because of how you can just await on peerconnection calls, which makes developing the happy path version of the code much faster, that can then be progressively extended with proper error handling.
My experience of it in Java/C++/Golang is in every case you have to deal with all the problems far more upfront before any of it works at all. And JS doesn't have the multithreaded aspect to handle, which is also the major weakness as it eliminates the extensability in that environment.
I have a sort of proof of concept level SFU in golang, with a simple TypeScript/React client, and the whole client is this: https://github.com/atomirex/umbrella/blob/master/frontend/sr... and most of the complexity there is because I can never remember if track ID or transceiver MID should be used in different situations!
That's some pretty impressive multimedia stuff you've got there! All I know how to do is a basic P2P chat room...and the most advanced thing about it is file attachments!
Thanks, but in truth the media stuff here isn't the difficult bit as the state of webrtc in 2025 means it's really just a question of shuffling byte buffers around in time. It's really libwebrtc and the browser integrators that deserve the credit.
I have done native mobile libwebrtc work, and that's several other levels of complexity from all this, but with that you can do things like hardware accelerated neural net integration quite easily because of how it's all structured.
I'm new to this and Claude AI talked me into using 'simple-peer' as my library (NPM package) even though the browser's native WebRTC API was almost identical code. I'd be interested in your opinion about what API to use for just a chat app, that does file-sharing. In other words it will be sending around byte buffers (files) as part of the JSON objects. I haven't looked up libwebrtc yet. My WebRTC started as a "Vibe Coding" session last week, and since the results were so impressive I kept on developing it into a full-blow chat app, just for kicks.
So, I am not familiar with "simple-peer" but there are some definite inter-browser quirks relating to datachannels which it might be taking care of.
I seem to recall one browser always prefixes the buffers with sequence numbers, for example. Really fun stuff like that, but I would hope that is history by now.
My preference would be to use the standard webrtc api, and then use a polyfill style library for uniform behaviour if you don't want to worry about it (which it sounds like simple-peer might be).
In the event you want a much higher level API and pre-rolled signalling server etc. my go to recommendation on that would be https://livekit.io/ which I am not affiliated with, but I tend to think people starting out should try that and then be able to explain why they're not using it, much in the same way I would expect a game dev to try using Unreal and have a good reason if they aren't planning on using it.
Right, thanks. Appreciate the advise. I'm a big fan of using whatever libraries there available, in all contexts, as long as I'm using the "dominant" one. I always stick to whatever's most popular because it will be well supported, less buggy, have easily findable documents and resources the web, be "known about" thoroughly by LLMs, etc.
I was a C++ dev all thru the 1990s, but moved to Java, JS, Python. There's really no good argument for using C++ nowadays in 99.999% of apps. Unless you're doing something VERY special like realtime stuff, or something where each action of the CPU needs to be controlled directly, you just don't need it. I'm sure you know that, tho. Not preaching at you. I learned Python as recently as 2023, just so I could get deep into the AI landscape and access all those libraries/tools.
WebRTC's complexity can be frustrating. I believe it is inherent to how many things it is trying to solve. If an alternative arrives that solves everything WebRTC does, it will end up being just as complex.
WebRTC is amazing! I think it might be helpful for some younger folks if you talked about UDP, I realize it's maybe a bit "weird" - however coming from the UDP world helped me think about all the ways WebRTC can be used. I think it's one of the most underrated and underutilized technologies.
I cannot thank you enough for writing this; the very first page with the "What, Why and How" is precisely what I wish were written for every "thing" I have ever worked with. It's so clear, and contextualizes so much so quickly, I'm frankly in awe. Thank you for your contributions!
I think the 'What, Why and How' captures the purpose and joy of learning. Nothing is better then getting lost in a fun problem. I don't want to just understand how it is solved, but the story about how it got solved.
If you have any feedback on how the book could be better would love to hear!
I like this book, but it doesn't contain any code examples, so it wasn't useful to me.
I ended up adopting code from the High Performance Browser Networking book and some code examples by Google that were written like 8 years ago. It was painful to replace the outdated APIs with new ones and rewrite in TypeScript, but I eventually did it.
The book is vendor agnostic. I wanted it to be timeless and vendor agnostic.
The lack of code made all publishers I approached reject it :( I would love to see a hard copy someday.
I had hoped if I put no code in it the WebRTC community would feel more comfortable with it. If I made it Pion specific, would greatly reduce its reach.
For all those into WebRTC, I just ran across this Reddit topic (link below), and the very latest post is one about a Chat App that was apparently just completed last week:
It mentions Nostr, and makes me realize both Nostr and WebRTC can work well together. I haven't checked, but I'd guess there are Nostr apps using WebRTC to send Nostr messages around. I mean Nostr is basically just a crypto-signed JSON object.
To my knowledge, most regular web servers either cannot speak DTLS at all or only have limited support for it, but all modern browsers work with it just fine for WebRTC.
WebRTC data channels are basically “UDP on the web” but they have lots of controls to change how reliable they are, so they can be used as TCP style connections as well.
I still don’t fully understand why more people don’t use them over something like QUIC. (I think I’ve asked this question before here, but I wasn’t really satisfied with the answers)
I sadly switched off of using them, but mostly because the ecosystem around there is super underdeveloped compared to the ecosystem around QUIC/quinn. There is a LOT of boilerplate involved that feels unnecessary.
But, if you’re making a multiplayer game in the web, it’s basically the best technology to use cuz it already works. And if you use a library like libdatachannel or pion, you could make the game in Go or C++ and compile it for both Steam and the web!
Here’s a project I did with them that shows off compiled for both web and desktop: https://github.com/ValorZard/gopher-combat