Goodbye Internet Explorer

This ending presents an opportunity to pull out any code solely because of Internet Explorer and start living in the modern (browser) world.

That first part is easy. Sure, it’s pretty safe with a month before the browser will officially stop working to let new development get launched without being tested in IE11. Your developers will thank you.

That second part, ripping it entirely out of your existing code base, may need some convincing. After all, it’s already there. What harm can it possibly do?

This goes beyond Internet Explorer too. I’m talking about ALL old browsers, rarely used browsers and older versions of modern browsers. Check your analytics to get an idea of how many people are visiting your website this way, then think about offering them a simpler version of your website.

Let’s start with what it might look like.

Have you ever turned on “Reader Mode”? I love Reader Mode, and sometimes I just want to read, you know? A simpler version of your website is just that - a basic layout and no Javascript.

You’ll get a pretty good sense of your HTML structure and source order this way, too (and if you find this needs correcting, please do, as good accessibility starts here).

But what’s the harm?

It sounds like a bit of work, so let’s discuss why it’s worth doing.

Performance

A grid that works in IE11 will have a lot more code than you need for a modern browser. I’m talking anything from negative margins, padding, row divs, :nth-child selectors, and possibly various mixins and extends. Compared to a modern CSS Grid grid, the size of this CSS (and probably HTML) is significant.

Javascript that works in IE11 is also huge compared to what we can achieve in modern browsers. jQuery is no longer needed, a lot of your polyfills won't be needed, and modern browsers support module loading. Say goodbye to that mega JS bundle loaded on every page even though 60% of it is written for one interactive app on one page… that isn’t even published anymore.

Assuming that IE11 is as far back as you have, an older codebase probably goes back to IE10 or worse.

And if you have put a lot of work in already to start writing modern code (go you!), and use something like Babel, code splitting, module/nomodule attributes or PostCSS, autoprefixer and custom property fallback. Think about how much faster your code will compile without all that legacy stuff? I promise it’s a lot.

Maintenance

Remember that complex IE11 grid with negative margins, padding, the works? All those different lines of CSS to maintain so many weak points. Does the new frontend developer you just hired need to spend an afternoon getting their head around it? What does this do? Why’s it here? What’s a spacer gif? (Just kidding, but yes, I’m that old).

There is a technical debt attached to any piece of code that isn’t currently used. That shiny new feature that you all agree does NOT need to work in IE11 doesn’t even work correctly in modern browsers because of that random piece of legacy code that’s creating some obscure bug that takes days to find and resolve. Ouch.

Appealingness

You like us, frontend developers, yes? You possibly need us from time to time, and you might need to hire more of us. We can be happy, we can make jokes, and we can be your friends.

Frontend developers get a constant stream of new shiny frontend code and tools. We enjoy this part of our jobs the most, and we seek employers who can offer it to us. Tracking down and fixing browser bugs is not so appealing. 

Where do you even start?

So you’re convinced, hooray! Depending on what you have to work with, this could be a pretty big task. But a practical first step is just to analyse what you have and break it down into steps and phases.

Maybe start with that grid system. Converting into a Flex based grid with a gap property would be a good start, then perhaps plan a CSS Grid and markup clean up for phase 2. Wrapping it all in @supports(display:grid) will mean older browsers fall back to the default stacking context. Also consider setting up some visual regression testing before you start.

For your Javascript, stick a type=module attribute on your script tags for the same effect. If you’re building a nomodule version, just stop. Review any polyfills you're loading. Then take one Javascript file at a time and start converting it to ES6 modules, removing jQuery while you go (of course you have test coverage in-case you break something).

Are you using Browserslist to target the browsers that need transpiling to? Update it to what you deem appropriate based on your analytics.

After each significant change:

1. Take a look at the damage and make sure your content is still accessible.
2. Maybe put a couple of messages in if the content makes no sense without the app or widget that it relates to.
3. Treat it like the app failed to load for some reason.

If you find something that has nothing to do with IE and isn’t used on the site anymore? Remove it!

Feel like it’s time for a design refresh? Do it at the same time! Think of this as an opportunity, not a chore.

And don’t forget to run performance checks as you go to get that lovely warm feeling of improvement.

So go forth, live in the modern (browser) world.