前言游禹锡曾表示，Vue3会发布兼容IE11的版本，现在Vue3.0已经发布很久了，不过，兼容版本已经很久没有出现了。原来，微软正在积极推广自家的新Edge浏览器，并打算放弃IE。这让尤雨熙思考是否有必要兼容IE。胡：从Vue3开发开始到2018年年底，我们一直被问到IE11支持的问题。很多用户问Vue3会不会支持IE11，我们原计划是先出一个稳定版的Vue3，以后再支持IE11。在漫长的开发过程中，我们也对IE11的兼容性进行了研究和试验，但由于涉及的复杂性和手头的其他重大工作，IE11暂时搁置了。当我们在2021年再看当前的问题时，浏览器和JavaScript的状态已经发生了很大的变化。现在，越来越多的开发者开始使用现代语言的特性，更重要的是，微软自身也开始通过对Edge的推广，积极推动用户远离IE。它甚至在自己的Microsoft365等重大项目中放弃了对IE11的支持。就在几天前，WordPress也决定放弃对IE11的支持。IE11的全球使用率已降至1%以下。当我们谈论面向公众的网站和应用程序时，IE11有明显而迅速的下降。我们相信这是一个重新思考Vue3对IE11支持的机会。在Vue3中支持IE11的成本行为是不一致的Vue2的反应性系统是基于ES5getters/setters的。Vue3使用ES6的Proxy来获得更高的性能和更完善的响应式系统，但是Proxy不能在IE11中进行polyfill。这是最大的障碍，因为这意味着如果Vue3要支持IE11，它实际上需要发布两个具有不同行为的不同版本：一个是基于Proxy的反应系统，而另一个使用基于ES5的Agetter/设置器系统。Vue3基于Proxy的反应式系统提供了几乎完整的语言特性覆盖。它可以检测出许多在ES5中不可能或不可行的操作，例如属性添加、删除、数组索引和长度变异，以及在操作符检查中。为Vue3的代理版本编写的相同代码在IE11版本中根本不起作用。这不仅给我们带来了技术上的复杂性，也给开发者带来了持续的精神负担。我们最初的计划是在IE11的开发版本中同时发布Proxy和ES5响应式实现。在支持Proxy的开发环境中运行时，它会检测并警告不兼容的IE11使用情况。从理论上讲，这是可行的，但由于需要混合两种实现方式以及开发和生产之间存在行为差异的风险，因此会产生很大的复杂性。支持IE11的长期维护负担也意味着我们必须考虑整个代码库中使用的语言特性，并为我们的子包找出正确的polyfill策略。IE11中添加的每个无法填充的新功能都会导致另一个行为警告。一旦Vue3承诺支持IE11，我们将无法在下一个主要版本（Vue4）之前摆脱它。如果复杂性可以完全包含在Vue本身中，库作者的复杂性在某种程度上仍然是可以接受的。但在与社区成员讨论后，我们意识到两种反应式实现的共存也不可避免地暴露给库作者。通过在Vue3中支持IE11，库作者将不得不考虑他们的库运行的Vue3内部版本（并且可能支持Vue2），如果他们决定支持IE11，他们将不得不考虑ES5的响应原则来编写他们的库。为IE11贡献持久力没有人喜欢支持IE11。这是一个已经被淘汰的浏览器。Web生态系统向前发展得越远，我们在尝试支持它时需要克服的差距就越大。而讽刺的是，如果Vue3支持IE11，就相当于我们给了它更多站出来的理由。考虑到我们的用户群，放弃对IE11的支持可能会使它更快过时。我们知道绝对需要IE11支持的用户，以及真正需要IE11的用户：金融机构、教育机构和依赖IE11屏幕阅读器的人。如果您想构建针对这些领域的应用程序，您可能别无选择。如果你真的需要兼容IE11，我们的建议是使用Vue2。因为与其承担Vue3和Vue未来版本的大量技术负担，还不如专注于向后移植兼容功能到2.7版本的Vue2。确保两个主要版本之间的最新开发体验更有意义。可以向后移植到2.7的一些功能：将@vue/composition-api插件合并到Vue2中。这将使基于CompositionAPI的库直接适用于Vue2和Vue3
