Crossing The Browser Update Chasm

Crossing the browser update safely

Modern browsers have the capability to auto update themselves. In Chrome (as an example) you don’t find yourself manually updating the browser version, it just happens magically. While you can go ahead and disable this feature, most common users will not do this.

Continuing with the Chrome example, this means your stable browser version changes every 6 weeks or so. Mind you that the Canary build changes almost on daily basis.

Google lists the Chrome version history and planned updates for the coming year.

As an application developer this is a nightmare.

Think of what a company needs to go through in order to maintain its WebRTC application and make sure it doesn’t break. Some of those challenges are:

Multiple browser support, something that only gets more complex now that Microsoft joined the gang and Apple will sometime follow suit.

Constant updates of the WebRTC standard and APIs that get quickly adopted in browser updates you have no control over.

No real sync between the different browser vendors when each new functionality or API change is being added to the browser.

Add to this the server side that needs to be maintained and you get a perfect recipe for a disaster.

This is something I run into regularly when speaking with customers, suddenly the service stops working on Firefox, Google decides to stop support for non-secure sites as of December (be prepared)…

Taking control over your application

One option is to pass over this headache to someone else, use an API platform and build your application on top of it.

There are clear advantages to this approach. It is in some way similar to the business I was into for many years at Radvision where we sold VoIP SDKs that implemented the SIP and other standards. We took the headache of following the standard and making sure things work and our customers paid us for this.

In WebRTC the headache is to greater extent, as you don’t really have control of all the moving parts.

The WebRTC API platform ties you to a specific vendor’s API and backend. It is what it is; you can’t really add features or fix things yourself. You pay as you go and as you grow until you reach a point where the math of cost might make you decide to do it yourself (or renegotiate terms).

An API platform is good for some but not for all.

Regardless, you need to test your application and not count on luck that it will work on different platforms and in different network environments.

This is a challenge I will address together with Tsahi Levent-Levi from testRTC on a Webinar we will host on Nov 18^th.

Learn more about this webinar and register for one of the 2 sessions we will hold.