Vue 3是一个错误，我们不应该再犯
文本是翻译的，作者Fotis Adamakis， 他是 vue.js雅典会议的共同组织者，文中的第一人称指的是该大佬。
从最初引入Vue 3开始，已经过去了4年多。经过多次RFC的讨论，以及其他现代框架（包括react和Svelte）的影响，Vue 可能已经成为最强大和最全面的框架，能够逐步支持任何规模和架构的应用。
听起来很刺激，对吗？嗯，事实远非如此。从那时起，就发生了很多延迟和降级的情况。尽管Vue 3最近成为了新的默认版本，但很多重要的支持库还没有准备好，甚至没有计划与两个版本兼容。这说明很多代码库还停留在Vue 2上，迁移到版本3的路径并不容易。
请不要误解我，Vue 3非常棒。它可能是目前最好的框架了。但事实上，从第二版开始没有简单的迁移路径，这是一个错误，我们不应该在未来重复。
Vue 2的问题
Vue一直被认为是一个进步的框架。选项api很容易理解，我们可以学习并在需要时引入更复杂的模式和库。小的学习曲线和良好的文档是大家喜欢它的原因。
另一方面，在将通用逻辑抽象为mixin时，使用继承而不是组合的体系结构缺陷造成了许多可伸缩性问题，并破坏了干净组件声明的许多原则。Vue3 引入组合API 作为一种解决方案。
另一个重要的问题是对typecript的支持。当然，在Vue组件中编写typescript就像在script标签中添加type="ts"一样容易。但在模板和 store 里，支持是有问题的。
vue3 解决方案
完全重写是一个改善框架内部结构的机会。Vue3 广泛地使用了Typescript，包括响应性机制在内的许多方面都从头开始。这使得Vue 3在数据包大小、初始渲染、更新和内存使用方面的性能得到了明显的改善。
此外，还增加了很多新的功能。
- Composition API
- 语法糖<script setup>
- Fragments
- Emits Component Option
- 来自@vue/runtime-core的createRenderer API可以创建自定义渲染器
- style 里面可以绑定变量
- SFC的<style scoped>现在可以包括全局规则或只针对插槽内容的规则
- Suspense
新功能改善了整体的开发体验，欢迎很多开发都的追捧。争论的焦点是，其中大部分功能，包括组合API、teleport、 suspense 等，在Vue 2中已经都能用了，所以它们不能真正算作框架的改进。
真正的问题
破坏的性变化，有很多。其中一些很简单，比如Events API。Vue实例不能再用作事件总线，但有即插即用的解决方案，如 mitt 或 tiny-emitter，可以用作直接替代。这需要有一定工作时间，但可以及时完成，没有太多风险。
另一方面，有些变化不能安全地进行，也不能不进行小规模或大规模的重构。在一个用Vue 2构建的现有大型应用中，你可能会使用一些被废弃或改变的API。
迁移构建应该是两个版本之间的桥梁，但由于有这么多被废弃的功能，它对大型项目并不适用。此外，官方对一些基本的支持库的建议是迁移到另一个不同的库，这进一步增加了复杂性。由于有这么多的移动组件，即使迁移构建成功，也需要大量的工作，这对大项目来需要有更多的时间用来解决技术债务。
不需要的东西
Vue始终是一个有意义的框架。你可以试着猜测一个API应该如何工作，你很可能是对的。Vue 3不再是这种情况。
一个例子是关于新的基于函数的Vue组件编写方式的意见征集，有大量的回应，包括正面和负面的。不管你在这场争论中的立场如何，将社区分成两半绝不是一个好兆头。
文档
在开发过程中，特别是在一个新的框架中，谷歌和StackOverflow是你最好的朋友。目前，Vue 2的答案占据了压倒性的优势，但在Vue 3中，很多API实现的原理都不一样了，因此可能会造成一定的混乱。
生态
一个框架有多强大，它的生态系统就有多强大。有争议的决定和不负责任的废弃功能驱使许多贡献者离开，导致许多库被放弃。但是，当你没有给开源库一个可行的方法来支持两个版本的时候，就指责他们没跟上你的版本时，这表明你缺乏同情心和对大局的理解。
一个框架的真正力量来自于它周围的社区和生态系统。
过去
如果你有幸在2015年前后写代码，你有可能会使用当时最主流的框架angularJS。
转到 Vue 3的看起来很像从 AngularJS 到 Angular（版本1⇒2）的过渡。大量的破坏性的变化导致了挫败感，最终Angular失去了对React和Vue的吸引力。
如果你是一个全栈工程师，你可能熟悉大约10年前在Python生态系统中发生的同样情况。在大约十年的时间里，许多项目无法升级，因为许多核心库没有增加对Python 3的支持，而出现的新库只支持Python 3。当然，后来的Python版本开始只在版本3上添加新的和闪亮的功能，这种混乱的情况还没有真正结束。
未来--这种情况会再次发生吗？
看起来前进的方向是向后退，把所有的东西都移植到迁移构建中，但是损害已经造成了，开发满意度看起来并不乐观，不能忽视。有远见地让框架参与进来是合理的，但开发经验是框架的核心职责之一。Vue 4应该考虑到整个生态系统，并提供一个迁移路径，否则它将成为没有人愿意使用的最佳框架。
到目前为止，你对Vue 3的迁移有什么经验？请在评论中分享你的想法和建议。
作者：Chris ，译者：小智
原文：https://fadamais.medium.com/vue-3-was-a-mitake-that-we-should-not-repeat-81cc65484954
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！