Is it time to cast Internet Explorer aside?

Although it’s generally agreed to be terrible and the last version was released in 2013 — the distant past as far as technology is concerned — Internet Explorer refuses to die.

Internet Explorer still has somewhere between a two to five percent share of the browser market, perhaps even approaching ten percent if we only consider desktop users.

It’s hard to measure browser market share, but probably one in twenty users are still on IE.

Unlike Edge, Chrome, Firefox and other modern browsers, which download new versions automatically in the background, Internet Explorer doesn’t update itself, leaving us with a substantial group of users who are stuck on this ancient browser.

Who are these people?

Lots of them work for big businesses, where IT rollouts are slow and expensive. IE is still the de facto browser in many government departments.

The majority aren’t using IE by choice. They can’t upgrade, because their hardware is either old or locked down, and often need IE to do their jobs. These users are generally also older and less experienced with computers.

Essentially, they’re the users most in need of support, so unless you can prove these people aren’t in your target audience (with data!), it’s worth spending the time to help them use your service if they need to.

After all, it’s easy to cater to digitally literate twenty-somethings with macbooks. The real challenge is to make the web cater for everyone.

Luckily, design principles like progressive enhancement encourage us to build online services that fail well — providing a passable experience even when the user’s browser isn’t the latest and greatest.


Web developers joining the field today may well have never used Internet Explorer, and won’t remember the days where developing for it wasn’t optional — it was mandatory.

I’m one of these people. My first webpage layouts used flexbox — I never had to contend with classic float or table based layouts.

Here’s a few of the things that tripped me up learning how to develop for IE.

Aggressive caching

Internet Explorer is very, very aggressive about caching files it downloads.

This is generally a good thing in production, since it means returning users have less to download and see your content faster, but it can be a tremendous pain during development.

It can be a hassle when you’re making minor tweaks to a Javascript or CSS file, but failing to see any updates in the browser.

Overcoming caching just takes a hard reload (Ctrl+Shift+R) in Chrome, but it’s not as easy in IE.

Some IE versions do have dev tools accessible in the normal way, and some allow you to “Always fetch from server”.

Use the network tab of the dev tools to verify when files are being fetched from the cache.

No flexbox (or grid)

Modern CSS gives us two incredibly useful and flexible (hah) modules for building page layouts. Flexbox is the more established of these, and grid support hit mainstream browsers last year.

But you can’t really use either of these in IE.

The best you can do is design like it’s 2006, floating things left and right. But that potentially means you’ll need to maintain a completely different layout, just for IE users.

To avoid that maintenance nightmare, my approach to this is to give IE users the same single-column layout that mobile users will see. A single column is what look like by default — no floats, flexbox or grid CSS needed.

Sure, it’s not perfect, but it still works.

Missing Javascript methods

When Javascript started out, it was a very imperative, step-by-step language, but later versions have added a lot of functional features.

Newer, functional methods like .forEach() are less verbose and easier for developers to understand.

Generally, the more recent functional methods are the missing ones.

For instance, if you want to do something with every element in an array, you might normally lean on .forEach(). In IE, that’ll need to be a classic for loop instead.

It’s not a straightforward replacement either, since scope works differently in a for loop compared to the function inside a forEach.

IE’s terribleness was a major cause of the creation of jQuery, which aimed to make life easier for developers by smoothing over the differences between browsers, and providing a simple, common API.

No quick fixes

Transpiling tools like Babel promise to let you write next-generation Javascript, and take care of the hard business of making it run in the browser for you.

While Babel does a good job of converting modern JS syntax into something that’ll work in a classic browser, it doesn’t work so seamlessly with modern browser APIs.

So, using an arrow function ()=>{} is no problem, because Babel can turn it into the classic function syntax of function(){}.

However, the trickiest part of building for IE is where you’ve used modern browser APIs that IE doesn’t have a drop-in equivalent to.

The fetch() API is simple and easily understood, but even the capitalisation of XMLHttpRequest is confusing.

For instance, modern browsers can make HTTP requests using fetch(). It’s intuitive and simple to use. IE has only the old, tatty XMLHttpRequest, which has a very different syntax that feels very strange to a developer who didn’t learn it the first time round.

You’ll either have to manually polyfill these, running the risk of multiplying the number of bytes you send down the network (just what outdated hardware and software needs!), or will need to use the older API.


It can be tempting to do away with IE and just develop for modern browsers. It’s continued existence is a headache for front-end developers everywhere, including me.

But a key strength of the web is that the code we write can, in principle, run anywhere. That’s not true of any other platform.

There’s nothing technological stopping us from delivering acceptable experiences even for users of the oldest browsers.

Robust services that still kind of work even when conditions aren’t perfect is better for everyone, not just IE users. Even with a modern smartphone, signal can drop out, JS file downloads can fail part way. Users of screen readers won’t perceive a fancy page layout anyway, so why not start with a good, semantic single column layout, then add CSS grid flair on top of it?

Principles of progressive enhancement and universal design are still vital to our work.

We mustn’t forget that the people still using IE aren’t just stubbornly refusing to download Firefox. They’re generally just as frustrated to use the browser as we are to develop for it, so we should do what we can to make their lives easier.

At least, until IE finally dies for good.

Caniuse.com is an incredible resource for checking support for modern browser features, and Browserstack is great for testing with multiple versions of Internet Explorer, if you don’t have access to it yourself.