背景：Reddit 上的 RFC 讨论
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 的原点。你觉得要求你的用户这样做是公平的吗？你确定这就是你们想要的结果吗？
dessant 说：
「兼容版」这个词说明了 Vue 团队对旧 API 的态度。兼容对我来说意味着过时的。
boubiyeah 说：
我不知道为什么尤雨溪不能在这两个版本的命名问题上更坦率一点。 为什么尤就不能直接说「我在版本命名和对未来的计划上有些问题，社区的反应让我知道我应该修改一下措辞」。 相反，他说的是：「你在说什么？我一直都是这样想的呀」。
gustojs 说：
这可能有一部分是我的错。尤雨溪主要关注点在技术层面，而我的关注点在社区方面。我们没有意识到版本命名带来的潜在问题。
尤雨溪的最终回应
尤雨溪回应道：
首先，新 API 跟性能关系不大，Vue 3 的性能提升主要来源于新的模板编译策略。 其次，我觉得你把问题简化成新 API 会带来复杂性有点不合适。这份 RFC 很难理解，因为里面的信息量太大了。实际上你可以看看这个例子，你很可能就会了解新的 API 并不会带来新的复杂性： Vue 有大量的用户，老实讲我不太理解为什么新增一批 API 会是一种冒犯。因为我们清楚地了解到新的 API 在某些情况下会更优雅，也许你还没有遇到这些情况（我不是说你目前的需求比较低端）。我们在应对不同的应用，所以这些情况我们都要考虑。相反，如果你认为 Vue 永远不会遇到一个复杂到必须使用这些新 API 的需求，那才是一种冒犯。 最后回答你的问题：只要你愿意，你可以一直使用旧 API。只要社区认为旧 API 有必要保留，我们就会一直保留。我们不会强迫你用新 API。
