A Beginner’s Guide to HTML5 Cross-Browser Polyfills
The web can seem fast moving. New frameworks, tools, and even languages come and go. Yet many developers feel that they have to move as fast as their slowest user. New browsers are ‘evergreen’ — they auto-update unseen in the background without asking for permission, and they’re making leaps and bounds in terms of progressing new APIs.
Yet even modern browsers implement features at different times. It’s frustrating to read about the bleeding-edge of modern development only to think it’s all unusable for years to come. Maybe you’ve looked through your site’s analytics and spotted users still on IE9? Should you code like it’s 2011 or delegate everything to jQuery or some framework? There is another option. Enter the polyfill.
What Are Polyfills and Why Do We Need Them?
Remy Sharp coined the term in a 2009 book and blog post. If the feature exists in the browser, the polyfill lets the browser do its thing, if not, the polyfill steps in to plug the missing functionality. They fill in the holes of older browsers, the missing features we want to use today. It replicates a native API with non-native code.
What Missing Features Are We Talking About?
In 2009, the 5th Edition of ECMAScript landed. It was a large and radical step forward for the language. ECMAScript 2015 delivered a similarly seismic update. Going forward, improvements to the language will be incremental, happening on a yearly basis. It’s an exciting time, with new features continually making their way into the language. Besides the core language itself, there’s also the DOM and the various APIs of the web platform.
To highlight the discrepancy between a modern and a legacy browser, here’s a comparison of the latest Chrome release versus Internet Explorer 9 (which some companies still sadly mandate support for). And here’s a table showing support for ECMAScript 6. The second table only goes as far back as IE 11, which as you can see supports practically zero ES6 features. That’s a lot of missing features…
Polyfills vs Transpiling
So clearly, from looking at the above tables, we need to transpile our code. It takes your shiny new syntax and spits out plain old-fashioned ECMAScript 5. If you want to utilize arrow functions, async/await, rest and spread parameters, classes, et al in your code, you need to transpile your ES6 code into ES5 with a tool such as Babel.
WeakMap, static methods like
Object.assign, instance methods like
Array.prototype.includes, and generator functions.”
So the Babel polyfill can give us all the ES6 features we want. But there’s plenty it leaves out. Maybe you add and remove classes with the
classList API or conduct media queries with
matchMedia, but you still need to support IE9. Luckily there’s a service that provides everything the Babel polyfill covers, and a whole lot more.
Making Life Easier with Polyfill.io
Polyfill.io is an open source initiative developed by the Financial Times. It currently receives up to 204 million requests per day and describes itself as “a canonical library of polyfills”. This polyfills-on-demand delivery system enables you to peruse Can I Use, shrug, use the latest standards and still be compatible with legacy browsers.
— Alice Bartlett (@alicebartlett) May 24, 2017
Ideally, we should only polyfill features we’ve actually used and only send those polyfills that a particular browser actually needs. Polyfill.io can achieve both those needs. Rather than delivering bloat to modern browsers, the service reads the User-Agent HTTP header so that it can deliver only what is necessary. New browsers will receive an almost empty file, old versions of IE will receive a gargantuan wall of code.
You can mitigate the weight of code delivered to older machines by specifying a list of the features you’re using in the query string. If omitted, a set of defaults will be used. Using the service does require one additional blocking HTTP request, but to my mind, its ease of use is worth it. Philip Walton, an engineer at Google, has his own thoughts about polyfills and performance, which is worth a read if that additional request bothers you.
What Doesn’t It Cover?
‘Prolyfills’: Testing Out Emerging API’s
And on to prolyfills – speculative shims for APIs that will probably happen.
Prollyfill: a polyfill for a not yet standardized API.
— Alex Sexton (@SlexAxton) October 14, 2012
Polyfilling features that haven’t shipped yet as a proof of concept is increasingly common, and is fun for experimenting with the bleeding edge of front-end development. Perhaps you want to test out the Observables proposal inspired by the popular RxJS library? There’s a prolyfill for that. Experimenting with new technology is one of the most exciting parts of being a developer.
So there you have it. We’ve looked at what polyfills are, why they’re necessary, how to pull in whichever polyfills you might need from polyfill.io and even how you can go about polyfilling features that haven’t shipped yet.
But what about you? Are you only using language features available in all the browsers you support? Or are you writing modern code, then using polyfills to make it work in older browsers? And what is the oldest browser you’re expected to support? Let me know in the comments below.
This article was peer reviewed by Graham Cox. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!