From its nascent days, the growth of the web has been marked by the waxing and waning of technologies, frameworks and ideas. Old ideas and technologies expire and fade away, and new ones arise in their place. Much as the cicada molts and leaves behind an old shell as it moves into adulthood, the web has seen countless ideas come and go as it has evolved.
Relics (and Catalysts) of the Web
Remember XHTML? More specifically, do you remember caring deeply about XHTML? You likely do. Do you still care about XHTML? Chances are, the answer is no. The same goes for Flash, DHTML, HTML Components and countless other buzzwords of the web that once felt so alive and important, and now feel like relics of another time.
Occasionally, however, we collectively stumble upon ideas and technologies that stand the test of time. These are ideas that don’t just evolve with the web–they are often a catalyst for the evolution of the web itself. Ideas like Cascading Style Sheets and XMLHTTPRequest, the vendor hack that spurred the AJAX revolution, are two examples among many.
Polyfills: A Retrospective
How then, should we categorize the polyfill — an approach for “filling in” feature gaps between browsers? In 2014, is the polyfill a relic, or a catalyst? The term certainly doesn’t seem to carry the same cachet it did way back in 2010, so are we to believe that the approach it describes is no longer needed; that the web has “leveled up” enough to cast the term into history books? I think not. Not only is polyfilling still important, it’s becoming more important than ever as the sheer extensibility of the web platform explodes.
By now, the etymology of “polyfill” has been well-tread, but let’s review anyway. In 2009, Remy Sharp coined the term “polyfill” to describe:
“a piece of code (or plug-in) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.”
It’s a practical term, intended to describe an approach that allows developers to target varying levels of built-in functionality across browsers with a common set of code. Way back in 2010, polyfilling was most often intoned as a way to get “modern” features like Web Storage, Canvas and CSS3 into Internet Explorer 8 and its antecedents.
Over the last four years, however, IE — that old punching bag — has grown. The browser is evolving at a much faster clip than in the past and even doing a bit of the “watch me add features that are still in First Public Working Draft”-trick that Chrome first mastered. Polyfills of the past for HTML5 technologies like Storage and Canvas are still relevant for many sites, but they become less so with each passing holiday as young techies venture home to valiantly upgrade the browser on Grandma’s Pentium.
In 2010, the technologies that fell under the “HTML5 umbrella” would fit nicely on a single slide. They were many, but manageable, and with few exceptions, they’ve enjoyed near-universal adoption across browsers, even on devices. I suppose one could say that HTML5 is “done,” and that polyfilling can now assume its place in the web platform hall of fame.
Polyfills, Reconsidered
Yet things are never quite so simple. Our standards bodies and the platform itself may be quickly leaving the “HTML5” moniker behind, but this has less to do with the fact that the work is done and much more to do with the reality that there’s not an umbrella term broad enough to encompass all of the work going on in the web platform these days. To shamelessly borrow a analogy that’s been used in this context before, we are in the midst of a Cambrian explosion of web technologies.
For starters, the “mainline” work of our intrepid standards bodies has not slowed in recent years. As CSS3 modules enjoy implementation, new modules join the ranks, covering everything from new selectors and layout constructs, to conditional rules and even a rethinking of web animation itself. The ECMAScript TC39 committee continues to capitalize on the ever-rising popularity of JavaScript by introducing brand new language features — and re-introducing ones long-dormant — in it’s ES6 revision. Even the DOM is getting some love with an overhaul design to better align documents with the needs of script-heavy applications.
And this doesn’t even begin to describe the more experimental work taking place on the platform, where ideas like providing scriptable browser caches (ServiceWorker), WebGL via CSS (Filter Effects) and fine-grained control over content negotiation (HTTP Client Hints) are being introduced daily. And let’s not forget Web Components, a cadre of specifications primed to fundamentally change the way we build browser apps in the future. That is, if Apple decides to join the party.
What, you might ask, does this have to do with polyfilling? Everything! With new specs and ideas being proposed across the web every single day, there has never been a more important time for the polyfill. Call it a prollyfill, or forward polyfill if you will, but the fact is that these specs and ideas are merely ethereal until we developers have a chance to put them to the test, with code, in a real browser. This has always been the goal of the polyfill, hasn’t it? To enable a non-supporting browser to “act” like it supports a soon-to-be native feature.
The polyfill of 2014 is much the same, in this regard. It might be trickier at times, and we may need to jump through a few more hoops and try out a few new hacks, but the stakes — and the opportunity for developers — have never been higher. Because, unlike the polyfills of the “early modern web,” which existed to level the playing field of the web, today’s polyfills exist to level up the web itself.
If you’re interested in learning more about polyfills, prolyfills, and extending the web, check out the author’s new book, Building Polyfills, now available for sale.