“So, Is WebRTC Old or New?”
Asked a Curious Student
📚 Connect with us. Want to hear what’s new at The Pragmatic Bookshelf? Sign up for our newsletter. You’ll be the first to know about author speaking engagements, books in beta, new books in print, and promo codes that give you discounts of up to 40%.
I’m teaching my WebRTC course again this fall. The version of the course I taught a year ago ultimately led to the proposal for my book Programming WebRTC:
My favorite thing about teaching is engaging student questions. Tricky when you’re teaching a classroom full of developers who’ve somehow gotten the idea that questions are a sign of ignorance (they’re not) rather than a sign of curiosity and intellectual depth (100% are).
Thankfully I have some really curious students this semester. Not midway through the second class of the semester, a student asked point-blank whether WebRTC is old or new technology. Fair question!
WebRTC From Draft to 1.0 Spec
On one hand, the earliest technical foundations of what we now know as WebRTC can be traced to Google’s acquisition of Global IP Solutions in May of 2010. So it’s old, in internet time.
On the other hand, the WebRTC 1.0 specification did not become a W3C recommendation until January 2021, barely eight months ago as of this writing. That means it’s new, right?
From that perspective, sure — but keep in mind the earliest WebRTC working draft was posted just before Halloween 2011. So, back to old. The W3C specification is focused on APIs exposed in the browser, and generously references numerous RFCs governing WebRTC’s underlying protocols developed by the IETF RTCWEB group, which itself was chartered in 2011. Those protocols, too, have a storied, decade-long history of development.
It’s All in the Browser Implementation
All fine neckbeard-grade trivia regarding recent technological history — but none of it matters much for web developers coming to WebRTC in 2021. The most important thing about a completed specification is that it becomes the authoritative source to compare errors and weird browser behaviors against. That’s an absolute necessity when debugging your own app and filing bug reports, of course. A specification in flux — a W3C working draft or editor’s draft, even a candidate recommendation — is subject to change.
But the source of errors and weirdness is not often a specification in flux so much as the implementation of a specification in actual browsers in use.
And it’s implementations that muddy the WebRTC-development waters and have probably contributed to web developers keeping WebRTC at arm’s length or further for so long.
Like any Web API, WebRTC is not implemented perfectly in any browser — nor uniformly across any two browsers, either. And despite all-too-common lore, no, you don’t have to force users onto Chrome to use a WebRTC app. Even Chrome has yet to implement a key feature for RTCDataChannels — the Blob binary type — and it, therefore, continues to deviate from the specification by initializing to the ArrayBuffer binary type when opening a new data channel.
But the WebRTC specification doesn’t just outline the properties and methods of WebRTC’s core browser APIs: it also suggests example patterns for orchestrating them. Most critical of all of those is the perfect-negotiation pattern. Of course, the perfect-negotiation pattern fails — hard — in browsers that haven’t properly implemented the APIs and WebRTC state-machine as outlined in the spec. That includes older browsers still in circulation, but also the most recent versions of Safari across all Apple platforms.
I try hard to show in Programming WebRTC that you can still gracefully work around broken and incomplete implementations and produce a WebRTC app that does everything expected of it. Your app can stream audio and video, yes, but can also open channels for secure, peer-to-peer transmission of arbitrary application data. That includes working around Chrome’s lack of support for the Blob binary type.
The Final Answer: Old and New
The fundamental, timeless truth of web development is that our technologies are always both old and new. Web development is unique for many reasons, but I’d argue its most unique feature — or bug, depending on your perspective — is that web developers have zero control over the run-time environment once their work has left the server.
With WebRTC, in a true peer-to-peer connection, there is no server!
Sure, we often exactingly control our own run-time environments by doing initial development on the latest version of Chrome or Firefox nightly, referencing documentation and maybe a finalized W3C specification as we go. But then it’s necessary to do a bit of time travel and start picking up on the idiosyncratic and profoundly weird implementations on old but still-circulating browsers, too.
What are your thoughts and questions? Have you done something interesting with WebRTC? Please share in the comments.
Are you ready to experiment with WebRTC? Pick up Karl Stolley’s book from The Pragmatic Bookshelf. Now through October 31, 2021, you can save 35% on the ebook version of Programming WebRTC (now in beta) using coupon code webrtc_medium_35. Promo codes are not valid on prior purchases.
Stay in Touch
A great way to stay in touch with The Pragmatic Bookshelf is to sign up for our newsletter. You’ll be the first to know about new books for programmers, books in beta, and promo codes that give you discounts of up to 40%.
