Browser Patches, Shims, and Polyfills

March 18th, 2011 | Tags: , ,

I’ve noticed that the jQuery community has started using the term Polyfill recently so here’s a brief post that helped me in thinking through this topic. It’s largely inspired by the awesome list of HTML5 Cross Browser Polyfills assembled by the Modernizr folks.

Graded Browser Support

Yahoo has published their Graded Browser Support for the last 3 years and it makes a great starting point for any web application project.  More recently jQuery Mobile published their Mobile Graded Browser Support which emulates Yahoo’s approach. Both of them have divided browsers into tiers, Yahoo choosing to provide different experiences to users in different tiers, and jQuery Mobile choosing to only support the top tier.

The tiered approach is a great way of thinking about the browser landscape and outlining a strategy for Progressive Enhancement or Graceful Degradation.  However there are still significant variances in the APIs of the browsers within a single tier, especially if you want to use any of the newer technologies.  Developers address this variance by writing PatchesShims, and Polyfills(?) in the hopes of creating a baseline API on which to build the rest of their application or library.  Generally your baseline API should target current W3C and related specs.

Building Patches, Shims, and Polyfills

If you’re Google and you have unlimited engineering resources you can write sophisticated browser plugins like Chrome Frame and Google Gears to update older browsers.  For the rest of us, the best way to go about writing patches, shims, and polyfills is to use feature detection (as opposed to user-agent detection). Peter Michaux has a great article on how feature detection balances false positives and false negatives.  You can also learn about feature detection techniques from Dive Into HTML5.  There are a number of feature detection libraries such as and Modernizr.

So once you write a feature test that returns a meaningful boolean, the question is how you address the lack of a feature (a false).  If you can implement the feature using javascript and other supported technologies then you’ve got yourself a shim!  If your shim conforms to a W3C or related standard, even better!  People will disagree on what they consider “implementing” a feature, and often times shims don’t perform as well as a native browser implementation would, but even bad performance is usually preferred to no performance.

Update: March 18, 2011 – Polyfill Definition, thx Paul. See also: Remy Sharp, Rey Bango

A Polyfill is essentially a shim that replicates the real API as defined by the standard/spec.

  1. March 18th, 2011 at 20:20
    Reply | Quote | #1

    A polyfill is a kind of shim that replicates the real API. So a websocket polyfill would create a window.WebSocket global with the same properties and methods on it as a native implementation. That means you can develop for the future, with the real API, and only load your compatibility polyfills in the fallback case for other browsers.

  2. March 18th, 2011 at 20:38
    Reply | Quote | #2

    Awesome, that’s the definition I was hoping for!