Browsers are incredibly complex programs. But even though web standards were introduced in 1998, many browsers are still incompatible with them. IE has long been the most problematic browser, the one that violated web standards the most.
Flexbox (a technology that developers have been latest phone number database using since 2013), for example, is listed on caniuse.com as having partial support on IE due to " a lot of bugs ."
IE also has the most primitive version of DevTools, making fixing IE bugs undoubtedly the most frustrating part of any developer's job. It's a huge time sink when developing web services and web applications.
There's a difference between support (where you can visually verify that everything works and looks good enough) and optimization, where you aim to provide the best experience possible. This creates a potentially confusing gray area and doesn't provide a clear definition between the two, much less what's good enough for IE.
This comment about IE9 from Dave Ruppert is still relevant:
The line on what is considered "broken" is fuzzy. How visually broken does it have to be for it to be functionally broken? I look for cheap fixes, but this is compounded by the fact that the QA team doesn't understand this nuance, a bug is still a bug that gets logged and assigned to my inbox... Whether it's polyfills, if-condition workarounds, or phantom styles; there is cost and technical debt associated with running a site on an ever-shrinking browser slate.
If the IE functional support approach is used, web developers' hands will be tied in their choice of tools (polyfills, transpilation, etc.) and after all this, long and painful testing will be required.
Most top sites have dropped IE support
Popular sites that have officially dropped IE support include: YouTube, GitHub, Slack, Zendesk, Trello, Discord, Spotify, Behance, Wix, Huddle, WhatsApp, Google Earth, and VKontakte. Even Microsoft's own products, such as Teams, have significantly reduced their IE support.
Twitter displays a banner informing IE users that they will not get the best experience on IE and redirects users to the old mobile version of the Twitter site.
Why Internet Explorer is still used today
The rapid decline of IE users after the initial dramatic drop has slowed down for now. There is one main reason the browser continues to hold on: ancient business applications that don’t work in any other browser. Many large companies still use applications that rely on APIs that were never standardized and are now obsolete.
Luckily, the new Edge seems to have solved this problem. In a recent post, the Microsoft Edge Team explained how these companies can finally move away from IE:
The team designed Internet Explorer mode to be 100% compatible with sites that run in IE11 today. Internet Explorer mode looks like it's just part of the new Microsoft Edge... Using Enterprise mode, IT can enable users of the new Microsoft Edge to simply go to sites that depend on IE11, and they'll work.
says on Twitter
After using the beta version for several months, beta testers say it’s a really great browser. Edge is the default browser for Windows 10. Hundreds of millions of devices are still running earlier versions of the operating system, on which Edge wasn’t available. The new Chromium-based version will provide support for both Windows 7 and 8. For users stuck on older devices with older operating systems, there’s no excuse to use IE anymore.
In other words, now is the time to drop support for IE.
Performance costs
All modern browsers support ECMAScript 2015 (the latest version of JavaScript), and have done so for quite some time. Transpilation (translating JavaScript into an older (and slower) version of ECMAScript) is still common in the industry, but is currently only required for Internet Explorer. This process, which allows developers to write modern syntax that still works in IE, has a negative impact on performance. Philip Walton, an engineer at Google, put it this way :
Large files take longer to download, but they also take longer to parse and evaluate. When comparing two versions of my site, the parse/compare time was about twice as long for the older version. [...] The cost of supporting a lot of unnecessary JavaScript for low-end mobile browsers can be significant! We (on the Chrome team) have seen numerous cases of file bloat adding seconds to the overall startup time of sites on low-end mobile devices.
A different approach to serving can be used to work around this, but it adds a small layer of complexity to the tooling constraints. I'm not sure it's worth worrying about when you look at the big picture of what's already required to support IE.
Another example: IE requires a lot of polyfills if you want to use modern APIs. This usually means sending extra, unnecessary code to other browsers in the process. An alternative approach, polyfill.io , takes a request for a set of browser features and returns only the polyfills needed by the requested browser. Both approaches are bad for performance.
In terms of CSS, modern features like CSS Grid reduce the need for cumbersome frameworks like Bootstrap. Other modern CSS features can replace some of the work traditionally done with JavaScript, making it less brittle and more performant. However, IE support means you have to use techniques that are not as good in terms of performance or time.
