vue3搞出大新闻来了

水木社区手机版

主题:vue3搞出大新闻来了
楼主|eGust|2019-06-23 06:35:30|展开
yyx 给 vue3 搞了个 function api 提案：
https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md

简单来说就是把 react hooks 那套东西抄来了，看起来跟用了 hooks api 的 react 控件没多大区别了。上个星期有人把该提案转到 hackers new 和 reddit 上面去了，于是社区就爆了。大概就是，你这么搞就是走 angular.js 的老路，走 python 的老路，既然长得这么像 react 为毛不直接用 react

按照时间线的话，故事大概是这样
- 因为搞不定原来许诺 vue3 的 class api，老方案被否掉了：https://github.com/vuejs/rfcs/pull/17#issuecomment-494242121
- 到底是因为实在觉得 hooks 好玩好用，还是有野心让 react 用户轻松转 vue，具体原因就不得而知了，总之上个月底搞了这么个提案
- 两天前，有人把提案转到了 [hackers news](https://news.ycombinator.com/item?id=20237568) 和 [reddit](https://www.reddit.com/r/vuejs/comments/c319el/vue_3_will_change_vue_in_a_big_way_current_syntax/)
- 于是很多人开始到 github 反对，粗看了一下，目前400条评论里有一半是从两天前开始的：https://github.com/vuejs/rfcs/pull/42
--
FROM 125.238.192.*
3楼|eGust|2019-06-24 05:49:12|展开
py3 导致社区分裂了已经十多年了，到现在 py2 依然还不可小觑

【在 adamhj (淘气阿丹) 的大作中提到: 】
: python的老路是指啥...
--
FROM 101.98.83.*
4楼|eGust|2019-06-24 05:53:43|展开
这个 rfc 跟前两天已经长得很不一样了，估计没人愿意翻历史，所以再补充点儿信息：
开始的时候，明确说 vue 2.x 的语法将在 v3 中 deprecated，预计在 v4 中移除，一听要移除大家就慌了。当然也包括我，毕竟在我的努力下新项目用了 vue，刚俩月就听说隔个两三年就得重写，这个让人不太好交代……还好周末过去，基本打消了这个顾虑。

yyx 在 pr、推特中似乎还有过一些不太客气的说法，所以论坛上连 petulant、childish 这种词都出来了，不止一人对 vue 核心团队成员在讨论中高高在上的态度表达了不满……

昨天终于怂了，目前 rfc 里不再 deprecated v2 api 了，但还留了个口子：
We have no fixed plan to remove of 2.x options. API removal will only happen if the APIs in question are no longer actively used by the community.

然后打算同时提供两个版本：
Standard build: compatible with 2.x API (except for breaking changes introduced in other RFCs), with the ability to optionally use the new APIs introduced in this RFC.

Lean build: only supports the new APIs and a subset of 2.x options. If you are starting a fresh project using only the new API, this would give you a smaller and faster runtime.

这不就是 py3 么……

【在 eGust (十年) 的大作中提到: 】
: yyx 给 vue3 搞了个 function api 提案：
: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md
: 简单来说就是把 react hooks 那套东西抄来了，看起来跟用了 hooks api 的 react 控件没多大区别了。上个星期有人把该提案转到 hackers new 和 reddit 上面去了，于是社区就爆了。大概就是，你这么搞就是走 angular.js 的老路，走 python 的老路，既然长得这么像 react
: ...................
--
修改:eGust FROM 101.98.83.*
FROM 101.98.83.*
8楼|eGust|2019-06-25 17:23:08|展开
刚才回的长文被审核了……

问题关键不在新 api，而是要废老 api。这么一搞就让人信心不足，你今天觉得 hooks 好可以废掉 v2，那明天出个别的完全有可能在 v4 里废掉 v3。一个项目隔个两三年就要重写一遍，这是谁都接受不了的。

如果当初只说我们有套新的 api 长得很像 hooks，那大家可能会跟 react 社区一样开心。

所以这次是市场营销的失败，跟技术完全没关系，但是伤害已经造成了……

【在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 这个rfc我从开头一直在跟。我是新api的坚定支持者。新api本质上和react hooks没关系，就是看起来有点像，本质上就是以前 data computed watch methods 等东西换了个写法，把原来内部的功能函数暴露出来了，提供一个函数式的写法，不再suffer from this magic等等从前没
: 然后，rfc下面某些反对者说的“高高在上优越感”的发言，其实基本都不是core team member。member们都在装孙子，是几个外围的rfc常客在不客气地各种怼，其中包括我。。
--
FROM 125.238.192.*
14楼|eGust|2019-06-26 14:09:49|展开
vue 的卖点在哪是另外一个话题了，但这场风波的核心跟新 api 一点儿关系都没有

不过我同意，如果跟 react 搞成一个样子的话，vue 就没什么优势了。毕竟 react 除去 lifecycle 只有 state、props 两个核心概念，跑到 vue 就变成了 data、computed、methods、watch 再加上 event 一共五个半概念了

【在 syssky (syssky) 的大作中提到: 】
: vue要是这么折腾的话，迟早还是走Angular的老路。
: 前端最不缺的就是框架，当初vue异军突起，能从angular react里突出重围火起来，得益于概念简单、学习曲线平缓、易于上手。
: 这个框架里塞的东西越来越多的时候，也就是式微的时候。不信等着看vue3也许就是最后一个热门版本了。
: ...................
--
FROM 101.98.83.*
15楼|eGust|2019-06-26 14:21:48|展开
我很好奇你们项目的生命周期都多长？

按照现在 agile 的德性，两三年还在不停的加功能。难道你们的项目一年出头就已经没什么事情可以干，闲到可以重写了？

【在 nikezhang (难得糊涂) 的大作中提到: 】
: 两三年重写还好吧，一年或者两三个月就重写才受不了
--
修改:eGust FROM 101.98.83.*
FROM 101.98.83.*
21楼|eGust|2019-06-26 16:13:52|展开
锁版本不能解决漏洞啊，隔几年官方已经不维护了，audit 一堆严重 vulnerabilities，难不成打算自己修么？

【在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 重要的项目一般都会锁依赖版本的吧。。。从2.6升到2.7都不敢，何况2升到3
: 不管最前沿发展到啥版本了，稳定性要求高的历史悠久项目肯定不敢追新，乖乖继续在旧版本依赖上做增量式开发。唯一的问题就是如果落后太多版本的话，社区里面现成可用的新插件轮子往往没法直接用，得改改。。
--
FROM 125.238.192.*
22楼|eGust|2019-06-26 16:55:45|展开
内部实现什么样，对使用者来说并不重要，暴露给用户的 api 才决定代码的组织形式。

react 的形式是 functional 接口，数据的组织形式是单向的，整体概念上是一致的。

vue 的组织形式可一点儿都不 functional，这点对不熟悉 fp 的用户是非常友好的。再加上 template 为主（我只在 storybook 里面用 jsx，因为实在不想专门写控件），导致不得不制造许多概念，才能满足代码复用的需求，比如 mixin、slot 什么的。

再延伸出去就是 react + redux vs vue + vuex 的问题。redux 可以说概念十分的简单，只要掌握了 immutable、pure function 就不会出错，跟 react 的思路是一致的。而 vuex 有点儿奇怪的，state - data，getter - computed，同步更新 mutation、异步 action - method，看起来一一对应，但 state 其实是 functional，只能读、走 action 更新。这与 data、computed { get, set } 是格格不入的，所以新手很容易用错。似乎说过下个版本要简化 vuex 接口，不知道会不会对新手更友好些

【在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: react和vue的核心区别是reactivity的实现方式。
: 理论上vue里面的computed watch也都不是必要概念，完全可以和react一样留给用户自己实现。父子之间的event传递也可以转化为函数prop的传递。
: 所以其实任何一个UI框架的核心概念也就是props和state嘛。本质区别还是怎么检测变动。react hooks搞得那么magical，就和react的检测机制有关。vue把检测放在了proxy/gett/setter层面，比较精细，所以vue开始做类似hooks的api的时候感觉更自然，更直观好理解。
: ...................
--
FROM 125.238.192.*
25楼|eGust|2019-06-26 19:09:08|展开
这不就体现出 api 稳定性的重要性了么

react 也不是不改 api，比如去年对 lifecycle 动刀子了。但人家 deprecated 不是说把整套 api 都给改了，几乎得重写全部代码。给你一两年的时间，慢慢把一小部分代码改掉，心理上还是比较容易接受的。

所以我一直说这次风波的核心问题并不在技术方面，而是营销策略上的问题

【在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 去年围绕这个问题圈里几个大佬吵过一次架，感觉阿里内部大部分前端/node项目组都倾向于锁版本。腾讯里面竟然还有些组不仅锁版本而且真的自己修node_modules里的bug。。
: 这个事情感觉没啥完美的解决办法，根本上说，重要的商业项目过度依赖普遍不咋靠谱的js社区，这本质上就不是特别靠谱。。。
--
FROM 125.238.192.*
26楼|eGust|2019-06-26 19:31:30|展开
我还是举一个例子吧，比如我们有这么一类 form 控件
props: { target: Object, name: String, ... }
computed: { value: { get() { return this.target[this.name] }, set ... } }

父控件把 data 中的对象和名称传给子控件，<child :target="foo" name="bar" />，子控件使用 v-model="value"，然后在 set 里做比较，决定要不要放入待传回的数据中。上周同事问了我一个问题，为什么明明我在父控件里 this.foo.bar = baz，结果这个字段却没出现？他期待子控件 computed.value.set 会被调用……

如果用 react，父控件不得不再传一个调用 setState 的方法进去，更新之后的 target 也是一个全新的对象，你觉得还能问出来这种问题么？

react 故意设计成所有的对象都应该 immutable，想有属性变化就得重新生成一个，这样你不得不去关注数据的流向。vue 的做法的确是 gc 压力小了，上 proxy 之后效率比生成新对象高更多了。但是双向数据绑定的弊病也出来了：多个源都可以去更新同一个对象，数据的流向变得难以追踪。

还是老话，对于使用者来说，并不在意内部实现是怎样的。vue 比 react 加载快了多少，内存少占用多少，复杂的页面能多画几帧，并不是那么重要。跟正确性相比，代码写得更费劲、效率低了，都不是大的问题。java 跟 c++ 比起来，不光跑得慢，还更啰嗦（不造轮子的话），但是人家不容易啰嗦错啊。

【在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 我觉得咱俩说的东西本质是一样的。
: react为什么走functional单向数据流路线？不是因为它的props和state技术上无法被直接赋值修改，本质原因是因为它的reactivity机制是检测不到直接赋值的，所以必须走setState（）之类的显式触发，整体重新生成vdom然后diff。
: vue的data为什么不需要setData（）？因为用了proxy/setter呗，所以也就没有必要非要使用单项数据流了。
: ...................
--
修改:eGust FROM 125.238.192.*
FROM 125.238.192.*