【译】这些理由告诉你，你早就该放弃支持 IE 了......

• 原文地址：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%。

浏览器市场份额统计表

最后，甚至连微软也承认自己在 web 浏览器上的败北。因此，微软在 2015 年发布 Windows 10 的同时，还发布了一款全新的 Edge 浏览器，该浏览器完全重写了以前的内部代码。不过，低市场份额以及用户普遍怀揣着“安装 Chrome 浏览器就够用了”的心态，无不说明这款浏览器难担大任。微软不得不另辟蹊径。

再过几天，也就是 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 11 上的 Areknawo

首先从我的博客网站开始。在当前的版本中，它表现得还挺好的，只是 JavaScript 无法运行。顶部广告无法显示，订阅通知框以及每篇博文下的 Disqus 评论消失了，AJAX 页面转换失效。所有的这一切都归功于......IE 不支持我在代码中使用的 ES6 模板字符串！

老实说，我并不打算修复这个小问题 —— 尤其是进行不兼容 IE 的重构时。因为这没啥意义。这个博客是面向 web 开发人员或者”技术“人员的，而他们通常会使用最新的、最好的工具。大部分的目标用户群体根本不使用 IE，就算使用了......兴许也只是为了做测试 ;)。

YouTube

IE 11 上的 YouTube

在 IE 上打开 YouTube 感觉就像是回到了过去。一切正常，但 UI 已经过时了。貌似谷歌给 IE 留下了最后一个兼容的版本。明智之举。但是对于小组织和小公司来说，维护同一网站的旧版本可能有点浪费资源。

GitHub

IE 11 上的 GitHub

GitHub 直接了当地告诉你，你当前使用的浏览器是不受支持的。有意思的是，GitHub 现在是属于微软的。不过我并不是在责备他们 —— 他们的做法没错。不管怎样，你可以关闭这个小对话框，但紧接着你会发现工具栏是坏的，登录页面似乎也有问题，一直显示在加载中。出于安全性考虑，我没有尝试进行登录 —— IE 过去发生了很多安全性问题。

CodePen

IE 11 上的 CodePen

CodePen 同样显示了一个对话框，不过这个对话框更大，而且”无法关闭“。上面说，高级会员可以配合 Debug View 进行使用，不过我没有进行测试，所以这里不发表意见。

CSS-Tricks

IE 11 上的 CSS-Tricks

CSS-Tricks 是一个简单的网站 —— 它使用的 JS 并不多，内容大多都是文本。也没有任何对话框或者信息弹出 —— 只有内容残缺的页面。样式不生效，部分东西无法显示，但至少内容和文章还是可以阅读的。

其它网站

IE 11 上的苹果官网

”反 IE“的网站太多了，我没办法在本文一一穷举。不过，我还是稍微再吐槽一下！流行的生产力工具 Slack 和 Trello 不允许你使用 IE 登录网站，甚至苹果官网首页的布局也是完全崩坏的！其它页面看起来没问题，但是没有华丽的滚动特效，并且无法购买任何东西，除非”更新你的浏览器“ 。

如果你觉得上面这些案例不够，你还可以用 IE 11（如果你使用的是 Windows 10 —— IE 11 可能还在） 打开你经常浏览的网站。然后，你就能切身体会到我这一路上经历的痛楚了！;)

结束语

本文的主要目标就是为了告诉你，已经没有必要兼容 IE 了。在使用现代特性时，你应该会觉得更加放得开，尤其是着手新项目的时候。

我听说一些企业依赖于只能在 IE 上运行的代码，并且承担不起更新的成本。依我之见，这种设计太差了 —— 无意冒犯。互联网从来都是不断变化和发展的，唯有学会适应和改变才能存活下来。如果你的 app 不允许你这么做，那么它就是失败的。这只是我个人的观点。事实上，我甚至浏览过一个 —— 说来好笑，连 IE 11 都不支持的网站！只有使用旧版本的浏览器才能正常访问该网站 —— 尽管这些浏览器早就不被支持了。

所以，除非你面向的用户群体非常广泛且特殊，否则我会劝告你：不要在 IE 上花太多功夫。如果对 IE 的支持不会给你带来任何损失或者是限制你产品的功能，那尽管去支持好了！不过，想想我们前面讨论过的那些特性，现实往往是残酷的......

好了，本文内容到这里就结束了！你对支持 IE 这件事的看法是什么？你的网站又是否会支持 IE 呢？请在底下的评论发表你的看法。另外，如果你喜欢这篇文章的话，可以把它分享给其他人，并关注我的 Twitter 和 Facebook，或者是通过 weekly newsletter 实时获取我的最新文章。如果你感兴趣的话，也可以关注我的 YouTube 频道 ，欢迎点赞和订阅！最后，感谢你阅读本文，祝你有美好的一天！