前言

之前尤雨溪曾说过，Vue3 将会出一个 IE11 的兼容版本，现在 Vue3.0都已经发布很久了，却迟迟不见兼容版本的出现，原来是因为微软积极的推进自家的新 Edge 浏览器，并打算放弃 IE，这让尤雨溪同学觉得兼容 IE 是否还有必要，来看看他的知乎：

译文

从 Vue3 开始开发的时候一直到2018年底，我们一直被问到有关 IE11 的支持。许多用户都在问 Vue3 是否会支持 IE11，我们最初的计划是先发布 Vue3 的稳定版，然后稍后才会支持 IE11。在漫长的开发过程中，我们还就 IE11 的兼容性进行了研究和实验，但是由于所涉及的复杂性和手头上的其他的大量工作，因此 IE11 就先暂时放了一放。

当我们再看一下 2021 年的现在的问题时，浏览器和 JavaScript 的状况已经发生了很大变化。现在，越来越多的开发人员正在使用现代语言功能，更重要的是，微软本身已经开始通过对 Edge 的推广，积极地将用户推离 IE。甚至还在自己的主要项目(如Microsoft 365)中放弃对 IE11 的支持。就在几天前，WordPress 也决定了放弃对 IE11 的支持。IE11 的全球使用率已降至1％以下。当我们谈论面向公众的网站和应用程序时，IE11呈明显的快速下降趋势。

我们相信这是一个重新思考 Vue3 对 IE11 支持的机会。

在Vue 3中支持IE11的成本

行为不一致

Vue2 的响应式系统是基于 ES5 的 getter / setter。Vue3 利用 ES6 的 Proxy 获得了性能更高且更完整的响应式系统，但 Proxy 却无法在 IE11 中进行 polyfill。这是最大的障碍，因为这意味着如果 Vue3 要支持IE11，它实际上需要发布两个具有不同行为的不同版本：一个是基于 Proxy 的响应式系统，而另一个则使用类似于 Vue2 的基于 ES5 的 getter / setter 的系统。

Vue3 基于 Proxy 的响应式系统提供了几乎完整的语言功能覆盖。它能够检测许多在 ES5 中不可能或不可行的操作，例如属性的添加、删除、数组索引和length突变以及in操作符的检查等功能。为 Vue3 的 Proxy 版本编写的相同代码在 IE11 版本中根本不起作用。这不仅给我们带来了技术上的复杂性，也给开发人员带来了持续的精神负担。

我们最初的计划是在 IE11 的开发版本中同时交付 Proxy 和 ES5 的响应式实现。当它在支持 Proxy 的开发环境中运行时，它将检测并警告不兼容 IE11 的用法。从理论上讲，这是可行的，但由于需要将这两种实现混合在一起，并且在开发和生产之间存在行为差异的风险，因此造成了极大的复杂性。

长期维护负担

支持 IE11 还意味着我们必须考虑整个代码库中使用的语言功能，并为我们的分包找出正确的 polyfill 策略。IE11 中无法被 polyfill 的每个新功能的添加都会造成另一个行为的警告。一旦 Vue3 承诺了对 IE11 的支持，我们将无法摆脱它，直到下一个主要版本(Vue4)。

库作者的复杂性

如果复杂度可以完全包含在 Vue 本身中，那么在某种程度上仍然可以接受。但在与社区成员讨论之后，我们意识到两种响应式实现的共存也不可避免的会暴露给库作者。

通过在 Vue3 中支持 IE11，库作者将不得不考虑其库运行的 Vue3 的内部版本（可能还得支持 Vue2）如果他们决定支持 IE11，则必须考虑用 ES5 的响应式原理来编写他们的库。

为 IE11 贡献持久力

没有人喜欢支持 IE11。这是已经被淘汰掉的浏览器。当网络生态系统向前发展的越远，我们在尝试支持它时需要克服的差距就越大。而具有讽刺意味的是，如果在 Vue3 中支持 IE11，那就相当于我们给了它更多坚挺的理由。鉴于我们的用户群，放弃 IE11 的支持可能会使其淘汰的更快。

对于绝对需要IE11支持的用户

我们深知，对于那些真正需要 IE11 的人：金融机构、教育部门以及依赖 IE11 屏幕阅读器的人们。如果要构建针对这些领域的应用程序，则可能别无选择。

如果真的需要兼容 IE11，我们的建议是使用 Vue2。因为与其为 Vue3 和 Vue 的未来版本承担大量技术负担，还不如将工作重心转向将兼容功能向后移植到 2.7 版本中的 Vue2 呢。并且确保在两个主要版本中获得更近的开发体验将更加的有意义。

可以反向移植到2.7的一些功能：

将 @vue/composition-api 插件合并到 Vue2 中。这将使基于 Composition API的库直接适用于 Vue2 和 Vue3
<script setup> 单文件组件中的语法
emits 选项
改进的 TypeScript 支持。
在 Vite 中正式支持 Vue2