这几天国外关于 Vue 新 API 的一些争论

16,687

本文只是翻译 :) 掘金的排版比知乎好太多了。

首先是 Reddit 上有人发帖。

标题:Vue 3 将大变——目前的语法会被弃用,组合函数将最终作为创建组件的唯一方式

内容:

尤雨溪几天前发布了一篇 RFC(意见征求稿),介绍了 Vue 3 里基于函数的 API。
许多我们正在使用的特性都会被弃用,诸如 data、computed、methods、watch、mixin、extends 和生命周期函数。Vue 组件主要由一个叫做 setup() 的函数构成,这个函数会返回所有的 method、计算属性和监听器。

如果你想继续使用旧版功能,Vue 会提供一个兼容版本。

文章里还说:

新的 API 和 2.x 的 API 理论上完全兼容(只是多了一个 setup()选项) 。但是,新 API 的引入实际上会让相当一部分的旧选项长远来说变得没有必要。如果能够去掉对这些旧选项的支持,可以获得相当的代码尺寸和性能提升。

因此,3.0 我们计划提供两个不同的版本:
兼容版本:同时支持新 API 和 2.x 的所有选项;
标准版本:只支持新 API 和部分 2.x 选项。

更新:
他们澄清说旧版 API 将会和 Vue 3.x 共存。Vue 4.x 会不会删掉旧版 API 就不确定了
看起来尤雨溪读了网上了评论,他声称我的这篇帖子是不准确的,与此同时他却把原文的措辞修改了。之前的「兼容版本」被改为「标准版本」,之前的「标准版本」被改为「轻量版本」
你能读大家的评论并且听取大家的意见,这很好。但是你不应该改写你的文章,然后说我误解你了。


后续,Vue 团队在 hacker news 上发了一篇回应,翻译如下:

我是 Vue 的团队领导。
相关的帖子里有很多误解,所以我们需要澄清一下:

  • 新的 API 完全是额外加到 Vue 2.x 里的,不会有任何 break change。
  • Vue 3.0 会有一个标准版本,包含新 API 和旧 API,同时会额外提供一个轻量版本,这个版本会删除一些旧 API,以使 Vue 更小更快。
  • 这只是一个「意见征求稿」,所有 API 都没有盖棺定论。你可以留下自己的建议,我们并不是马上就会发布 Vue 3.0。
    更多详情请看这里:vuejs/rfcs

回应文完,接下来是这篇文章下面的评论。

lwansbrough 评论到:

尤你好,虽然新 API 的提案澄清了这些变化被定为Vue 3 的可选项,但 Vue 团队的长期重点尚不清楚,新 API 看起来就像是为 Vue 4 设置的诱饵。

问题的关键在于:当 Vue 2 发布时,我们觉得 Vue 2 的设计相比于 React 足够简洁,所以上了 Vue 2 的车。而当时 React 的重点主要是函数式和基于性能的UI开发方法(现如今 React 依然在关注这些)。

如果你有一个超级专注于性能,并非常喜欢函数式的团队,React是更好的选择。 Facebook 也会继续大力投资于性能改进。新 API 里你们也非常关心性能,这很好,我很欣赏这一点,但你们这样做会违背了另一波人的想法。

性能不是 Vue 的卖点,函数式编程也不是 Vue 的卖点,这个 RFC 里提到的其他奇奇怪怪的东西都不是 Vue 的卖点。没有人会看着 Vue 说「哇,在渲染某个测试组件 1000 次的时候,Vue 比 React 快了整整两毫秒耶!」

采用 Vue 的人是什么人?是哪些对 React 表现出的复杂性不满的人。而现在,Vue 团队却告诉我「React 的方法更高级,适合高级用户」。坦白讲,这是一种冒犯。我们早就预测了 React 带来的复杂性不值得我们的团队去尝试,或者我们已经在用 React 的过程中遇到了问题,所以我们才选 Vue,因为 Vue 搞定了这些问题而且能做到和 React 一样高效。

如何才能在 React 的地盘打败 React?Vue 3 似乎给出了答案(译注:答案就是模仿 React)。恭喜你们 Vue 团队打败了 React(译注:我猜这里的意思是尤雨溪说 Vue 的新 API 跟 React 相似但是性能更好),但是我们等的不是这个答案。这不是我们想要向我们的团队、我们的老板、我们的利益相关者给出的答案。

我想问你一个问题:我该如何管理我的代码?长期方案应该是重写我应用里所有的代码(在 Vue 3 存在的时间里),然后我就回到了原点,那个我放弃 React 转向 Vue 2 的原点。你觉得要求你的用户这样做是公平的吗?你确定这就是你们想要的结果吗?

尤雨溪回应道:

首先,新 API 跟性能关系不大,Vue 3 的性能提升主要来源于新的模板编译策略。
其次,我觉得你把问题简化成新 API 会带来复杂性有点不合适。这份 RFC 很难理解,因为里面的信息量太大了。实际上你可以看看这个例子,你很可能就会了解新的 API 并不会带来新的复杂性:gist.github.com/yyx9908
Vue 有大量的用户,老实讲我不太理解为什么新增一批 API 会是一种冒犯。因为我们清楚地了解到新的 API 在某些情况下会更优雅,也许你还没有遇到这些情况(我不是说你目前的需求比较低端)。我们在应对不同的应用,所以这些情况我们都要考虑。相反,如果你认为 Vue 永远不会遇到一个复杂到必须使用这些新 API 的需求,那才是一种冒犯。
最后回答你的问题:只要你愿意,你可以一直使用旧 API。只要社区认为旧 API 有必要保留,我们就会一直保留。我们不会强迫你用新 API。

另一个人评论到:

我只想说 RFC 有一个重大的变化,之前写的是「标准版」和「兼容版」,标准版不支持 data / computed / methods / watch / provide / inject / mixins / extends 和所有声明周期。
RFC 更新之后,之前的「兼容版」变成了「标准版」,而之前的「标准版」变成了「轻量版」。

dessant 说:

「兼容版」这个词说明了 Vue 团队对旧 API 的态度。兼容对我来说意味着过时的。

boubiyeah 说:

我不知道为什么尤雨溪不能在这两个版本的命名问题上更坦率一点。
为什么尤就不能直接说「我在版本命名和对未来的计划上有些问题,社区的反应让我知道我应该修改一下措辞」。
相反,他说的是:「你在说什么?我一直都是这样想的呀」。

gustojs 说:

这可能有一部分是我的错。尤雨溪主要关注点在技术层面,而我的关注点在社区方面。我们没有意识到版本命名带来的潜在问题。


最后,就在6小时前,尤雨溪发了一篇推文:

Earlier today I was really itching to write a dedicated blog post for those who did not and still refuse to actually read the RFC, but it's my wife's birthday so I'll do it tomorrow.
前些天我非常想要写一篇专门的文章给那些至今还没有读过 RFC 的人看,但是今天是我老婆的生日,所以我会明天写这篇文章。


补充:中文版 RFC 并没有更新

完。