First, some notes about who this advice is for: I am assuming you’re working for a small team with no Quality Assurance testing department making a content focused site. If you have a large team that actually QA tests IE11, this advice may not apply to your situation. If you’re just doing personal projects for fun, you should have already dropped ES5 years ago. If you’re making more of an app than a content site, you probably should have cut off IE11 years ago, but the calculations are more complex and site specific.
Let’s contrast this with other users we could optimize for. The number of visually impaired readers is steady and will not go down absent some breakthrough in medical technology. Visually impaired readers can’t just use another device if the site doesn’t work in the device they have in front of them. In fact, even users who have physically normal vision are impaired when driving or walking, and it seems to me inevitable that as voice assistants become ubiquitous and easy to use, sighted users having websites read aloud to them will eventually become commonplace. Plus, there are legal imperatives to make reasonable accommodations for visually impaired readers.
If you’re running a small site without a QA team, it’s probably worth going to Browserling right now and finding out if you’re even working in Internet Explorer to begin with. Browserling will let you run a virtual PC with Internet Explorer from your own browser for a limited time for free, so it’s probably easiest way to do a quick low effort smoke test of your Internet Explorer support without having to install anything. Just open up a tab, take a look at your site, and see if the results surprise you.
I’ve seen developers (including most especially myself) burned by just assuming that Babel and Autoprefixer have solved all their problems with IE11. You may already be dropping support for IE11, you just don’t know it yet. I’ve had sites I work on break for months at a time in Internet Explorer with no complaints from readers. One site I redesigned got just a single reader inquiry about a widget that broke in IE11 after a redesign. When I told the reader to try loading the page in Chrome, he seemed satisfied. More recently, IE11 has had some terrible rendering bugs on my site for days or months at a time that have triggered zero reader complaints. If I don’t QA it myself, no one else will do it for me.
If you think your code will work but haven’t actually QA tested it, it can lead to the worst of both worlds: code bloated with extras for IE11 that still doesn’t even work anyway. It’s not enough to transpile down to ES5, you also need to polyfill every missing DOM API you use, and that can be a very complicated and bloated proposition.
Essentially, there are three target web platforms you might want to support:
- Modern browsers
- Internet Explorer 11 (if you’re supporting <11, 😱)
If you try to support IE11 but aren’t actually QA testing it, you will probably end up with only modern browsers working. It is better to aim for both modern browser support and no-JS browser support and actually succeed than to try for IE11 support and silently fail.
What should you do instead of optimizing IE11?
The web is built on the foundation of progressive enhancement. Deliver “good enough” service to legacy browsers, and save the enhancements for the bulk of your userbase.
Most developers think of
<script type="module">as way to load ES modules (and of course this is true), but
To put that another way, every browser that supports
<script type="module">also supports most of the ES2015+ features you know and love.
Essentially, if you set the script element’s type attribute to an unknown value, browsers will just ignore the script. The effect of this is that IE11 will ignore the contents of any
<script type="module"> tags. Modern browsers, on the other hand, will ignore the contents of
The first step is to decide what your organizational priorities are. These days most software engineers are familiar with the concept of the minimum viable product. What’s the minimum viable experience that you’re willing to deliver to IE users? Maybe you’re not ready to write them off completely and just deliver a broken page and a “Best Viewed in Chrome” icon. But you may be willing to say that as long as they view your ads, you don’t care if they can bypass the paywall or can’t comment on articles. In my case, I want Internet Explorer using readers to be able to read my articles and to show up in my analytics. Everything else, I’m willing to cut or sacrifice in the name of freeing up the resources for creating a better no-JS experience. If that’s my minimum viable experience, I am going to create it and test that it actually works, and then stop iterating, so that I don’t accidentally break it with my future changes to the enhanced, modern browser experience.
import "../utils/add-listeners.js"; // eslint-disable-next-line no-console console.warn("could not load enhancements"); document.body.classList.add("has-old-js");
.has-old-js class triggers a CSS utility class to show and hide things conditionally. A
<noscript> tag in the HTML does the same, as does an
Concrete techniques taken from my work site
Like all news sites these days, Spotlight PA has a big modal screen that prompts you to sign up for our newsletter as you start reading an article. (Yes, yes, complain about it all you want, people actually do sign up for the newsletter because of this prompt. That’s why we show it.) What to do for IE11? That’s easy: nothing. As useful as the prompt is in getting new readers for our newsletter, there’s no reason to worry that 1% of readers potentially aren’t seeing the prompt in one browser. We have other text indicating that there’s a newsletter and most likely the readers will come back in a better browser, like their phones, and see the modal then. 1% growth in our newsletter is easily swamped by the noise from week to week, and there are many better ways to increase newsletter growth than chasing IE11 users. The first major way of doing progressive enhancement is to just omit unnecessary site enhancements.
.no-js-hide, and I can use these to selectively show or hide an element based on whether it is applicable or inapplicable to a no JS user. The page looks a bit cluttered with all the sign up forms already revealed, but it’s still essentially usable.
site:www.spotlightpa.org prefixed search to Google. The fourth technique then is to get someone else to solve your problem. As another example of this technique, we had a donation form written in Vue that fell back to sending readers to the donation processor’s default site. We had written the Vue form as a frontend to their payments gateway because the payment processing site was kind of clunky and ugly, but it was good enough as a last resort.
The best way to help your IE11 users is to provide a great experience for your non-JS users and share that experience with them, instead of sending them an untested and buggy experience that also slows the experience of users with modern browsers.