JavaScript - - By Oliver Williams

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.

However, you can’t polyfill the syntax of JavaScript. While Babel will take your arrow functions and turn them into regular functions, a polyfill will add methods to the global scope and to native prototypes. Babel offers its own ES6 polyfill that, in the words of the Babel website, offers “new built-ins like Promise or WeakMap, static methods like Array.from or 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.

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?

Polyfill.io is pretty comprehensive, and it includes some bleeding-edge browser APIs like Fetch and Promises. Yet there’s a whole world of polyfills out there to let you experiment and use new technology. Perhaps the most exciting of these is web components, a potentially revolutionary progression in front-end development offering style encapsulation and ease of reuse. Cross-browser support is finally on the horizon. Google have heavily pushed their Polymer project, which is basically a JavaScript framework built on top of a giant polyfill. However, web components shouldn’t be equated with this framework, as web components promise to be pretty powerful all by themselves. You can use components without Polymer, but the full gamut of the API has not been reproduced.

The Web Animations API offers a performant library-free way of building animations with Javascript. The browser support isn’t currently great but the shim has proven dependable enough that I’ve already confidently used the technology for all the animations on production sites I’ve worked on. It offers two options —  one fills the features that are currently available in certain browsers. The other adds features that are yet to be finalized, which brings me onto my final topic…

‘Prolyfills’: Testing Out Emerging API’s

And on to prolyfills – speculative shims for APIs that will probably happen.

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.

Conclusion

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!

Sponsors
Login or Create Account to Comment
Login Create Account