本文转载于 SegmentFault 社区

原文作者：Areknawo

译者：Chor

---

2025 年 10 月 14 日 —— 记住这个日子，据说 （非官方说法） 这一天过后，微软就不再支持 IE11 了。为什么我要告诉你这件事呢？因为，正如你可能知道的，IE 作为一款浏览器让广大 web 开发者大伤脑筋。不过它真就那么差吗？在 2020 年你是否还需要提供对 IE 的支持呢？

No.1

聊点历史

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 的合体状态！

No.2

残缺的特性

让我们回到正题。最近，在进行这个网站 （译注：指作者的个人网站） 的重构时，我在考虑为了支持 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 这样的工具进行处理，但还是太麻烦了，毕竟大多数浏览器都完全可以支持前面所说的那些特性。

No.3

案例学习

出于撰写文章的需要，我不得不离开舒适的 Linux，前往 Windows 10 最黑暗的一角 —— IE 11。不得不承认 —— 这个浏览器的体验和性能实在是差强人意。我忍不住回想起所有关于 IE 的点滴笑话;)。不管怎么说，既然我们对 IE 11 受限的特性有了一定了解，现在让我们浏览一些网站，看看它们是如何工作的吧！

Areknawo

https://areknawo.com/

IE 11 上的 Areknawo

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

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

YouTube

https://www.youtube.com/

IE 11 上的 YouTube

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

GitHub

https://github.com/

IE 11 上的 GitHub

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

CodePen

https://codepen.io/

IE 11 上的 CodePen

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

CSS-Tricks