【转】Vue2升级到Vue3到底是不是一个正确的选择?

就在前两天,一篇反对Vue2升级到Vue3的文章在vue官方社区引起了热议。(原文链接:Vue 3 was a mistake that we should not repeat

这篇文章从实际应用角度出发,分析了Vue2Vue3在真实项目中实操升级的痛点,提出了一个反对的声音:Vue3的升级是一个错误的选择

在一片热议中,甚至尤大都出来亲自解释并承认了一些问题。本文列举了一些原文中提到的观点以及尤大的回复。希望能给各位读者在实际项目升级时,提供更实际全面的参考。

前言

原作者首先声明了他并没有贬低Vue3的意思。他认为Vue3是非常非常棒的框架,解决了Vue2中很多潜在问题,技术层面改善了开发人员的开发体验,并显著提高了性能。原作者主要的问题,是从Vue3突破性的改变以及周边生态圈未能及时跟上的角度,重点强调了迁移升级成本+风险较大。

关于升级成本问题:尤大也承认了Vue3升级体验并没有想象中的那么流畅,Vue4会吸取经验,做好平稳迭代。这一点本文会在下面详细说明。

接下来,我们针对原文中提到的观点逐一列举解读。

ps: 为了避免语言翻译差异问题,所有原作者尤大的观点都是附上英语原文。

一、破坏性的api变更(Breaking changes)

  • Events API的弃用让这个问题首当其冲。(straightforward like the depreciation of the Events API)。Vue实例再也不能作为事件总线做事件通信,$on,$off,$once的彻底移除意味着之前所有有关代码都必须重新推翻重写,虽然有很好的插件工具让这件事变得没那么复杂,但是仍然会带来不小的迁移成本。
  • 代码构建问题。 你会经常遇到用Vue2写法写出来的代码在构建(build) 失败或抛出警告。因为这些api写法在Vue3中已经被废弃。这问题在已存在的大型项目中的尤为突出(In an existing large-scale application built with Vue 2, you would probably use some of the deprecated or changed APIs)。下图展示了一部分Breaking changes,可以看到破坏性的api变更数确实很多:

二、颠覆式的设计模式(composition-api)

颠覆式的composition-api慢慢向面向函数思想转变,导致很多原有习惯于options-api的开发者反感Vue正在像react靠拢,没有坚持住Vue特色。它提出了一种新的基于函数的 Vue 组件编写方式,引起了Vue社区大量的争议和分裂,甚至将社区分隔为两种观点阵营针锋相对,最终导致了Vue 最黑暗的一天事件。这很令人沮丧。

(the Request for Comment for the new function-based way of writing Vue components which had an overwhelming amount of responses, both positive and negative.No matter where you stand in this argument splitting the community in half is never a good sign and led to Vue’s Darkest Day and a lot of people getting discouraged over this.)

三、生态系统(The ecosystem)

框架的真正力量来自社区和它周围的生态系统。(The true power of a framework comes from the community and the ecosystem around it.)

生态系统和框架本身一样重要。因为没有责任机制,在有争议的决定和在弃用功能的时候,很多框架周边的生态系统的许多贡献者会被迫离开,并导致许多库被放弃或者延迟更新。很多时候,我们没有办法做版本兼容时,我们往往只能把责任归咎于,开源库缺乏同理心和对大局的理解。 (Controversial decisions and no accountability while deprecating features drove many contributors away and resulted in many libraries being abandoned. But blaming open source libraries for delays when you don't give them a feasible way to support both versions shows a lack of empathy and lack of understanding of the bigger picture)

四、文档系统(Documentation)

在我们的日常开发中,尤其是在使用框架时,我们会遇到各种各样的问题,这时我们时常需要google或者问答社区作为帮手,但是目前关于Vue搜索出来的结果几乎全是Vue2的结果,这也很难不令人难过。

(During development, especially with a new framework, Google and StackOverflow are your best friends. Currently, Vue 2 answers are dominating the results which might cause confusion and frustration since many things don’t work the same in Vue 3.)

五、过往案例(The past)

Vue2到Vue3的升级,有一点像angular1到angular2的升级

过渡到 Vue 3 看起来很像从AngularJS过渡到Angular版本 1⇒ 2)。大量的延迟和重大更改导致了挫败感,最终 Angular 失去了对 React 和 Vue 的吸引力。

(The transition to Vue 3 looks a lot like the transition from AngularJS to Angular (Version 1⇒ 2). A lot of delays and breaking changes led to frustration and eventually Angular lost traction to React and Vue.)

五、结论(Apinion)

  1. 看起来前进的道路其实是倒退。(It looks like the way forward is going backwards)
  2. 开发满意度看起来并不好。(development satisfaction is not looking good)

上图可以看到Vue已经有被svelte超越的趋势。

  1. Vue4应该考虑到整个生态系统并提供迁移路径,否则它将成为没有人愿意使用的最佳框架。(Vue 4 should take into account the whole ecosystem and provide a migration path or it will be the best framework that no one will want to use.)

六、尤大的回复:

1.关于破坏性的api:

这根本不是真的。

当我们进行版本切换时,所有核心库和工具都与这两个版本兼容(或为 Vue 2/3 支持提供单独的版本)。

实际上阻碍升级的依赖都是第三方,主要是 NuxtVuetify

2.颠覆式的设计模式:

实际使用过 Composition API + < script setup> 的用户在真是开发中的反馈非常积极,证明这是一个有价值的补充,现在他们中的许多人更喜欢它而不是 Options API。

我们当然可以更好地处理新 API 的引入,但仅仅因为存在争议,并不意味着它是错误的或者不必要的。实际上,引入大的、新的想法的行为,势必会让那些喜欢呆在舒适区的人感到不安,但如果我们迎合这种心态,就永远不会取得真正的进展。

3.关于周边生态和文档系统:

虽然我们确实创造了 Vue CLI、Vuex、Vetur 和 VuePress 的新替代品,但它们本身都有适用于 Vue 3 的版本。这是夸大事实,不尊重团队为提供这些工具的 Vue 3 兼容版本所做的努力。

4.关于和angular的过往对比:

  • 没有可比性,不能拿Vue升级和angularjs -> angular做对比。
  • Angular 和 AngularJS 是根本不同的框架。几乎没有共享交集,除了完全重写之外没有实际的迁移路径。
  • 另一方面,有许多生产 Vue 2 应用程序成功迁移到 Vue 3 的案例。很容易吗,确实不是,但是他们都迁移成功了。

5.关于升级问题:

我们同意,Vue3升级体验并没有想象中的那么流畅。Vue 将随着吸取的经验不断发展,我们绝对不打算在未来的Vue4中,进行这样的破坏性重大升级。

(We appreciate constructive feedback and agree that the Vue 3 upgrade experience isn't as smooth as it could be. Vue will keep evolving with the lessons learned, and we definitely do not plan to have disruptive major upgrades like this in the future.)

6.关于这篇文章结论:

在我看来,这篇文章整体上描绘的画面比实际要黑暗(dark)得多,有不必要的夸张,在少数情况下是完全不正确的信息。我希望至少能纠正我在其他评论中指出的一些事实错误。

七、总结讨论:

上述就是原作者提出来的问题以及尤大的回复,应该可以给各位正在考虑升级的小伙伴一点真实的参考意见。

作者:掘金干货君
链接:https://juejin.cn/post/7117525259212816414
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,033评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,725评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,473评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,846评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,848评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,691评论 1 282
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,053评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,700评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,856评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,676评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,787评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,430评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,034评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,990评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,218评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,174评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,526评论 2 343