Browser specific versions of javascript API

The Architectural Diagram of the Polymer project

The Architectural Diagram of the Polymer project

Today when you use a javascript API like jQuery you get the full package. I think about code handling most browser versions. A lot of if sentences within the code checks which browser engine and environment it is running on and depending of what is the current centext it executes the relevant piece of code.

Takes time – affects performance

Every time the code reaches a piece where the code soloution needs to execute different parts depending on the setup, there need to be used execution time on tests to go the right path. That takes up time and affects performance.

More code than is need is served

Each javascript API file today contains all the code needed to serve all the supported platforms. Its like if you bought a newspaper and you would get say 20 different language version served by default. Just imagine carrying the New York Times in 20 different translations, when you know that you understand the english version!

Why server code like that?

I guess that it is common practice and have been so since the beginning of the coding history. Guess that it is a pattern which have become the default way of doing it. I guess that there exists many good reasons for coding like that.

My suggestion – split into platform specifik files

I would suggest that tests should be made to split big APIs like jQuery or MDAngularJS and Polymer into smaller platform specific files. I am not a software arcitect but I thing that it would be doable.

The code could be fetched using a parameter:

jQuery.min.js/IE8

It could be served with a parameter in the name:

jQuery.min.IE8.js

It could be served based on Request parameter, so some logic on the webserver served the correct version.

Argument against this pattern

Ofcause there are arguments against such patterns. Like back in old days on Microsoft IIS webserver a file was used to detect which browser was visiting the site. It was hell to maintain that soloution.

What do you think?

Please share your thoughts on this subject below in the comments area.

 

US

3 thoughts on “Browser specific versions of javascript API

  1. In general I believe the days of platform specific code in web development are loong gone. Feature testing and conditional loading of polyfills make a lot more sense with the wide range of browsers and feature implementations.

    As for the case with jQuery where you want to create a unified API across all browsers, there are things to consider in that regard. They recently forked jQuery into 1.10 (full IE support) and 2.0 (IE9+), resulting in mostly performance gains as the code base only differs by 10%.

    The Polymer overview figure you’ve included shows an interesting and very optimal approach for such a large scale. The core (yellow) on which all the components (green) are build, will provide a reliable API over time, with feature dependencies being ensured by the polyfills (red).

    As browsers evolve the polyfills will give way to native implemetations until the red layer is completely gone, still the exposed API will remain the same.

    That is if the whole Web Component story goes the way Google is expecting :)

  2. Thank you for sharing knowledge on the subject, Morten.

    I also find the simpel overview used by the Polymer project a good illustration. Also the ideas behind where in time most browsers will support up to a shared ground natively. This idea that pieces of polyfill code will catch missing support through javascript is great.

    /Sten

Leave a Reply