Vue 3.0 彻底跑偏了

[plqws]

关联文章： https://zhuanlan.zhihu.com/p/68477600

Vue 3.0 的想法是引入灵感来自于 React Hook 的 Function-based API，作为主要的组件声明方式。

意思就是所有组件的初始状态、computed、watch、methods 都要在一个叫做 setup 的方法中定义，抛弃（暂时会继续兼容）原有的基于对象的组件声明方式。

Reddit、HN 相关的讨论帖，包括这个 RFC PR 的本身，都有大量强烈的反对的声音，然而目前 Vue 的核心团队似乎并不认为这个改变可能是一个错误，而是在努力说服大家接受这个改变。

（个人认为如果这个改变实装到 Vue 3.0，也许不会带来太大的影响，但是如果在 Vue 4.0 中彻底废弃原有的组件声明方式，Vue 相当于自杀了。）

[lxrmido]

……为了更直观？

[xxx749]

还行吧，用久了就习惯了

[Lygljj]

框架而已，能用就用，不能就换

[AlexaZhou]

感觉越来越复杂了，对重度应用可能有所提升，但是对轻度应用提高了学习成本，而上手快一直是 Vue 的一个很大优点

[love]

啥叫都有大量强烈的反对的声音，少量不思进取的人而已，看不到前端的新趋势。

vue 3 是 vue 的一大进化，很看好后续发展，yyx 的技术审美还是可以的。

[love]

另外这类人一般不看那个 RFC 到底讲了什么，和原 api 的对比，和 react hooks 的对比，为什么叫停了之前进行中的 class 方式

[uxstone]

随便改 反正我不用 vue

[IvanLi127]

上手快这个优点，不重要

[lqf96]

无所谓了，官方说 vue-class-components 会继续维护，大不了接着用呗...反正就是 underlying api 变了而已

[fy]

作为底层逻辑问题不大，上层部分可以编译过去。对 SSR 来说也许是件好事？

[dragonszy]

设计越来越好-->使用者越来越少。
操作系统是这样。
编程语言是这样。
什么都是这样。
古人云，曲高和寡。

[murmur]

坚持 vue2 就可以啊，vue 出 3 不代表 2 活不下去，有了 vue 和 react 不代表 jquery 就得死
我们公司用 vb 开发的 oa 都跑的好好的

[CodingNaux]

框架无所谓的，跟着团队走啦
不过隔壁 react api 少且稳定，进化比较平坦。

[secondwtq]

@dragonszy 我觉得你这个属于一个经典谬误：相关关系不能推出因果关系

“设计越来越好”这个过程是要经过一定的时间的，这个时间里面可能会有更好的替代品出现，用户少了可能是因为竞品而不是因为自身设计的变更

[ericgui]

开始玩 react 了，毕竟流行度最高

[jinliming2]

Python 2 和 3 的区别？

[EPr2hh6LADQWqRVH]

@love 蛤？
Vue 也许有很多优点，尤雨溪也许有许多独到之处，但技术审美。。。

[gouflv]

@love 就目前 vue 的实现，真说不上美，最多给个简单易用的“优点”

[orancho]

Vue 3 的这个 Functional 语法看起来就像是把原有的语法用语法糖粘起来然后再使之晦涩化的产物。

[KuroNekoFan]

vue，this 一把梭，审美在哪里？

[love]

@gouflv vue2 好不好我不好评价，毕竟我也没用过，但 3 那个提案我是很欣赏的，因为最近大量写 react hooks，一看就了解这是抄到了 react hooks 的精华并且反弹了让人很不爽的 react hooks 缺点。yyx 很了解竞争框架的优点不惜全盘放弃之前的 API 也要抄过来，这不是技术审美是啥。

[starcraft]

就是为了更好抄罢了。有什么好跑偏不跑偏的。

[gouflv]

@love “抄”这个字用的的漂亮。原来你说的技术审美是这样。。

[fanling521]

2.x 还能写好几年，急啥

[gouflv]

vue 3 最初的规划是用 oop 解决复用问题，结果一看 hooks 这个发明，立刻觉得 oop 不行了啊，各种问题，搞下去，一不小心还会走上 angular 的老路。那怎么办，硬着头抄呗，还能趁着 hooks 的热度，赶紧吹一波，你看：我们 vue 终于也能复用啦，终于丢掉了狗屎的 mixin 啦，这波抄的多么机智

[TimPeake]

真香警告就完事儿了

[adjusted]

react 因为 facebook 那么多工程师在用，如果改动激进点会被自己人先骂惨了，vue 就完全没这个顾虑。

[xzh654321]

真香警告

[rockyou12]

@gouflv 抄设计都能喷？ node 和 go 的包管理抄都不会抄，不然怎么会这么狗屎。而且现在大部分语言的语法设计也是抄的 c，有问题？

[love]

@gouflv 出现好的技术因为矜持和面子而不用，是蠢。还好 yyx 不是你这种想法，人家比你灵活务实多了。

[loading]

不喜欢可以不用追新，实在不行自己 fork，要么就跟着走。

[0x000007b]

像我这种后端因为没人给我写前端，只能自强不息，我或者说和我差不多的一大群人想要的只是能跑就行，自己做来自己用，等有必要了再找前端重构。改来改去增加了使用难度，都兼容比较好点

[moodasmood]

jQuery，还能战

[zhwithsweet]

酸他妈的，不影响 yyx 闷声发大财。
===========
setup 是个可选配置，vue3 要向后兼容的；
vue-class-components 然后继续维护的；
vue3 更多是底层的实现改变，暴露出来的 api 只会少不会多，你之前写啥以后写啥。

[BarZu]

我很欣赏 Vue3.0 的做法，小部分人反对而已，代表不了大部分。支持的人不发声，反对的人就以为全世界都反对了？

我自己也倒腾过写框架，我甚至把组件设计一个函数，类似这样

import ComponentB from './ComponentB.js'

function ComponentA ({ data, render, dom: _, style }) {
const data1 = data({ ... })

style({
'font-size': '12px'
})

return render([
_('div', [
_('span'),
ComponentB()
])
])
}

只可惜我水平不够，只能自己写个 demo 玩玩

[janxin]

还好吧，也不算跑偏啊。。。

[hoosin]

早上看了 JetBrains 的报告 ，React 的占有率已经超越 Vue 了

[Qcui]

@hoosin React 的占有率一直都比 Vue 高，并且高很多

[ericgui]

一个软件作品，也算是一部作品吧，也是同样遵守“输入输出”原理的。说白了，Evan 这么多年的技术积累，到底有多少呢？一个 vuejs，火起来了，当然有自己的特色，但一个小小的个人团队，真的就是抵得上 React 和 Angular 两个牛人云集的巨型团队的集思广益吗？

所以 vue3 原创不足，其实本质上还是 Evan 自己的技术积累已经到了极限，我不认为他能够继续引领 Vue3 和另外 2 个框架并驾齐驱，这才是我在考虑放弃 Vue 的核心原因。

[liximomo]

React Hooks 和 Vue 新的 RFC 解决的是同一问题，让组件逻辑可以再组件外书写复用。Vue 社区发对声大多是一些没有接触到这些复杂应用场景的初中级开发。他们中大多数也是没有完整阅读过 RFC 的，通过二手信息源错误的认为旧的 api 会被替代，实际上新的 RFC 并不会废弃任何东西，你可以不用，但 vue 必须要有，因为别人可能会用到。

[oukichi]

@hoosin medium 有篇文章分析报告称，react 占 70%，angular 占 27%，vue 占 3%。也许这是老美的统计，但是可见一斑啊。

[sodatea]

> 在 Vue 4.0 中彻底废弃原有的组件声明方式

不会的，如果到时候用旧的声明方式的人足够多，肯定不会从核心移除。
即使用的人不多了，也不会抛弃，最多是从核心仓库移到单独的包里。（就像 React 对 createClass 和 PropTypes 做的那样）

[notreami]

@jinliming2 啥，一个 js 库，跟一门编程语言类比？？

[SEARCHINGFREE]

开发者可以不跟风的，又不是必需品

[neoblackcap]

Facebook 里面一群搞 FP 的，他们不喜欢 OOP 我可以理解。Vue 是本身就是面向普罗大众的，现在这样改，让我有种 FP 这样的思想已经成了业界主流了。是我落伍了？

[duan602728596]

对于 react hooks，是真香。所以对于 vue3 还是很期待的

[love]

@neoblackcap 先看看 RFC 是啥，Vue 的 hooks 根本不是象 react 那样的函数式，本质只是借了 react hooks 的精华而已，函数只 setup 一次，并不会重复运行，反而避免了 react hooks 的缺点，在我看来是更先进了。

[love]

@ericgui 你这想法对于需要大人力大投入的复杂工程来说是成立的，但对于实现难度小基本是思想占大头的项目来说人多不意味先进，它只取决于最聪明那人，小团队反而更有优势

[gzf6]

搞 ng 的估计得跑国外找工作了，国内一水的 react 和 vue

[justin2018]

我老了 前端真的跟不动了~

[mogutouer]

感觉还可以，原生特性很好，想我们这种做小程序，用二道贩子（ mpvue，megalo ）的才难跟

[momocraft]

抛弃基本盘（我猜测有不小的比例是学个框架就好风凭借力的）对框架不一定好

[Ixizi]

真香预警

[599316527]

那还不如像 svelte 那样搞得彻底点，还要包层 setup() 不伦不类的

[impl]

可以用 svelte，svelte 没有 hook。

[laogui]

站在用户角度不敢轻易对框架的核心变化指手画脚，使用者和核心开发者所思考的不是一个东西。作为用户，要么积极跟随变化，要么就换别的。

[shenqi]

react 真香啊。三大框架里面，就 react 框架入门成本及发展延续成本最低，所以，真香。

[voidcomma]

每次都有人拿 vue 是个人作品来黑，说 react 是巨型团队的那个，去了解一下 react 的核心团队有几个人再来黑吧。。利益相关：工作大量使用 vue，个人喜欢用 react。

[plqws]

我自己本身在大量的项目上使用 Vue，所以更能理解 Vue 之所以吸引人的地方。

- 我要实现某个逻辑，通常只有一种方法，马上就能开工。但是 Vue 3.0 还是之后的版本，则会让人纠结到底要用传统的 API 还是新 API，这个选择的过程就很使人难受，也是一个框架最不应该出现的问题。

- 代码组织轻松，即便是千人万人的团队，写出来的代码基本都差不多。因为基于对象（或者 Options ）的组件声明，把组件不同逻辑的编写方法和位置都约束起来了，而基于函数的声明方法给了开发者更大的自由，也产生了更大的不确定性。同时也降低了可读性（开发者需要在 setup() 里到处寻找 value 在哪里，methods 在哪里，分辨哪些是 computed，某个叫做 isEnabled 的字段到底是 value 还是 computed ）。

- 基于上面这些优点，随之带来的就是极低的上手门槛，不需要多熟悉 js 的语法糖或者未来特性，就能用 Vue 进行生产。然而在失去上面这些优势后，很难说 Vue 再会是一个亲民友好的框架了，而更像是一个被 React 社区不断影响干扰，而迷失了自我的失败品。

学习曲线陡峭度的提高、代码的可读性的降低、可能会出现的旧 API 被废弃导致的迁移成本，这些都是很可怕的问题。

而且基于函数的 API 的引入，这个改变太过巨大，在某种意义上可以认为这是一个新的框架了。所以为何 Vue 团队不考虑学习一下 Express 与 Koa，从 Vue 中分离出一个新的框架，从而服务那些真正需要这些新特性的高阶用户。毕竟某种意义上，引入这个新的 API，基本上所有现存的插件都要重写，这一点和 Koa 对于 Express 的改变来说，还是很相似的。

[wszgrcy]

@gzf6 啊啊啊啊啊，虽然你说了试试，但确实挺令人伤心的

[ragnaroks]

我突然想起"求求你们别更新了,老子真是学不动了"这个贴子了

[gzf6]

@wszgrcy 哈哈，ng 这么稳定、完成度高的框架，省了多少团队协作的成本，居然企业应用很少选择，搞不懂搞不懂

[sugars]

你这个“彻底”二字，我就想说你点什么

[sodatea]

@plqws

> 则会让人纠结到底要用传统的 API 还是新 API
一般肯定是建议新代码新用法，老代码老用法。跟 React 生态的演进也没什么区别

> 开发者需要在 setup() 里到处寻找 value 在哪里，methods 在哪里，分辨哪些是 computed，某个叫做 isEnabled 的字段到底是 value 还是 computed
我不是太理解为什么需要区分 value 和 computed。
不过 value / computed 和 methods 的区分我觉得是可能会做出改进的（当前的 RFC 仍然是设计中的版本，不是最终版本，有新的好想法或好意见肯定会继续调整的）

> 可能会出现的旧 API 被废弃导致的迁移成本
RFC 里刚开始用了 deprecation 这个词，应该算是 Vue 团队信息传达时的一个失误，让普通用户被吓到了。
事实上，这个成本无限接近于零。
1. 因为 setup 写法是一个比较底层 /基础的实现，基于这上面提供旧 API 的兼容版本，不过是需要用户改一个 webpack alias，或者引入一个新的库而已（参考 create-react-class https://reactjs.org/docs/react-without-es6.html ），而维护这个兼容库的成本非常低
2. 另外因为 function API 的灵活性，其实这个代码可以低成本自动化转换（并且不丧失可读性）。Akryum 昨天差不多一天时间就写出了这样一个在线工具： https://suspicious-mclean-0e54c3.netlify.com/

> 不需要多熟悉 js 的语法糖或者未来特性，就能用 Vue 进行生产
函数也是非常基础的 JS 语法，而且去掉了魔改 this，应该说门槛更低了……

> 某种意义上，引入这个新的 API，基本上所有现存的插件都要重写
不，跟 React Hooks 相似，这只是提供了新的**底层**能力，现存插件完全可以不重写，只是说，新的底层能力让插件作者有可能设计出新的 API 用法。

[mazai]

@ragnaroks 我真的学不动了，作为一个后端开发来说，也要保持前端知识点的跟进真是学不动了

[AV1]

jQuery2 丢弃对旧版 IE 的支持，怎没见过那些 jQuery 程序员高呼跑偏呢？😒

[SEARCHINGFREE]

#66 所以大伙还在用 jq1 呢

[plqws]

@sodatea #64 感谢回复。

不知道我这么理解对不对，function-based api 是一个底层的组件定义方式，并且可以支撑起 object-based component 甚至 class-based component 的实现。而 Vue 是打算将 object-based component 等支持拆分出去，作为可选内容？

从昨天下午开始我就一直翻阅那个 PR 的回复，目前看来，Vue 团队挺有必要写一篇文章，或者在 RFC 中专门说明这个内容，来缓解社区对这个提案的误解的加深，不过我看 Evan You 似乎也已经开始着手这件事了。

[SilentDepth]

如果让组件 export default 一个函数（而不是一个 plain object ），由这个函数承载 setup() 的功能，并返回一个类似 Component Options 的东西让它看起来像 Vue 2.x 的写法，大家还会有这么大的抵触吗？

[owenliang]

有 react 为啥用 Vue，悲哀。

[robinlovemaggie]

Evan 说：你们先吵一会儿，我去给媳妇庆个生。

[df0618]

我不明白 React、Vue 这些为什么这么怕装饰器……没有装饰器的代码实在是太恶心了
UseUseUseUseUse
.value.value.value.value.value.value
还有各种一大坨的 Lamda 参数
看着就想吐

[martinoooo]

@df0618 有装饰器又说抄 angular 了

[df0618]

@martinoooo 所以之后打算去玩玩 angular 或者 Blazor 了，本来用 ts + vue class component +一个 vuex 装饰器组件 虽然有缺陷但感觉还挺好的，现在这种去 class 化应该是不会符合我的审美了

[sodatea]

@plqws
是的。
解释工作应该在进行中了……

[sodatea]

@df0618
1. API 设计上的权衡可以看这里： https://github.com/vuejs/rfcs/pull/17#issuecomment-494242121
2. JS 目前语言设计的问题，可以看下贺老的吐槽

JS 的 decorator 标准难产这么久不是没有原因的……依赖于这样的标准肯定是有风险的，作为用户层的 addon 更安全

[whypool]

学不动了，不要更新了

[plqws]

@sodatea #64
> 2. 另外因为 function API 的灵活性，其实这个代码可以低成本自动化转换（并且不丧失可读性）。Akryum 昨天差不多一天时间就写出了这样一个在线工具： https://suspicious-mclean-0e54c3.netlify.com/

其实我意识到了一个挺有意思的问题，从 options 转成 setup 的确挺简单的，因为 options 的结构和层次分明。但是如果要从 setup 转成 options 的话……好像没有什么头绪，因为写法太灵活了，做不了静态分析，不知道这意味着什么。

[GreatAuk]

@hoosin react 难道不是一起领先于 vue 的吗

[FrankHB]

@rockyou12 问题大了去了。
1.C 的语法不够狗屎么。
一般人遇到能更狗屎的语法就是所谓的数学语言，但是数学好歹能在某个具体下游领域理直气壮地告诉你诸如“看这就是爱因斯坦求和约定老实看清楚别搞混不服闭嘴”；相比之下，C 的实现还是要缩卵到惦记某些用户记不住优先级规则而警告少括号，却又不敢在 spec 里不支持……高下立判。
2.看看，屎成这样都让你有底气“大部分”了。谁的锅？
现在还能抄这样子屎货设计的，大致情况是设计者脑子里没货和 /或被屎淹没不知所措弃疗了。

[love]

@plqws 什么叫转 setup 做不了静态分析，转 setup 才是最适合静态分析，也是 hooks 的最大卖点，而且比 class 方式更好地配合 typescript 静态检查，原来的 mixin 之类的才不能静态分析，不好搞清楚变量哪里来的

[rockyou12]

@FrankHB 好吧，你觉得 c 语法狗屎就狗屎吧，也许你是喜欢 haskell 和 lisp 的大大，和我们这些搬砖的不一样

[yuekcc]

工作上还真在用 jq1。项目历史原因不解释。vue3.0 的 api 还是挻好看的，入门上估计 vue3 不会增加太多成本，毕竟是内部重构，对外还是可以以 vue2 风格去写。

当然，其实我是比较喜欢 svelte，没有同好么？

[FrankHB]

@rockyou12 Haskell 显然更狗屎（什么苟屁 layout ……），只是默认已经把能接受这种语法完全没有异议的用户排除出一般人之外了。
Lisp 也有很多(屎)，不过某种意义上不管是不是搬砖都有方法更容易（相比 C ）把里面的屎变通掉。

[Sparetire]

现在大版本都不允许有不兼容了么，何况都保证兼容性了还要操心影子都没有的下下个版本会不兼容。。
兼容了又要觉得你这新 API 出来我不会用，不是显得我很过时？
真的难伺候。。
每个说不支持装饰器的，很久以前尤就说了装饰器标准一直不稳定，也给出了合理的理由
还有人说性能不是卖点，性能还真是卖点好吧，至少是卖点之一，体积比 React 小很多，性能略好，新出的 hooks 也做到了开销更小

[loading]

我才开始学 vuejs 2.x，我跟不上啊……

[Almost20]

还好吧。只是多加了特性，又没有说不支持旧的写法。

[Elephant696]

@oukichi 关于这个统计，我不认同。我去年也看过一份统计报告。在全球范围来看，react 的使用率确实是远高于 vue 的，特别是在欧美地区。但是在中国还有俄罗斯地区，vue 的使用率要比 react 高很多。如果把使用程度分成 轻度、中度、重度、特别重度四级，那么 react 在欧美为重度，在中国为中度。vue 在全球范围为中度，在中国为特别重度。
上面还有印度和非洲地区的统计，我记不太清楚了，不过基本是 react>vue 的情况。

还有 angular，除了在欧美地区为中度使用外，其他地区基本是轻度，在中国占有率非常低。

[Allenqjy]

@AlexaZhou 大佬，anyflow 是彻底停更了吗？

[leafin]

有 jQuery 就够了

[coloz]

vue 越来越复杂。。。还是学 ng 吧，至少 ng 的难度始终如一

[tower1229]

只不过你不是 3.0 改造的目标受众，只要你喜欢完全可以一直用 2.x

[IWSR]

同时维护 2.x 项目与新开发 3.x 项目将会是件很痛苦的事情，不过 Function-based API 会给 vue 带来更多的可能，相比之前的模板来说，写法会更加自由。

[IWSR]

@IWSR Ummm 当然我还是推荐新项目使用 react 吧，老年人吃不消了

[cheerxl]

@IWSR template 并不会取消

[jinsongzhao]

个人决定的作品，比集体决定的作品，容易跑偏。

[Sapp]

就没人发现，如果 vue 没有 3.0，其实已经跟有 hooks 加成的 react 完全不是一个级别的对手了么？ 包括在 vue 好上手这一点，有 hooks 加成的 react 已经比 vue 强了（当然 react 的其他东西 react-router、redux 依旧比 vue 那一套复杂），利用 hooks，很多新手可以实现以前很多基本做不到的事情，react 拥有 hooks 之后，vue 已经完全对我没有任何吸引力了，以前我还会在一些小项目考虑他，现在直接 react 就完事了。

[xinn1x]

不觉得，一个功能分散在不同的声明周期里，很难受么。一个组件的声明周期里一堆功能相关的函数罗列在那，过几天再看就很难受。

[bojue]

@gouflv angular 好无辜

[nexo]

@love 大佬求教下 vue2.x 不用 class 的写法 能接入 ts 吗