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

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

首先是 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 并不会带来新的复杂性：https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f8af555
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 并没有更新

完。

转载于:https://juejin.im/post/5d10364e51882532d937f261