WebRTC API footprint

I continued to browse WebRTC API and to develop an application that shows me the diff. I hope to have something good now…

The problem

The problem is simple: As a developer, I have the responsibility to develop an application that works whatever the browser used by the users. More than that, I have to offer an equivalent user experience or at least an acceptable user experience depending on the possibility of that browser. A crash in the application due to a missing API should not be part of that experience :-)

This point brought to the surface all the complexity of that problem: Even if some WebRTC parts are common, each browser has its own implementation and evolution pace and more than that its own objective.

Using adapter.js, features or api detection and a lot of tests allow most of the cases to overcome that difficulty.

But this is like testing a magic black box. I hate that. This is progression through failure. As a developer, I need myself to understand the behavior of each API in each browser to see if it is the same or if there are differences.

Hopefully, sites like MDN Web Docs or Can I use are here to try to help us understanding what API is available in which browser.

This is where I wanted to have something more.

API footprint and differences

As explained in a the posts Do I need audio and video processing skills and WebRTC JavaScript API state of the art, I developed a little tool to help me having in one SVG diagram the whole APIs list.

This helped me during the development sometimes to know how to access some API or to make audio pipeline using the Audio API.

But I wanted to go further. I would like to compare that footprint between 2 versions of the same browser or between 2 different browsers. Using the SVG diagram, differences between browsers can be detected quickly. But comparing 2 versions of the same browser was a little bit more complicated using the diagram.

So, I decided to build a text extractor in order to rely on a diff tool to display the differences.

The result was exactly what I would like. In some seconds, I can now check the progress of a browser in terms of API by having a changelog of API.

Chicken or egg

The quality of the result depends on the WebRTC interfaces targeted. I can’t automatically browse all JavaScript interfaces of the browser. It’s too much and because a lot of them make no sense for WebRTC development.

So, I short-listed interfaces mainly based on the specifications written by the W3C. At that time of writing, I have identified 75 interfaces to track. Pure WebRTC interfaces represent less than 50% of them. But I think it is interesting to have in that list interfaces such as Permissions, Audio API, and HTMLMediaElement because they have a strong link to WebRTC. To be complete, I tried to gather all interfaces that deal with audio and video including Canvas API.

But as specifications change and as new specifications are created, this list need to be reviewed depending on W3C progress.

Example

Comparing Safari versions

I made a test with Safari. Here are the differences between Safari 15.1 available and the latest Safari Technology Preview 15.4 available at that time of writing.

Note: It seems strange that the MediaRecorderinterface is no more present in the latest version…

Comparing Safari MacOS and Safari Ipad

I did a test by comparing Safari both and MacOS (Safari 15.1) and on Ipad (IpadOS 15.1). Here his the differences

Future work

Having that, I’m now able to have my own WebRTC API release notes to help me to understand the changes.