- 原文地址：Why you should have ditched IE support long ago…
- 原文作者：Areknawo
- 译者：Chor
2025 年 10 月 14 日 —— 记住这个日子，据说（非官方说法）这一天过后，微软就不再支持 IE11 了。为什么我要告诉你这件事呢？因为，正如你可能知道的，IE 作为一款浏览器让广大 web 开发者大伤脑筋。不过它真就那么差吗？在 2020 年你是否还需要提供对 IE 的支持呢？
聊点历史
Internet Explorer（IE）是一款最初由微软在 1995 年发布的 web 浏览器。那时 web 浏览器刚诞生不久，标准也没有广为遵循。JavaScript 甚至还在“襁褓”之中（它是在 1995 年 12 月发布的），而各个浏览器都有自己的非标准特性、附加组件以及插件。
因此，微软在 1995 年带着 IE 进军浏览器市场的时候，几乎没有遇到竞争对手（除了 网景导航者）。在最初的版本发布后不久，微软就开始在其非常流行的操作系统 —— Windows 的每一个新版本中免费提供 IE。这带动了 IE 使用量的急剧增加，在 21 世纪初它的市场份额已经超过了 90%。当然，这里面并不乏反垄断以及权力滥用的争议，但这里不敞开聊这些。
“抱歉，该网站只能在 IE 运行”，类似这样的对话框和弹出窗口一度充斥用户屏幕。不过，这一切很快就结束了，因为微软没有能力改进自己的 web 浏览器，反而是引入了各种奇怪的特性。这个时期，Web 的可访问性得到增强，其它 web 浏览器开始进军市场（比如 2008 年的 Google Chrome）。再加上移动端（IE Mobile —— 曾经也是有这么一个东西的）的兴起，导致 IE 的市场份额持续下跌，现在只有大约 1.5%。
再过几天，也就是 2020 年 1月 15 号，带有全新图标并以 Chromium（Chrome，Opear 以及许多其它的浏览器都使用了该内核）作为内核的 新版本 Edge 将卷土重来。这一次，微软会再次尝试赢回自己的用户群。你可以在这里下载该浏览器的 beta 版本，我不得不承认 —— 这款浏览器属实可以。有点像 Edge 和 Chrome 的合体状态！
残缺的特性
让我们回到正题。最近，在进行这个网站（译注：指作者的个人网站）的重构时，我在考虑为了支持 IE 得做多少工作。结果表明 —— 相当相当多！所以，对那些占比不到 0.4% 的仍然使用 IE 浏览器的读者们，我感到抱歉，因为往后我就不会再支持 IE 了。为了证明我的选择是正确的，我们来设想一下一个网站为了支持 IE 11（这里考虑的甚至不是更古早的版本）需要放弃多少东西。
JavaScript
2015 年 ES6 的推出使得 JS 人气暴涨。由于 IE 11 是在 2013 年推出的，并于不久后的 2015 年被 Edge 取代，因此它没有办法支持现代 ES6 的特性。也许你认为这算不上一个问题，毕竟类似 Babel 这样的工具可以近乎完美地解决兼容性问题。不过，有些特性是没办法通过 polyfill（用“旧”代码替换） 解决的。此外，大部分浏览器也都支持 ES6，这时候仍然采用 polyfill，只会造成不必要的代码臃肿和开发流程复杂化。
EcmaScript 6
Can I Use 上的数据表明，IE 11 不支持大部分 EcmaScript 6（ES6）的特性。这意味着它无法使用诸如箭头函数或者是类这样的语法糖，也无法使用诸如 Promise 或 WeakSet 这样的新特性。其它的，诸如（Weak）Map、Set 以及 let/const 变量声明，只得到了部分支持。当然，比 ES6 更新的特性也很少见（如果有的话）。
这样的例子还有很多，但我不想吹毛求疵。其它浏览器的旧版本也不支持某些特性，但它们要么经常（无缝地）更新，要么没有那么流行。
Web API
由于 Web API 不是 JavaScript 本身的一部分，因此它允许在 Web 上使用一些独有的功能。然而，与那些涉及语法的特性不同，这些功能在大部分情况下都是没有办法通过 polyfill 实现的。
从更相关的 Web API 来看，IE 缺乏对 Fetch API、Web Notifications 以及 WebRTC 的支持。而这三者之中只有 Fetch API 有对应的通过使用 XMLHttpRequest 实现的 polyfill。值得庆幸的是，Notification API 和 WebRTC 都是为现代的、功能丰富的 web 应用而设计的，这些应用从一开始就没有打算面向 IE。
还有一些 Web API 只得到部分支持。最显而易见的也许就是 WebGL 了。WebGL 2 很显然是不支持的，这我们都清楚，但重点在于 IE 11 甚至要通过 "experimental-webgl" 标识符而不是标准的 "webgl" 来访问 WebGL 上下文。
HTML/CSS
如果你想要增加难度的话，可以创建一个不使用 JavaScript 的网站。不过一想到有服务端渲染（SSR）或者 JAMStack（静态网站）这类技术作为支撑 —— 这实际上也并不会很难。但我们没办法不使用 CSS，更别提 HTML 了！不幸的是，IE 恰恰就有很多 HTML 和 CSS 方面的问题。我们来举几个例子。
HTML
就 HTML 而言，问题还没那么大 —— 如果你认为对 HTML5 只能做到部分支持“不算问题”的话。抛开一些标准本身发布后才引入的特性不谈，IE 并没有缺失对大部分 HTML 特性的支持，所以这方面问题不大。
CSS
但 CSS 可就不一样了。IE 对很多重要的特性都只能做到部分支持，诸如 弹性布局、网格布局、CSS 变量以及视口单位（如 vmax）。有的可以使用前缀实现，有的则要么缺乏某些功能，要么只支持旧的、不兼容的规范版本。CSS 仍然可以依靠诸如 PostCSS 这样的工具进行处理，但还是太麻烦了，毕竟大多数浏览器都完全可以支持前面所说的那些特性。
案例学习
出于撰写文章的需要，我不得不离开舒适的 Linux，前往 Windows 10 最黑暗的一角 —— IE 11。不得不承认 —— 这个浏览器的体验和性能实在是差强人意。我忍不住回想起所有关于 IE 的点滴笑话;)。不管怎么说，既然我们对 IE 11 受限的特性有了一定了解，现在让我们浏览一些网站，看看它们是如何工作的吧！
Areknawo
老实说，我并不打算修复这个小问题 —— 尤其是进行不兼容 IE 的重构时。因为这没啥意义。这个博客是面向 web 开发人员或者”技术“人员的，而他们通常会使用最新的、最好的工具。大部分的目标用户群体根本不使用 IE，就算使用了…兴许也只是为了做测试 😉。
YouTube
GitHub
CodePen
CSS-Tricks
其它网站
如果你觉得上面这些案例不够，你还可以用 IE 11（如果你使用的是 Windows 10 —— IE 11 可能还在） 打开你经常浏览的网站。然后，你就能切身体会到我这一路上经历的痛楚了！😉
结束语
本文的主要目标就是为了告诉你，已经没有必要兼容 IE 了。在使用现代特性时，你应该会觉得更加放得开，尤其是着手新项目的时候。
我听说一些企业依赖于只能在 IE 上运行的代码，并且承担不起更新的成本。依我之见，这种设计太差了 —— 无意冒犯。互联网从来都是不断变化和发展的，唯有学会适应和改变才能存活下来。如果你的 app 不允许你这么做，那么它就是失败的。这只是我个人的观点。事实上，我甚至浏览过一个 —— 说来好笑，连 IE 11 都不支持的网站！只有使用旧版本的浏览器才能正常访问该网站 —— 尽管这些浏览器早就不被支持了。
所以，除非你面向的用户群体非常广泛且特殊，否则我会劝告你：不要在 IE 上花太多功夫。如果对 IE 的支持不会给你带来任何损失或者是限制你产品的功能，那尽管去支持好了！不过，想想我们前面讨论过的那些特性，现实往往是残酷的…
好了，本文内容到这里就结束了！你对支持 IE 这件事的看法是什么？你的网站又是否会支持 IE 呢？请在底下的评论发表你的看法。另外，如果你喜欢这篇文章的话，可以把它分享给其他人，并关注我的 Twitter 和 Facebook，或者是通过 weekly newsletter 实时获取我的最新文章。如果你感兴趣的话，也可以关注我的 YouTube 频道 ，欢迎点赞和订阅！最后，感谢你阅读本文，祝你有美好的一天！