清明时节雨纷纷，尤大发文欲断魂。没错，小长假这几天，大家又被爱在假期搞事情的尤大的新闻霸屏了，就在 4 月 3 日凌晨，尤大在知乎发了一篇名为“[RFC] 关于 Vue 3 的 IE11 支持”的文章， 内容是关于 Vue 3 不再支持 IE11 的提案：
看到这条消息，心里竟然毫无波澜，因为我们被 IE 拖累实在是太久了。相信很多仍然在做 PC 端页面的同学深受 IE 其害，还记得我在 2009 年第一次做出网页时，还要关注 IE5 的兼容性；曾几何时，IE 兼容性问题还是前端面试的高频题目。一晃 12 年过去，IE11 也终于被微软自己抛弃了。
很多社区的同学第一时间对 RFC 的原文进行了翻译，我假期打了疫苗，一直休息来着，昨天才开始翻译的。除了 RFC 译文之外，我们先来看看这个新闻的一些知识点：
知识点
什么是 RFC
RFC 是英文Request For Comments，意思是征求意见。在 React 也有 RFC。无论是 React 或 Vue，当作者或者开发者想要对其做出大量变化或者添加新特性时，一般都需要撰写一个提案，提案里面需要包含这件事的动机和详细设计。
React 在 2018 年 React Conf 提出的React Hooks就是以 RFC 形式提出的。这次的“关于 Vue 3 的 IE11 支持”也是 RFC，也就意味着，这件事需要征求社区的意见，并不是最终的决定。
不过呢，一般而言，RFC 都是经过深思熟虑的，被提到 RFC 的提案，尤其是作者本人的提案，基本都会通过，只是在讨论中补充更多的细节。
IE11 的现状 —— 亲爹都不爱
微软抛弃旧儿子 IE 浏览器，将更多的精力投入到新儿子 Edge 上来。其很多核心产品都已经不再支持 IE11 了，如 Microsoft 365。如今 IE11 的全球使用率已下降至不足 1%。如此不堪的境遇，老旧的 IE 是该早点消失了。
Vue 不支持 IE11 了吗，IE 用户怎么办
当然不是，Vue 在 2.X 版本仍然支持 IE11，如果你想使用类似 Vue 3 的新特性，可以等等 Vue 2.7 版本。这次的 RFC 宣布，将会对 2.7 版本做向后兼容，移植 3.x 的部分新功能，以保证两个版本之间相似的开发体验。看到尤大的这个做法，我也收获了很多，很多时候换一个思路，就会海阔天空。
RFC 译文
- 原文地址：vue3-ie11-support
- 原文作者：尤雨溪
- 原文发布时间：2021-04-03
- 本文永久链接：https://github.com/Ivocin/Translation/blob/master/Docs/0000-vue3-ie11-support.md
- 翻译、校对：清秋
- 开始日期：2021-04-02
- 目标版本: 3.x
- 参考 Issue：N/A
- 实现 PR：N/A
摘要
- 移除 Vue 3 对 IE11 的支持。
- 将精力转为把兼容特性向前移植到 Vue 2.7 版本中。
动机
从 Vue 3 启动开发开始，一直到 2018 年底，我们一直被问到有关 IE11 支持的问题。很多用户都问过，Vue 3 是否会支持 IE11，我们原本都计划是先发布 Vue 3，让它稳定下来，然后在后续阶段增加对 IE11 的支持。在漫长的开发过程中，我们另外还做了兼容 IE11 的研究和实验，但是由于其复杂性以及手头大量的其他工作，这项工作的优先级就降低了。
当我们在 2021 年再来看这个问题时，浏览器和 JavaScript 的情况都发生了巨大变化。现在更多的开发者使用现代语言特性，更为重要的是，微软自己开始积极推动用户远离 IE，并对 Edge 持续投入精力。它还在自己的主要产品（如 Microsoft 365）中移除了对 IE11 的支持。而就在几天前，WordPress 也做出了移除 IE11 支持的决定。IE11 的全球使用率已下降至不足 1%。当我们谈论面向公众的网站和应用时，IE11 的下滑趋势十分明显。
我们认为这是一个重新思考 Vue 3 支持 IE11 的好机会。
Vue 3 中支持 IE11 的成本
行为不一致
Vue 2 的响应式系统是基于 ES5 的 getter/setters。Vue 3 利用了 ES2015 的 Proxy 实现了一个更高性能、更完备的响应式系统，但无法在 IE11 中 polyfill 这一特性。这是我们最大的障碍，因为这意味着如果我们要支持 IE11，就必须发布两个不同行为的的版本：一个是基于 Proxy 的响应式系统，另一个则是基于和 Vue 2 类似的基于 ES5 的 getter/setters 特性的响应式系统。
Vue 3 的基于 Proxy 的响应式系统提供了近乎完整的语言特性覆盖。它能够检测到许多在 ES5 中完全无法检测的操作，比如属性到添加或删除，数组的索引以及长度变化，in操作符检查。基于 Proxy 版本的代码无法在 IE11 里运行。这不仅仅给我们带来了技术上的复杂性，同时也给开发者造成了持续的心智负担。
我们原本的计划是在支持 IE11 版本的开发中同时发布 Proxy 和 ES5 的两种响应式版本。当它在支持 Proxy 的开发环境中运行时，会检测并对不兼容 IE11 的一些用法做出警告。这虽然在理论上可行，但是带来了极大的复杂性，因为它需要将两种实现混合在一起，而且增加了开发和生产环境行为不一致的风险。
长期维护的负担
支持 IE11 也意味着我们必须对整个代码库中使用的语言特性做出考量，并为我们的发布版本找到合适的 poliyfill / 编译策略。每一个在 IE11 中无法被 polyfill 的新特性都会带来新的行为警告。一旦 Vue 3 承诺支持 IE11，直到下一个大版本发布之前都无法摆脱它了。
给库开发者带来复杂性
如果 Vue 本身能够完全处理掉这种复杂性，那么在某种程度上也是可以接受的。然而，在与社区成员讨论后，我们意识到，共存的两个响应式系统实现也不可避免地影响到了库作者。
通过在 Vue 3 中支持 IE11，本质上库作者也需要做同样的决定。库作者不得不考虑他们的库运行在哪种 Vue 3 版本上(可能还得支持 Vue 2)。如果他们决定支持 IE11，在编写库时，脑子里也必须时刻考虑 ES5 响应式系统的相关警告。
为 IE11 持续存在做贡献
没人愿意支持 IE11。它是一个停留在过去的行将就木的浏览器。未来 Web 生态向前发展的越远，我们为了支持 IE11 所要填补的缺口就越大。具有讽刺意味的是，如果 Vue 3 支持 IE11，那么就等于我们给它注入了新的生命力。基于我们的用户基础，移除对 IE11 的支持可能会加快其被淘汰的速度。
对于那些实在需要 IE11 支持的用户
我们也很清楚，对 IE11 的真正需求来源于那些无法升级的用户：金融机构、教育部门和那些依赖 IE11 的屏幕阅读器。如果你正在构建一个面向这些领域的应用，你可能别无选择。
如果你需要 IE11 支持，我们推荐使用 Vue 2 版本。与其为 Vue3 和未来的版本承担巨大的技术债，我们认为把工作重心放在让 Vue2 拥有向后兼容特性、确保两个大版本之间的拥有更加近似的开发体验这件事更有意义。
一些可以在 2.7 版本向后兼容的特性：
- 把
@vue/composition-apiplugin合并进 Vue 2。这会让使用 Composition API 开发的库同时支持 Vue2 和 Vue3。 - 单文件组件中的
<script setup>语法。 emits选项。- 提升的 TypeScript 类型支持。
- 正式在 Vite 中支持 Vue 2(目前的支持是通过非官方插件实现的)
注意：以上列表暂定，可能并不全面，我们会在单独的 RFC 中讨论这些内容，并做出最终决定。
