Dropping IE Support

I’ve almost completely dropped support for old Internet Explorer in my most recent projects despite the fact that they should be accessible to a wide and non-technical audience. Call me crazy but I have more reasons than simple insanity for doing so. Internet Explorer usage (for versions I’m not targeting) has dropped to single digits and progressive enhancement is something that should be applied in a generalized way that targets all browsers. I won’t advocate for dropping IE wholesale but if you’re thinking of moving that way, maybe this will ease some of your concerns.

I started writing this in January of 2015. It’s contents have only become even more true and reliable since.

Six years ago when I started my first company, every bit of my front end code was littered with Internet Explorer specific hacks. Everything from my markup to CSS, and styles. Nothing was left untouched. Back then it made sense. Internet Explorer 9 was just starting to be used and even that can’t be considered a truly modern browser although it was the first version I didn’t have to care so much about. Now we have companies like Salesforce dropping support for IE7 and and IE8. When these large companies start dropping older versions of IE you know that this time we really are on the verge of no longer having to worry about IE specific hacks.

For a long time developers like me have been treating Internet Explorer as a browser to be treated separately from their usual progressive enhancement centered workflow. We would make sure that our sites looked and functioned properly in all of the other major browsers and then do an “IE run” wherein you spin up some VMs and start testing the site in at least 3 different versions of that browser. And when, not if, we found bugs we would start littering our code with extra classes and unnecessary elements and lots IE specific JavaScript and CSS for that browser alone. No other browser in the last 20 years has caused more headaches than Internet Explorer and this entire time we may as well have been creating completely separate sites just for IE the way creating separate mobile websites was popular just a few years ago.

Those days are behind us. Now we have IE 11 and Edge with a brand new rendering engine backed by a Microsoft that seems to have finally modernized, opened up, and begun to listen to developers. I’m not about to switch back to Windows but even the most fervent Microsoft hater has to give them some credit these days. Internet Explorer is still a pain to develop for if you’re not on Windows but you no longer need to worry about JavaScript quirks and styling hacks. In the current environment you can develop and debug using your browser of choice and be relatively confident you won’t find many serious issues afterwards. That’s not to say you can stop testing in multiple browsers. It’s my opinion that there will always be differences between browsers that need some debugging. What I am saying though is that we can finally start using CSS3, HTML5 and and ES5 with confidence. The only front end technology that you really need to worry about anymore is ES6 (also known as ES2015 or the latest version of JavaScript which is coming to WebKit slowly with lots of great new features).

Vendor prefixing

I still do vendor prefixing. I use LESS as my preferred CSS transpiler and have a library full of mixins that do the prefixing for me. If pure CSS is your thing then you can use a tool like Autoprefixer at build time or manually to add vendor prefixes. Vendor prefixes are likely going to be in common usage for quite some time to come. You’ll always have some user using older versions of what we once considered modern browsers and as new features are added to CSS the browsers we know will begin implementing them using vendor prefixes.

Ditching jQuery

For longer than I’ve been a developer, front end people didn’t really write JavaScript, they wrote jQuery. jQuery was created to help developers focus on functionality without having to worry about browser compatibility (which has largely been used as a euphemism for “supporting Internet Explorer”). These days most jQuery code can be written in plain JavaScript with no worries, even in IE.

Usage Stats

As of December of 2015, Chrome and Firefox combined have about 90% of the browser market sewn up with Chrome leading Firefox by about 50%. All versions of IE come in at 6% with Safari and Opera trailing even lower than IE. With Safari, just about anything that works in webkit works in Safari but Chrome is much much better at implementing new features as they’re available while Safari gets a big update once a year.

What this tells us is that all things being equal 90% of your visitors will be using Firefox or Chrome.

Know your audience

Different categories of sites will attract different browser demographics. It’s easy for me to brag and be a dick about IE because just about every site I build is for younger and/or technical audiences. My IE stats in Google Analytics show less than 1% of my visitors using IE for any given site. 1% may seem like a lot but many of those sites aren’t really getting all that much traffic. When you’re getting 10,000 page views a month that means 100 users came in using IE and of those most are using IE9 or higher which are the best versions of Internet Explorer to have to deal with.

Your mileage may vary though so you have to make a choice about whether you’re going to go out of your way to support IE.

Dropping support doesn’t mean rendering broken pages

One of the first things I mentioned at the start of this article is that we should all be developing sites with progressive enhancement in mind. That means that when a browser doesn’t support some new CSS3 animation or an ES5 method like Array.prototype.forEach you can easily take care of these things by patching the browser’s JavaScript methods using something like ES5 Shim. If you’ve done progressive enhancement correctly then even this missing support won’t disrupt the user’s ability to access your page and use it. As far as CSS support goes, you can just show an “uglier” version of those styles in older browsers. So you miss a nice rounded corner and your button hover styles don’t have transition effects. Not a big deal. As long as the content is clear and accessible then that’s all that matters. No need to jump through hoops, bloat your code, and make it unmaintainable so that 1% of users get the same exact experience as the other 99%. That’s a total waste of time (unless you have some sort of huge budget I guess).

Real world example

Right now I’m helping to develop a site for a multi-billion dollar corporation. They decided they’ll only be supporting IE9 and up. This decision has not affected how I code in the slightest. We’re able to use just about any CSS3, HTML5, and JavaScript code we’d use in an ideal world and so far no issues related to them have come up and it’s not because we’re not using any newer CSS3 or JavaScript features.

Drop it like its hot

Because it is hot. Drop IE and free yourself from code bloat, debugging, and maintenance hell. I originally started to write this over a year ago so maybe this is all obvious to you now but I just wanted to get it out there.

Front-end development

« Getting Good at Development Securing API Keys in a JavaScript Single Page App »

Comments