目录
这几天国外关于 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 并没有更新
完。
饥人谷一直致力于培养有灵魂的编程者，打造专业有爱的国内前端技术圈子。如造梦师一般帮助近千名不甘寂寞的追梦人把编程梦变为现实，他们以饥人谷为起点，足迹遍布包括facebook、阿里巴巴、百度、网易、京东、今日头条、大众美团、饿了么、ofo在内的国内外大小企业。 了解培训课程：加微信 xiedaimala03，官网:https://jirengu.com
