尤雨溪:Vue 3 将不会支持 IE11 了
清明时节雨纷纷,尤大发文欲断魂。没错,想小长假这几天,大家又被爱在假期搞事情的尤大的新闻霸屏了,就在 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-api
plugin 合并进 Vue 2。这会让使用 Composition API 开发的库同时支持 Vue2 和 Vue3。单文件组件中的
<script setup>
语法。emits
选项。提升的 TypeScript 类型支持。
正式在 Vite 中支持 Vue 2(目前的支持是通过非官方插件实现的)
注意:以上列表暂定,可能并不全面,我们会在单独的 RFC 中讨论这些内容,并做出最终决定。
版权声明: 本文为 InfoQ 作者【清秋】的原创文章。
原文链接:【http://xie.infoq.cn/article/752e68b08ade1511483305e31】。文章转载请联系作者。
评论