The distance between Internet Explorer (IE) 11 and every other major browser is an increasingly gaping chasm. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to development. Testing becomes onerous. Bug-fixing looms large. Developers have wanted to abandon IE for years, but is it now financially prudent to do so?
First off, we’re talking about a dead browser
Development of IE came to an end in 2015. Microsoft Edge was released as its replacement, with Microsoft announcing that “the latest features and platform updates will only be available in Microsoft Edge”.
Edge was a massive improvement over IE in every respect. Even so, Edge was itself so far behind in implementing web standards that Microsoft recently revealed that they were rebuilding Edge from the ground up using the same technology that powers Google Chrome.
Yet here we are, discussing whether to support Edge’s obsolete ancient relative. Internet Explorer is so bad that a Principal Program Manager at the company published a piece entitled The perils of using Internet Explorer as your default browser on the official Microsoft blog. It’s a browser frozen in time; the web has moved on.
Browsers are moving faster than ever before. Consider everything that has happened since 2015. CSS Grid. Custom properties. IE11 will never implement any new features. It’s a browser frozen in time; the web has moved on.
It blocks opportunities and encourages inefficiency
The landscape of browsers has also changed dramatically since Microsoft deprecated IE in 2015. Google developer advocate Sam Thorogood has compiled a list of all the features that are supported by every browser other than IE. Once the new Chromium version of Edge is released, this list will further increase. Taken together, it’s a gargantuan feature set, comprising new HTML elements, new CSS properties and new JavaScript features. Many modern JavaScript features can be made compatible with legacy browsers through the use of polyfills and transpilation. Any CSS feature added to the web over the last four years, however, will fail to work in IE altogether.
Let’s dig a little deeper into the features we have today and how they are affected by IE11. Perhaps most notable of all, after decades of hacking layouts on the web, we finally have CSS grid, which massively simplifies responsive layout. Together with CSS custom properties, object-fit, display: contents and intrinsic sizing, they’re all examples of useful CSS features that are likely to leave a website looking broken if they’re not supported. We’ve had some major additions to CSS over the last five years. It’s the cumulative weight of so many things that undermines IE as much as one killer feature.
While many additions to the web over the last five years have been related to layout and styling, we’ve also had huge steps forwards in functionality, such as Progressive Web Apps. Not every modern API is unusable for websites that need to stay backwards compatible. Most can be wrapped in an if statement.
if ('serviceWorker' in navigator) {
// do some stuff with a service worker
} else {
// ???
}You will, however, be delivering a very different experience to IE users. Increasingly, support for IE will limit the choice of tools that are available as library and frameworks utilize modern features.
Take this announcement from Evan You about the release of Vue 3, for example:
The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support.
The Vue 3 codebase makes use of proxies — a JavaScript feature that cannot be transpiled. MobX is another popular framework that also relies on proxies. Both projects will continue to maintain backwards-compatible versions, but they’ll lack the performance improvements and API niceties gained from dropping IE. Pika, a great new approach to package management, requires support for JavaScript modules, which are not supported in IE. Then there is shadow DOM — a standardized part of the modern web platform that is unlikely to degrade gracefully.
Supporting it takes tremendous effort
When assessing how much extra work is required to provide backwards compatibility for a deprecated browser like IE11, the long list of unimplemented features is only part of the problem. Browsers are incredibly complex pieces of software and, despite web standards, browsers are inconsistent. IE has long been the most bug-ridden browser that is most at odds with web standards. Flexbox (a technology that developers have been using since 2013), for example, is listed on caniuse.com as having partial support on IE due to the “large amount of bugs present.”
IE also offers by far the worst debugging experience — with only a primitive version of DevTools. This makes fixing bugs in IE undoubtedly the most frustrating part of being a developer, and it can be massively time-consuming — taking time away from organizations trying to ship features.
There’s a difference between support — making sure something is functional and looks good enough — versus optimization, where you aim to provide the best experience possible. This does, however, create a potentially confusing grey area. There could be differences of opinion on what constitutes good enough for IE. This comment about IE9 from Dave Rupert is still relevant:
The line for what is considered “broken” is fuzzy. How visually broken does it have to be in order to be functionally broken? I look for cheap fixes, but this is compounded by the fact the offshore QA team doesn’t abide in that nuance, a defect is a defect, which gets logged and assigned to my inbox and pollutes the backlog…Whether it’s polyfills, rogue if-statements, phantom styles, or QA kickbacks; there are costs and technical debt associated with rendering this site on an ever-dwindling sliver of browsers.
If you’re going to take the approach of supporting IE functionally, even if it’s not to the nth degree, still confines you to polyfill, transpile, prefix and test on top of everything else.
It’s already been abandoned by many top websites
Popular websites to officially drop support for IE include Youtube, GitHub, Meetup, Slack, Zendesk, Trello, Atlassian, Discord, Spotify, Behance, Wix, Huddle, WhatsApp, Google Earth and Yahoo. Even some of Microsoft’s own product’s, like Teams, have severely reduced support for IE.
Twitter displays a banner informing IE users that they will not receive the best experience and redirects users to a much older version of the Twitter website. When we think of disruptive companies that are pushing the best in web design, Monzo, Apple Music and Stripe break horribly in IE, while foregoing a warning banner.
Why the new Chromium-powered Edge browser matters
IE usage has been on a slower downward trend following an initial dramatic fall. There’s one primary reason the browser continues to hang on: ancient business applications that don’t work in anything else. Plenty of large companies still use applications that rely on APIs that were never standardized and are now obsolete. Thankfully, the new Edge looks set to solve this issue. In a recent post, the Microsoft Edge Team explained how these companies will finally be able to abandon IE:
The team designed Internet Explorer mode with a goal of 100% compatibility with sites that work today in IE11. Internet Explorer mode appears visually like it’s just a part of the next Microsoft Edge…By leveraging the Enterprise mode site list, IT professionals can enable users of the next Microsoft Edge to simply navigate to IE11-dependent sites and they will just work.
.@MicrosoftEdge: one browser for all web experiences. IE mode will allow you to view and access legacy sites directly in the same window. #MSBuild https://t.co/NXcDjDB5B4 pic.twitter.com/x7BtCtASNs
— Microsoft Edge Dev (@MSEdgeDev) May 6, 2019
After using the beta version for several months, I can say it’s a genuinely great browser. Dare I say, better than Google Chrome? Microsoft are already pushing it hard. Edge is the default browser for Windows 10. Hundreds of millions of devices still run earlier versions of the operating system, on which Edge has not been available. The new Chromium-powered version will bring support to both Windows 7 and 8. For users stuck on old devices with old operating systems, there is no excuse for using IE anymore. Windows 7, still one of the world’s most popular operating systems, is itself due for end-of-life in January 2020, which should also help drive adoption of Edge when individuals and businesses upgrade to Windows 10.
In other words, it’s the perfect time to drop support.
Performance costs
All current browsers support ECMAScript 2015 (the latest version of JavaScript) — and have done so for quite some time. Transpiling JavaScript down to an older (and slower) version is still common across the industry, but at this point in time is needed only for Internet Explorer. This process, allowing developers to write modern syntax that still works in IE negatively impacts performance. Philip Walton, an engineer at Google, had this to say on the subject:
Larger files take longer to download, but they also take longer to parse and evaluate. When comparing the two versions from my site, the parse/eval times were also consistently about twice as long for the legacy version. […] The cost of shipping lots of unneeded JavaScript to low-end mobile browsers can be significant! We (on the Chrome team) have seen numerous occurrences of polyfill bloat adding seconds to the total startup time of websites on low-end mobile devices.
It’s possible to take a differential serving approach to get around this issue, but it does add a small amount of complexity to build tooling. I’m not sure it’s worth bothering when looking at the entire picture of what it already takes to support IE.
Yet another example: IE requires a massive amount of polyfills if you’re going to utilize modern APIs. This normally involves sending additional, unnecessary code to other browsers in the process. An alternative approach, polyfill.io, costs an additional, blocking HTTP request — even for modern browsers that have no need for polyfills. Both of these approaches are bad for performance.
As for CSS, modern features like CSS grid decrease the need for bulky frameworks like Bootstrap. That’s lots of extra bites we’re unable to shave off if we have to support IE. Other modern CSS properties can replace what’s traditionally done with JavaScript in a way that’s less fragile and more performant. It would be a boon for both performance and cost to take advantage of them.
Let’s talk money
One (overly simplistic) calculation would be to compare the cost of developer time spent on fixing IE bugs and the amount lost productivity working around IE issues versus the revenue from IE users. Unless you’re a large company generating significant revenue from IE, it’s an easy decision. For big corporations, the stakes are much higher. Websites at the scale of Amazon, for example, may generate tens of millions of dollars from IE users, even if they represent less than 1% of total traffic.
I’d argue that any site at such scale would benefit more by dropping support, thanks to reducing load times and bounce rates which are both even more important to revenue. For large companies, the question isn’t whether it’s worth spending a bit of extra development time to assure backwards compatibility. The question is whether you risk degrading the experience for the vast majority of users by compromising performance and opportunities offered by modern features. By providing no incentive for developers to care about new browser features, they’re being held back from innovating and building the best product they can.
It’s a massively valuable asset to have developers who are so curious and inquisitive that they explore and keep up with new technology. By supporting IE, you’re effectively disengaging developers from what’s new. It’s dispiriting to attempt to keep up with what’s new only to learn about features we can’t use. But this isn’t about putting developer experience before user experience. When you improve developer experience, developers are enabled to increase their productivity and ship features — features that users want.
Web development is hard
It was reported earlier this year that the car rental company Hertz was suing Accenture for tens of millions of dollars. Accenture is a Fortune Global 500 company worth billions of dollars. Yet Hertz alleged that, despite an eye-watering price tag, they “never delivered a functional site or mobile app.”
According to The Register:
Among the most mind-boggling allegations in Hertz’s filed complaint is that Accenture didn’t incorporate a responsive design… Despite having missed the deadline by five months, with no completed elements and weighed down by buggy code, Accenture told Hertz it would cost an additional $10m – on top of the $32m it had already been paid – to finish the project.
The Accenture/Hertz affair is an example of stunning ineptitude but it was also a glaring reminder of the fact that web development is hard. Yet, most companies are failing to take advantage of things that make it easier. Microsoft, Google, Mozilla and Apple are investing massive amounts of money into developing new browser features for a reason. Improvements and innovations that have come to browsers in recent years have expanded what is possible to deliver on the web platform while making developers’ lives easier.
Move fast and ship things
The development industry loves terms — like agile and disruptive — that imply light-footed innovation. Yet rather than focusing on shipping features and creating a great experience for the vast bulk of users, we’re catering to a single outdated legacy browser. All the companies I’ve worked for have constantly talked about technical debt. The weight of legacy code is accurately perceived as something that slows down developers. By failing to take advantage of what modern browsers have to offer, the code we write today is legacy code the moment it is written. By writing for the modern web, you don’t only increase productivity today but also create code that’s easier to maintain in the future. From a long-term perspective, it’s the right decision.
Recruitment and retainment
Developer happiness won’t be viewed as important to the bottom line by some business stakeholders. However, recruiting good engineers is notoriously difficult. Average tenure is low compared to other industries. Nothing can harm developer morale more than a day of IE debugging. In a survey of 76,118 developers conducted by Mozilla “Having to support specific browsers (e.g. IE11)” was ranked as the most frustrating thing in web development. “Avoiding or removing a feature that doesn’t work across browsers” came third while testing across different browsers reached fourth place. By minimising these frustrations, deciding to end support for IE can help with engineer recruitment and retainment.
IE users can still access your website
We live in a multi-device world. Some users will be lucky enough to have a computer provided by their employer, a personal laptop and a tablet. Smartphones are ubiquitous. If an IE user runs into problems using your site, they can complete the transaction on another device. Or they could open a different browser, as Microsoft Edge comes preinstalled on Windows 10.
The reality of cross-browser testing
If you have a thorough and rigorous cross-browser testing process that always gets followed, congratulations! This is rare in my experience. Plenty of companies only test in Chrome. By making cross-browser testing less onerous, it can be made more likely that developers and stakeholders will actually do it. Eliminating all bugs in browsers that are popular is far more worthwhile monetarily than catering to IE.
When do you plan to drop IE support?
Inevitably, your own analytics will be the determining factor in whether dropping IE support is sensible for you. Browser usage varies massively around the world — from almost 10% in South Korea to well below one percent in many parts of the world. Even if you deem today as being too soon for your particular site, be sure to reassess your analytics after the new Microsoft Edge lands.
If I could, I would drop support for IE on every project immediately. Unfortunately, working with enterprise clients who only ever use default Microsoft software combined with Microsoft’s insistence that no feature ever be removed from a new version of Windows means they’ll be using IE for at least another decade.
And don’t worry, Safari will be taking Internet Explorer’s place.
Safari’s not a real danger. Questionable decisions? For sure. But it’s an evergreen browser that won’t stifle users from upgrading the same way IE did for many years.
People have a really short memory and a distorted view of the past. The real issue with IE was that it became so dominant that nobody bothered to make their sites work in any other browser. Sounds a lot like the situation we have now with Chrome…
So true! Safari doesn’t even support all HTML5 Input types.
And this is how the chrome-fanboi culture lives on. This reduces the freedom of the web. Instead of proposing standards and unifying, people want to build around a browser and just make that the standard.
This is not “chrome-fanboi culture”. Also it does not “reduce freedom of the web”
Internet Explorer is the one not following the standardized features of web browsers by not being developed for over half a decade.
In fact it was Internet Explorer not following the standards in the first place by implementing all the microsoft-specific features that are the reason enterprise applications only work inside of IE
Don’t see anyone complaining about Firefox, just the “sick person” of the internet
I have no doubt that when asked with no other context, every web developer would say “Yes, I would love to drop support for IE.” I’m sad to see the author has fallen into the shallow argument against IE that lives primarily on the internet and that completely ignores it’s huge usage numbers in the enterprise (where it is often mandated as the only browser available by corporate IT departments) and in the developing world. I wish there would have been even an acknowledgement of these valid instances that cover millions of people, but instead we get “Look, [popular with web developers thing] dropped IE support, so you can too!”
The author did mention this exact thing though?
Firstly this is a developer case not a business case. Even in the money section you revert back to the developer experience. And it’s not that hard support IE11, in my experience revenue gained from IE11 is higher than the cost to develop for it.
Why not have some empathy with IE11 users, instead of looking at it from a developer point of view “I want to use new features”. Try to understand why users have stuck with IE11… there are a number of social and economic reasons why they stay
“Firstly this is a developer case not a business case. ”
Totally agree.
The article makes valid points the vast majority if not all of us agree on, but they are technical points.
IE11 comes with Windows, and in corporate realities this means having support and a clear chain of responsibility.
That’s a question my boss asked last week, actually.
I’m no pro whatsoever, but I can read numbers. On a personal level, I’m a 100% in favor of dropping IE support. I thought the readings would support my case and at first glance, they did. Less than 5% of the visitors use some version of IE. Me? Overjoyed.
But a deeper look cold-showered me: those 5% represented a little bit more than 10% of our business. Can’t overlook one tenth.
Yeah. I’m still crying out loud.
I like Chromium, but I’m no fan of the “chrome-fanboi culture” (to cite upper post). And yeah, there are factors you can’t ignore. Like, what if one of your main supplier only relies on IE?
Internally, we use Vivaldi / Firefox / Waterfox / Edge extensively. Actually anything BUT IE! Depends on personal choices and/or needs. But I can’t manage what the IT department imposes to the guy I’m on the phone with.
All in all, your surveys and analytics should give you a pretty clear answer.
Just as a sidenote, transpiled code are not necessarily slower (usually it’s faster). That’s because the native counterparts implementation are doing extra checks and procedures to be standard compliant.
I abandoned IE support long ago. I used to hinder myself by trying to support all the way back to IE6, but then I realized how fundamental broken all that was. With all of the vulnerabilities and downgrade attacks of SSL, I was actually putting users at risk by supporting old browsers, as well as massively increasing the difficulty of development and limiting the features I could implement.
But I don’t see it as excluding browsers. Rather, it’s minimum supported features. If your browser doesn’t support modules, classes, and async/await, it doesn’t meet the requirements.
That used to be ok for purchased computer software. Why should it be an issue for a free website, especially when better browsers are available for free.
Anyways, Safari is definitely the current obstacle. Just because it’s “evergreen” doesn’t mean it’s modern. Safari is so far behind and has so many bad implantations, including something as simple as
Date.I make sure for years, that my users get a HUUUGE security alert popup if they use an old browser. Something for you, S.
It takes care about the customer and reminds him friendly, STOP DOING NONSENSE!
After you ran this a while you will get below 5%.
Nice. Now think about the elder people that are running IE, because they don’t even know what a browser is. How is your alert popup different from the “you have 8 viruses, click here to fix” prompts and all the other spammy things they get all the time, and that we teach them to never click on?
Nobody is using IE willingly. Nobody. The simply are not tech savvy enough to install any other browser, or locked in corporate / government devices that won’t allow them to install anything. An alert popup won’t change that. I’d bet you see the % drop simply because of users not returning due to the annoying popup rather than them switching to a newer browser.
“After you ran this a while you will get below 5%.”
Below 5% ?
Just like Safari or Firefox ??
While I think every single one of those are valid points, I believe you’re missing the real causes for IE use, and therefore arriving at questionable conclusions.
“ancient business applications that don’t work in anything else” is a misconception. If that was the source for IE use in other websites, people would simple run IE in their ancient app and whatever evergreen browser for everything else.
The true cause is simply people not knowing better, or locked in corporate systems that won’t allow them the choice either.
I still find senior citizens and elderly people that refer to the IE icon as “the internet”. They don’t know what a browser is, they don’t even recon the icon as a shortcut… the IE logo is the internet. We can’t reasonably expect them to install a new browser, no matter how many banners and prompts we throw at them. Specially since the very first thing we all teach non-tech-savvy people is “do not install anything”
As for corporate / government locked devices, they might be running IE or even locked in older versions of “evergreen” browsers. Check the use stats for anything at caniuse, and you’ll see small percentages of really old versions of Chrome, Firefox, Edge and Safari still in use.
The moment we decide not to support IE, we’re also not supporting people locked in older versions of evergreen browsers, or current versions of smaller browsers, specially those developed for low-resource devices. We tend to focus on the 1-1.5% that runs IE, and conveniently forget about other browsers that can stack up to 5-10% depending on the given feature.
A better solution, at least for the CSS aspect, is simply using progressive enhancement. If you’re gonna use grid and can’t be bothered to build a fallback, a simple media query will make sure that anyone accessing the web / app on a browser that don’t support grid gets the browser default, i.e. block layout.
In most cases, if building with a mobile-first mindset, we can serve lacking browsers with pretty much the same layout as mobile devices, completely cutting the cost of maintaining another layout. Yes, their experience will be different, but there’s nothing wrong with that.
I recon it could get more complicated on the JS side of things. There are techniques that will only serve the polyfills and transpilations to the browsers that needs them, keeping the performance costs at a negligible level for everyone else. Still as you correctly pointed out there are features that simply cannot be transpiled, so they should be treated with more care. But completely dropping the support is not the right approach for most cases in my opinion.
IE support is not about supporting IE. It’s about supporting the elder, the poor, and people running locked devices.
Microsoft stopped developing Internet explorer a few years ago & launched Microsoft edge in its place. Internet explorer was outdated, hardly anyone used to use it back in the day. The business case for dropping Internet explorer is well explained here & I think that change was needed.