Work
SubscribeWhat is a Polyfill?
A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.
Alex Sexton also classifies polyfilling as a form of Regressive Enhancement. I think that sums it up nicely.
Paul also defines it as:
A shim that mimics a future API providing fallback functionality to older browsers.
Some Examples
Here’s an example: sessionStorage is available in all the latest browsers (IE8 and upwards) but isn’t in IE7 and below.
A polyfill can be used to plug the support for older browsers that don’t provide sessionStorage.
Now with the polyfiller in place, as a developer I can rely on using the Web Storage API (for sessions) and not have to feature test in my code or fork to handle different situations.
Another example is providing canvas support in IE. This is really where the poly part can be seen. If there’s no native canvas, we can provide canvas support using Silverlight. If Silverlight isn’t available, we can drop down to using VML using excanvas (note that excanvas actually does also include a Silverlight bridge which I’d expect it would try first anyway). Using these two scripts provides the developers with (faily) solid canvas backup should it not be native in the browser.
Where it’s from and where it’s going
Earlier on this year I co-authored Introducing HTML5 with Bruce Lawson. During the R&D time I was looking at shims and techniques to plug missing APIs but they weren’t quite progressive enhancement. I wanted a single word that represented this idea that there was a ‘thing’ that could plug browsers but wasn’t progressive enhancement but wasn’t graceful degradation either.
Polyfilling seemed to fit what I wanted to say (in my head!).
Ployfilla is a UK product known as Spackling Paste in the US. With that in mind: think of the browsers as a wall with cracks in it. These polyfills help smooth out the cracks and give us a nice smooth wall of browsers to work with.
I tentatively used the new term during my HTML5 talk for ThinkVitamin back in June, but I didn’t want to push it for fear of trying too hard to push a new term out. However I did sneak it in to Introducing HTML5, which I can only assume lead to what happened recently.
Recently at JS Conf, Paul Irish released a list of polyfills and shims – an awesome resource list to save us developers the pain of older browsers.
It looks like polyfilling has some legs, so let’s start using them, and dragging older (and even the newer) browsers up to our expectations.
You should follow me on Twitter here I'll tweet about JavaScript, HTML 5 and other such gems (amongst usual tweet-splurges)
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)%3B%2B__utmv%3D10185432.-%3B)
I ALWAYS have this image in my head whenever this topic comes up:
http://www.tooled-up.com/Artwork/ProdZoom/PLCQDP330GS.jpg
Nice post, thanks for the handy list of polyfills and shims. Anything that helps flatten the browser landscape can only be a good thing.
P.S. You’ve a small typo on “Ployfilla is a UK product” :)
Remy,
Nice piece – and great to have an explanation. Now I understand the poly part – (nothing to do with parrots) :)
I especially like Alex Sexton’s reference to ‘regressive enhancement’.
I think the term polyfill is great but I previously favoured the old-school term ‘patch’ – it seems to fit in nicely with the definition in wikipedia :
A patch is a piece of software designed to fix problems with, or update a computer program or its supporting data. This includes fixing security vulnerabilities and other bugs, and improving the usability or performance.
http://en.wikipedia.org/wiki/Patch_(computing)
I liked the idea that if that browser makers can’t get on and bring their browser’s up to scratch, the wider community can create patches that will do.
It’s great to see this technique being pushed and gathering momentum – and we have you and Paul Irish to thank for that. So thanks! :)
[...] Well, it seems I’m a little late to the party – Remy Sharp has beaten me to the punch and posted a great post explaining the sudden popularity of polyfills. You should read that too. [...]
Can you clearify the term shim and polyfill a little bit, for me. The scripts of polyfills and shims listed on the modernizr-page are extremley different. There are some shims (excanvas, svgweb, webforms2), wich are trying to implement the standard and there are shims, wich are building an abstraction on top of two or more technologies. How do you distinguish between them? If you don’t distinguish between them, then jQuery, YUI etc. are also shims ( $(‘#main a’) is a shim for document.querySelectorAll(‘#main a’) ).
I think we should try to implement the standard and than build nice extensions and abstractions on top of this. With this concept, we could throw in a standard compliant implementation and then use another extension or abstraction, from a different developer.
I’m currently working on a “shim” libary, where I try to combine some of the shims mentioned in this list with an capability loading concept. It is in an early state, so not really useable for production mode, yet. But if someone wants to help out, let me know. (http://afarkas.github.com/webshim/demos/index.html)
A fair question. If Browser X has all the features ever to be spec’ed out, a polyfill could make Browser Y behave the same as Browser X.
For example, I’d say jQuery isn’t a polyfill, but this is:
// first include jQuery if (!document.querySelectorAll) { Element.prototype.querySelectorAll = function (q) { return $(this).find(q).get(); }; // the document object doesn't descend from the Element object, so // I've overridden this manually document.querySelectorAll = Element.prototype.querySelectorAll; }Now we can use the native
querySelectorAlland we know, as developers, that jQuery has plugged the support in older browsers (actually Sizzle would be a better match – but it should still illustrate my point).[...] release of Weppy, my Javascript WebP to WebM conversion library, or something of a polyfill for a format that is yet to be part of any specification (HTML5 seems to specifically reference the [...]
I immediately think of graphics APIs when I hear “polyfill”. I.e., flood fill a polygon. I am not the only one: http://www.google.com/search?q=polyfill+polygon+rgb|color
I am partial to “patch”, like Mark, and “shim” in general.
[...] Mobile alpha is coming Saturday Paul Irish has compiled a list of HTML5 Cross-browser polyfills (what’s a polyfill?) NodeJS screencasts Share and [...]
[...] polyfills such as CoffeeScript (when not run as a server-side code generator) may become more widely used, [...]
[...] of a feature that works in all browsers, then adding features for more capable browsers.The “polyfill” or “regressive enhancement” technique just means that you go ahead and use the [...]
In case anyone needed a touch more clarification on the term polyfill…
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.
Why not Americanize it? Call it spackle.
Because I’m English.
Good answer (English). Polyfill it is!
Despite the great explanation and the importance or standardizing terminology, this is also another buzz word some people will now use to make us think they know a lot. :)
So Polyfill in english is AguaPlast in spanish http://bit.ly/sL8FTv
Poly = many
fill = add up until full
Goni = corner
ergo: Polygon = many corners, poly fill = many times add up until full? Huh?! WTF?
Please, for the sake of semantics, etymology and greater understanding. Call it a patch or something!
You don’t call a copying machine xerox either, since you’re not from the US or Russia ; )
Honor your heritage, my British friend, but don’t forget that Greek came before.
You wouldn’t call a method call in higher-level languages a “GoTo” either, right?
PS: it’d be called “Pattex” in Germany… http://bit.ly/Hn2Erc
@George – I don’t normally bother returning replies to these “don’t use another word” comments, but you know that the underlying greek meaning is exactly what I was shooting for.
Poly = many – in that there are many different ways to solve a specific problem, like say supporting the video element.
Fill = add up until full – until the full specification is available to us as developers.
(not sure what goni is supposed to be…)
My intention with this “word” was to lay the seed and allow the web community to pick it up and see if it had legs. Turns out it did. We, as a community, wanted a word to hook our new HTML5 et al technologies on, and ultimately a polyfill is a better practise than a shim as it’s removable in the future without change to your own code.
Our industry likes buzzwords – ajax, web 2.0 – this is just another one, and if it helps get better support and better experience to users, then polyfill it is :)