This post was originally published by Freddy Rangel on Medium.
You might ask yourself, “why in the world would anyone want to torture themselves by supporting IE8?” Even Google doesn’t support IE8! But there are actually many companies that must support IE8 for one reason or another. At the company where I work, HelloSign, we allow third-party companies to embed our document signing software directly in their applications. Many of our customers support IE8. Therefore, we must support IE8 as well.
Recently, we received a report that IE8 users could not sign documents on our site. We take these kinds of bugs very seriously. Signing agreements is no trivial matter: they’re the written documents that outline the relationships and obligations of our lives. If our users can’t sign documents, they can’t do the basic tasks to get things done. A bug like this can have a huge impact on individuals and businesses alike.
The cause of this bug for IE8 users was our rewrite of many parts of our application using React and Webpack. As it turns out, there are quite a few changes needed in order to get these two libraries to run on IE8. Here’s how we did it.
Set NODE_ENV to Production
This change not only makes your React application much faster, but also removes a lot of code in development that are not supported on IE8. There’s a little more to it that just setting your NODE_ENV, but luckily I already wrote a blog post about how to do that and more: How to Make Your React Apps 10x Faster.
ES3ify Your Code
Even with a polyfill, there is much ES5 code that will break on IE8. One prominent example is the reserved words in IE8, words used as key names in an object. `class`, `catch`, and `default` are reserved works in ES3. ES3ify will change your code to avoid these conflicts with ES3
You can create a simple loader to ES3ify your code, or you can use the existing one here: es3ify-loader.
For good measure, I recommend using 2 Babel transforms that do much the same thing as ES3ify: Transform-es3-property-literals and transform-es3-member-expression-literals. We have a lot of legacy code that we’re not running through Babel, so we need to use ES3ify. We also use the Babel transforms just to be on the safe side.
Watch Out for IE8 Gotchas
One interesting gotcha I discovered was the incompatibility of the getter syntax in IE8. Many developers assume getters are an ES2015 feature, but they are actually ES5. This means that if you’re using getters in ES2015 classes, Babel will simply use the ES5 getter syntax. Unfortunately, this blows up on IE8.
There is support for getters in IE8, however, it is only compatible with DOM nodes. My suggestion: Avoid getters if you must support IE8.