A few weeks back I found a bug with IE where all the user saw was a blank white page. If you've been around for a while in the wonderful world of the client-side SPA, you'll probably know what was wrong without thinking twice. That's right. It was a JavaScript error before client-side rendering happened.

Considering it the bug only rears its head in Internet Explorer, my first guess is a problem with polyfills. Yep! That was it!

Uncaught TypeError: contacts.includes is not a function

But we're transpiling our code with Babel! Doesn't that mean that I can use all the latest and greatest JavaScript I want without having to worry about whether the browser supports it? Nope! Let's learn more...

Polyfills vs Code Transforms

JavaScript is constantly evolving thanks to the efforts of people in and around the TC39. Some of the evolutions rely on new syntax (like arrow functions) which allows me to do this:

const addOne = (num) => num + 1
if (addOne(2) > 2) {
	console.log('Math. Wow!')
}

Often, we can use this syntax in our source code so long as we convert it to syntax that can run in the browser (for example, by using a transpiler such as babel: example transpiled in the browser with babel-preset-env).

Some other of these new features rely on new APIs, like Array.prototype.includes which allows me to do this:

const contacts = ['Brooke', 'Becca', 'Nathan', 'Adam', 'Michael']
if (contacts.includes('Rachel')) {
	console.log('You have a Rachel!')
}

With these, if you run them through babel's env preset the includes function is not transpiled because it's not a syntax issue, but a built-in API one and babel's env preset only includes transforms for syntax transformations. You could write your own babel plugin (like this) to transform the code, but for some APIs it just wouldn't be practical because the transformed version would be significantly complex.

A polyfill is code which will make the currently running JavaScript environment support features which it does not. For example, a (imperfect) polyfill for includes might look something like this (refer to MDN for a real polyfill):

if (!Array.prototype.includes) {
	Array.prototype.includes = function includes(searchElement) {
		return this.indexOf(searchElement) !== -1
	}
}

The if statement is there to make this a "gated" polyfill. That means that if the functionality already exists, the polyfill code will not override the pre-existing behavior. You may consider this to be desirable, but it's actually the reason that includesis not called contains on String.prototype (TL;DR: some versions of mootools implemented contains in a gated fashion but the implementation is different from how includes works so the TC39 had to change the name to not break tons of websites).

The part that assigns Array.prototype.includes to a function is called "monkey-patching" 🐒 By applying this to the prototype, we're adding includes support to all arrays in the app (learn more about prototypes here). Effectively, the polyfill's job is to make it so I can use the JavaScript feature without worrying about whether it's supported by the environment in which my code is running (like IE 10 for example).

Where to get transforms and polyfills

With syntax transforms, I recommend babel-preset-env. It's actually fairly straightforward. For polyfills, the most popular one is core-js. You might also look at babel-polyfill which uses core-js and a custom regenerator runtime to support generators and async/await the way that babel transpiles it. Polyfills are sometimes referred to as "shims" and you may be interested in the js-shims by airbnb (which I've been told are more spec-compliant than core-js).

Conclusion

So what did I do to fix my IE10 bug? Well, one thing that really bugs me is that I have to ship all this code for polyfills to all browsers even if they do support these features. But a few years ago I heard of a service that was able to ship polyfills that are relevant only to the browser requesting them. I created my own endpoint that uses the module that powers that service and I'll write about that next week!

I hope this is helpful! Good luck!

P.S. You may have heard of something called a "ponyfill." Ponyfills are similar to polyfills except they don't monkey-patch, instead they're just the function by itself and allow you to call them directly. Learn more about ponyfills. In general, I'm more in favor of ponyfills, though you just can't get away from polyfills completely because often your dependencies are relying on built-ins that your browsers don't support.