HTML5 Zone is brought to you in partnership with:

John Esposito edits Refcardz at DZone, while writing a dissertation on ancient Greek philosophy and raising two cats. In a previous life he was a database developer and network administrator. John is a DZone Zone Leader and has posted 320 posts at DZone. You can read more from them at their website. View Full User Profile

Real-Time for Everyone: Thoughts on WebRTC 1.0

02.15.2012
| 4427 views |
  • submit to reddit

One of the more ambitious new web technologies is WebRTC (Real-Time Communications), whose spec explains itself as follows:

This document defines a set of APIs to represent streaming media, including audio and video, in JavaScript, to allow media to be sent over the network to another browser or device implementing the appropriate set of real-time protocols, and media received from another browser or device to be processed and displayed locally. This specification is being developed in conjunction with a protocol specification developed by the IETF RTCWEB group and an API specification to get access to local media devices developed by the Media Capture Task Force.


The W3C Working Draft was published last week, which means that the client side of the project is beginning to gather some momentum. The infrastructure-side is heating up, too -- just one week before the Working Draft release, Ericsson posted an opinion piece entitled 'WebRTC: The democratization of the communications industry', which included this strongly-worded paragraph:

Do you remember a time before web pages? To do anything in IT you had to be a boffin professional with special access. Then along came the web and everybody’s child could put up a website. If you see that as the democratization of the IT industry, WebRTC is the democratization of the communications industry.


Their reasoning? Without WebRTC, real-time communication is, at best, a second-class citizen in the web development world.

The follow-up article added a chunk of technical detail, on codecs, protocols, and interoperability. And yet again, the major advantage for the developer seems to be, simply: let the standards-makers worry about everything behind the scenes. Who cares about anything else when I can just write JavaScript?

So browser-as-platform marches on. Vladimir Sedach observes:

To step back in terms of commentary, the web browser has now come full circle to being a very weird virtualized operating system, whose APIs rival Windows in size, idiosyncrasies and complexity. The need for application hosting declines...


(Read more of Vladimir's commentary for additional interesting thoughts about WebRTC vs. hosted apps.)

While a version of WebRTC had already been implemented in Chrome Canary and (partly) Opera Labs, Chrome's implementation was, until recently, substantially different from the W3C Editor's Draft -- which makes sense, I suppose, since the framework was originally developed by Global IP Solutions, which Google acquired in 2011. Now, however, the Chrome and Working Draft APIs have grown substantially more similar.

The potential of WebRTC is, as the Ericsson post noted, pretty vast. It cuts deeper than many new web technologies, and touches close on the much-vaunted 'democratization' the web -- where other trends, such as cloud-hosted Big Data ('supercomputing for the masses'), also seem to be heading. And in JavaScript, too!

If the technology grips your dev-brain, dive into the API and see what you think. Or try this page, for a schematic and bird's-eye view of the architecture.

And for much more coverage, including a useful FAQ, check out webrtc.org -- which also maintains a blog on WebRTC development (and is also supported by Mozilla and Opera, as well as Google), for status updates.

What do you think? Will you use WebRTC? -- and is it really as 'disruptive' as some of these enthusiasts are saying?