[译]尤雨溪:Vue3将不会支持IE11 精力会投入到Vue2.7

前言

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

[译]尤雨溪:Vue3将不会支持IE11 精力会投入到Vue2.7_第1张图片

译文

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

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

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

在Vue 3中支持IE11的成本

行为不一致

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

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

我们最初的计划是在 IE11 的开发版本中同时交付 ProxyES5 的响应式实现。当它在支持 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。因为与其为 Vue3Vue 的未来版本承担大量技术负担,还不如将工作重心转向将兼容功能向后移植到 2.7 版本中的 Vue2 呢。并且确保在两个主要版本中获得更近的开发体验将更加的有意义。

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

  • @vue/composition-api 插件合并到 Vue2 中。这将使基于 Composition API的库直接适用于 Vue2Vue3

你可能感兴趣的:(vue.js,es6)