Dropping IE8 Support: Consequences for JavaScript

综合编程 2016-06-01

When people hear about dropping support for a certain Internet Explorer version, they mostly think of all the CSS hacks and workarounds that could be removed as a consequence. However, dropping support for IE8 can have subtle, but profound effects on your JavaScript. The short version of what it meant for trivago's JavaScript developers to drop IE8 support is that it enabled them to:

  • Drop unmaintained versions of external libraries and switch to newer, better performing versions that were incompatible with IE8.
  • Use the JavaScript standard that was defined in December 2009 and is supported by every browser except IE8.
  • Reduce testing overhead - for developers and QA.
  • Spend less time cluelessly debugging problems without any help from the browser.
  • Get rid of unstable and insecure workarounds that fixed problems with IE8.
  • Improve performance in all other browsers for free.

All in all, dropping IE8 support was an important milestone for our JavaScript developers. Let us look at the individual benefits in more detail.

Future Proofing

By dropping IE8 support, we have been able to update a few vital dependencies (jQuery, core-js, Babel) that had dropped support for IE8 a while ago. This helps developers because they get access to productivity increasing features added at a later release of these dependencies, and it avoids the situation where one of these libraries has a bug that won’t be fixed anymore.

Code reduction and performance improvements

Without having to support IE8, we can avoid many previously required workarounds that were slow but necessary.

Examples include:

  • The size of jQuery was reduced by 30% just by dropping IE8 support.
  • Our Twig compiler does not need to put text into fake elements just to satisfy IE8. This reduces the size of the DOM, the memory usage, and it improves performance.
  • lodash can use native browsers' features a lot more, and does not need to include the workarounds that would be required for IE8 to work. This results in less code and fewer feature tests, and, ultimately, much better performance.

Productivity increase

The worst part about IE8 is not that it is missing features. There are ways around that and while they are not always easy, we have managed to get by so far.

The worst thing about IE8 is actually that, when something goes wrong and does not work, it is virtually impossible to find out why. Unlike every other major browser, IE8 does not have a useful debugging environment. If it fails, you will just get a rather cryptic error message and a location on the moon - i.e. the place where it reported the error did not exist.

In the months before we finally decided to drop IE8, we experienced many epic struggles to fix tiny bugs. And these struggles, which usually resulted in a one-line change, didn’t last for hours, they consumed days or more. With no inkling of where an error orginated, we often had to resort to putting notifications into the code at a number of places, just to identify the general region. Once we had identified the vicinity of the "bad" code, we used the same kind of notifications to try and find out what exactly went wrong. At that point, it was usually time to ask Google why IE8 didn’t like that particular code. In the standard case, the code was just fine and valid and worked in all other browsers but, somehow, triggered an IE8 bug. This is now a thing of the past.

Dropping a build target

So far, we needed a special build for IE8 as the rules for code minification and various other parts were different for IE8. By dropping the IE8 specific build, we removed 8 out of 16 build targets, which greatly reduced the stress on our Jenkins servers.


Dropping IE8 support saves a lot of developer time. It helps us to avoid situations where we have to work with unmaintained libraries and helps us to write cleaner and more maintainable code with fewer special cases. Maybe best of all, it reduces developer frustration over having to identify the root of a problem with no help at all from the only browser that shows the wrong behaviour - only to find out that they have hit a bug in IE8 that they can’t fix without including weird workarounds.

责编内容by:trivago techblog (源链)。感谢您的支持!


Getting Started With Crafty: Controls, Events, and... In thelast tutorial, you learned about entities in Crafty and how you can manipulate them using different methods. In this tutorial, you will learn a...
Making a javascript string sql friendly Is there away to make a javascript string being passed to NodeJS friendly for MySQL? I'm trying to pass an email address to my NodeJS server and quer...
腾讯 Web 工程师的前端书单 作者:link 2014年一月以来,自己接触web前端开发已经两年多了,记录一下自己前端学习路上看过的,以及道听途说的一些书,基本上按照由浅入深来介绍。 JavaScript 入门 《JavaScript权威指南(第六版)》★★★★★ 淘宝前端团队翻...
Using Async in ES2017 – DiscoverSDK Blog I know that async sounds like an awful boy band from the 90’s, but the truth is that it’s one of the most anticipated new ...
Dynamic addition of HTML fields with Javascript an... I've been having a lot of troubles with this for the past few hours right now and I'm really not seeing where the problem is. Every single code snippe...