9 comments on “What’s in a WebRTC JavaScript Library?

  1. Thanks for including EasyRTC in this fabulous post. I really like the Easy St and Functional Way picture.

    I think two key considerations you could add in choosing an API is whether you need to control your own WebRTC signalling server on premise or in the cloud or use a PaaS,
    AND whether the API and/or signalling server are open source or not.

    • Thanks Doug! You make a great point about deployment options and open source. Especially when it comes to the JS library, having it open source is definitely nice so you can contribute features, or make your own customization if needed.

  2. Thanks for the interesting read, a really nice insight on what a library needs to provide.

    I’ve recently worked on such an effort myself, writing a JavaScript library for our open source Janus WebRTC gateway (which does not appear on the list but I won’t hold a grudge! 🙂 ) and can confirm that I asked myself the same questions in the process, in terms of what to provide and how I mean.

    One thing that had me thinking in particular was about the high level vs. low level approach for the library: this is a challenging question in general, as for instance it’s something that was part of the standardization process as well some time ago, which eventually led to JSEP. Eventually, considering the general purpose of the gateway, I chose a slightly lower level approach that does make things easier than using the WebRTC API, but also keeps some flexibility. After all, you can always tailor a higher level API on a lower level for some specific scenario, which is what I think I’ll try and face in the future.

    • Hi Lorenzo, thanks for the comments. Also, thanks for bringing Janus to my attention…I added Janus to the listing above.

      You have a good memory on the early WebRTC API discussions, and what led to JSEP. I think developers will ultimately appreciate more, not less when it comes to functionality…but having an easy way to quickstart is always appreciated and can only help adoption. As you say, it’s good to start with all the power and functionality in mind, and then make it simpler as you need to.

      I’ve been using AngularJS a lot lately, and I must say that there is just no easy way (that I’ve found) to quickstart the concepts of that API. I nearly gave up on it several times while climbing that learning curve, but In the end, I’m glad for all the super powers that you get with it.

  3. Thank you for this superlative article. I am particular happy about that brief mention of AngularJs and steep learning curve, which leads to my question:

    Have you implemented any of this with Angular? Which will be your personal choice with Angular?

    Thank you!

    • Hey Mark, thanks for the comments. Personally I am a big fan of Angular, but for me the learning curve was steep. I found many of the concepts, conventions, and lingo can be quite abstract at times (directives, data bindings, and factories, oh my 🙂 !), and I really had to commit myself to learning them. That said, once you get the hang of it, it really does give you super powers, and it is amazing how fast you can create awesome, dynamic web apps.

      As for implementing Angular with WebRTC (and the WebRTC JS libraries), yes I use it all the time. Angular goes really great with WebRTC, because WebRTC implicitly requires you to maintain a somewhat complex signaling state machine in the browser, and at the same time, manage the browser’s media engine state through the WebRTC API. Both of these result in a lot of asynchronous activity that has the get handled via lots of events. Of course, to make your web app awesome, you need to handle many of the async changes in state, and use them to update information on your HTML (e.g. on incoming call, activate a div containing a call notification and start playing a ringing audio file).

      Handling this sort of dynamic state is where Angular really shines. My basic approach has been to gather all the different handlers and methods into a single object, and I define a set of very basic properties that become my Angular data model (e.g. primitives for signaling channel state, incoming call state, and so on). Once you have your data model set up and working, it is a snap to use the Angular data-bindings and directives in your HTML to automatically trigger HTML5 awesomeness whenever your state changes!

      Anyways…hope this helps!

  4. I am new to webrtc and your articles have been very informative. Thanks.
    Please i would like some clarification.
    Since there is no defined signalling protocol, which part of WebRTC makes the Signalling Data consistent across all Signalling Protocols ¬ and Why and how does it make signalling data consistent?

Leave a Reply

Your email address will not be published. Required fields are marked *