【译】这些理由告诉你，你早就该放弃支持 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 频道 ，欢迎点赞和订阅！最后，感谢你阅读本文，祝你有美好的一天！