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.
FLASH SALESave $80 on command line for non-techies
I've published 38 videos for new developers, designers, UX, UI, product owners and anyone who needs to conquer the command line today.
Where polyfill came from / on coining the term
Shim, to me, meant a piece of code that you could add that would fix some functionality, but it would most often have it's own API. I wanted something you could drop in and it would silently work (remember the old shim.gif? that required you actually inserted the image to fix empty
td cells - I wanted something that did that for me automatically).
Also for me, the product Polyfilla (spackling in the US) is a paste that can be put in to walls to cover cracks and holes. I really liked that idea of visualising how we're fixing the browser. Once the wall is flat, you can paint as you please or wallpaper to your heart's content.
I had some feedback that the "word should be changed" but it's more that the community at the time needed a word, like we needed Ajax, HTML5, Web 2.0 - something to hang our ideas off. Regardless of whether the word is a perfect fit or not, it's proven it has legs and developers and designers understand the concepts.
I intentionally never really pushed the term out there, I just dropped it in a few key places (most notably the book), and I think it's when +Paul Irish gave a presentation some (many?) months later, directly referencing the term polyfill, was when the term really got a large amount of exposure (I think this was also helped with the addition of the Modernizr HTML5 shims & polyfill page).
Alex Sexton also classifies polyfilling as a form of Regressive Enhancement. I think that sums it up nicely.
A shim that mimics a future API providing fallback functionality to older browsers.
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
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 a (fairly) 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.
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.