与 Natalia Tepluhina 合作的 Smashing Podcast 第 26 集：Vue 3.0 有什么新功能？

在这个播客集中，我们谈论的是 VueJS。 3.0 版本中有哪些新内容，迁移难度如何？ Drew McLellan 与核心团队成员 Natalia Tepluhina 交谈以找出答案。

显示注释

• VueJS
• Vue 3 迁移指南
• 娜塔莉亚在推特上
• 娜塔莉亚的个人网站

每周更新

• 设计数字产品页面的不同方法
  作者：苏珊娜·斯卡卡
• React Native 应用程序中的单元测试
  作者：财富池地
• Google Analytics 帮助 Web 开发人员进行 UI/UX 设计的 5 种方式
  由克拉拉·布恩孔塞霍撰写
• 了解 TypeScript 泛型
  由杰米·科克希尔撰写
• 如何使用面部运动与排版交互
  作者：爱德华多·卡瓦扎

成绩单

Drew McLellan：她是一位充满激情的 Web 开发人员、Google 开发人员专家、会议发言人和作家。 目前她是 GitLab 的一名前台工程师，但作为 Vue JS 核心团队成员，您可能最了解她。 很明显，她比几乎任何人都更了解 Vue。 但是你知道吗，她曾经教过一只袋鼠唱歌。 我的 Smashing 朋友们，请欢迎 Natalia Tepluhina。

德鲁：嗨，娜塔莉亚，你好吗？

Natalia Tepluhina：嗨，Drew，这是我姓氏的一次非常好的尝试。 我需要给你学分。 当他们试图发音我的姓氏时，这是我从说英语的人那里听到的最好的事情之一。 如果你不会说俄语，我想这是不可能的。 正确的发音是 Tepluhina，但这就像，这就是为什么我通常只是要求人们叫我 Natalia，让我们停下来。

德鲁：好的，我努力了。 但重要的问题是，你在粉碎吗？

娜塔莉亚：我当然是。

德鲁：那很好。 所以我今天想和你谈谈我们在 9 月份发布的 Vue 3.0 的一些非常令人兴奋的消息。 就版本号而言，它是一个主要版本，但它确实是 Vue 的一个大版本，并且已经投入了很长时间，不是吗？

娜塔莉亚：是的。 我认为我们在 2018 年首次发布了第三版。我认为它是在春季宣布的，真正的工作开始于，我的意思是想法是在春季，真正的工作是在 2018 年秋季开始的。 我认为它是在 2018 年 10 月举行的伦敦会议上正式宣布的。积极的工作花了两年时间。 如果你想一想，这很多，之前的版本是在 2016 年发布的。所以这四年的一半时间也致力于 Vue 3 的工作。

Drew：决定需要一个新的主要版本的动机是什么？ 这是一种有意识的决定，好吧，我们要开发一个主要版本，我们要开发 Vue 3，还是只是一种只需要版本提升的变化的积累？

Natalia：不，我认为创建一个新版本是一个想法，因为有一些非常重要的事情。 因此，首先，有改变反应性的动机。 前一个基于 Object.defineProperty。 它有一些警告，它们都已记录在案，但仍然存在。 你知道，即使你记录了人们不应该做的事情，他们还是会去做。 您需要将它们指向文档。 顺便说一句，没有人会阅读文档。 出于某种原因，它只是发生了。 直到你指出人们在它的文档中不存在它。 不过没关系。 无论如何，我们都会教你。 所以反应性是其中之一。

娜塔莉亚：表演是下一个。 Vue 2 仍然有并且没有最差的性能，但是我们有一些关于如何让 Vue 更快的想法。 对于我们的特定部分，比如说观众，使用 Vue 的人来说，也有一个痛点。 那是打字稿。 Vue 2 内部是用 Flow 编写的，它仍然是强类型的，但是使用 TypeScript 打字是一场真正的噩梦，特别是如果你正在使用我们的状态管理 Vuex。 这又是一个很大的部分。 最后一个是，我们有点错过了抽象逻辑的功能，不是组件，而是可组合的逻辑部分。 像函数助手等，但它们也应该能够包含查看器活动。 一个很好的例子可能是 React Hooks，它们允许你抽象部分功能，而这在 Vue 中显然是缺失的。 而且我知道现在听起来像是“你从 React 偷了这个特性”。 事实上不是。 我相信想法异花授粉是我们生态系统中一个重要而美好的部分，它还可以帮助开发人员在收藏夹之间切换，对吗？

Natalia：所以我们正在开发这些主要功能来创建 Vue 3 作为主要版本。

Drew：现在我认为存在于开源生态系统中的一大优点是来自各种不同项目的大量想法和经验，并且能够借用这些想法并从其他项目中借鉴经验项目真的是有益的，让一切变得更强大，不是吗？

娜塔莉亚：是的。 我认为它的工作方式就像我们在 GitLab 中调用迭代值的方式一样。 当你想出一个想法时，它永远不会完美。 它主要是一些非常原始、非常硬编码的东西。 也许会改变一些东西，但这绝对不是完美的。 你需要对这个想法进行几次迭代才能使它真正好，甚至不完美，只是好。 并且随着生态系统中的想法而发生。 有人想出了一个好主意，你就接受它，让它变得越来越好。 我敢打赌，会有一些东西会从 Vue 中汲取一些想法，也许他们已经从 Vue 中汲取了一些想法，并使其变得更好，这里没有什么不好的。

Natalia：我强烈反对，比如，“你在窃取想法”。 这不是偷窃，这只是异花授粉。

德鲁：没错，是的。 您提到迁移到 TypeScript，所以现在 Vue 3 本身是使用 TypeScript 编写的，对吗？

娜塔莉亚：是的，是的。 相信我，Drew，我正在编写文档，关于如何使用 Vue 和 TypeScript 的小文档。 我当时想，好吧，可能有点像 Vue 2。而且我把文档过于复杂了，我就像是明确地输入了所有内容。 看起来不错，一切都已键入。 我可以看到类型，所以我的 ts-link 很开心，到目前为止一切都很好。 然后是我们的一位使用 TypeScript 的开发人员，“你不需要这样做”。 怎么样，怎么样？ “你不需要对数据进行显式类型。 您只需给它一个初始值， ts-link 就知道它的编号。 已经打好了。” 比如，怎么来的？ “我从文档中删除了 90% 的显式类型。 您真正需要输入的只有两件事是组件的代理，以及计算属性。 他们仍然需要返回类型。 但是其余的就像是自动键入的，只需使用我们称为定义组件的方法编写一个组件。 就是这样。 是打字的。”

纳塔利娅：就像，它只是工作。 对我来说，在我过去的经验中，我经常使用 Angular，我有 TypeScript 的斯德哥尔摩综合症。 一切都应该明确输入。 我的意思是，如果你有复杂的类型，当然你需要编写接口，但这就是 TypeScript 的工作方式。 不过，现在使用 Vue 3 使用 TypeScript 要容易得多。

Drew：太好了，所以这对 Vue 核心项目和使用 Vue 构建应用程序的开发人员都有好处，因为他们现在可以在他们的应用程序中很好地使用 Vue，而 2.0 和任何版本都无法使用 TypeScript 2.0 这么容易。 熟悉 Vue 社区的人会知道，Vue 的创建者 Evan You 仍然非常积极地领导该项目。 核心团队如何运作？ 在开发过程中它是如何构建的？ 不都是埃文吗？

Natalia：这是一个很好的问题，Drew，因为多年来，从字面上看，人们一直在谈论 Vue，我引用这个，我会听起来很苛刻，但抱歉，它就像，“一个中国人的框架，甚至像中国人的框架” . 我的意思是，即使是 Vue 1.X，也已经有了一个团队，并且 Vue 2 背后有一个大团队，而 Vue 3 背后的团队更大。问题是当我们谈论 Vue 时，我们都有不同的责任。

Natalia：有一些人在开发 Core，这不仅仅是 Evan 本人，他正在做 Vue Core 的大部分工作，当然，他也在领导这个项目。 但也有人在 Vue Core 工作，他们的贡献绝对是无价的。 还有一些新人也加入了 Vue 团队，他们在 Core 工作。 还有一些较小的团队在研究生态系统，有些人在研究 Pure Router，比如 Eduardo，有些人在 Vue CLI、Vuex 和文档方面工作。

Natalia：有一个完整的团队在处理文档，因为我们认为文档很重要。 目前在我们的网站上有，我认为 21、20 或 21 人，总是错过计数，属于核心团队，但这不是一个静态列表。 因为我们，我们显然没有招聘，我们是一个开源团队，这不是有偿工作。 但是我们相信，如果有人对 Vue 生态系统的任何部分做出了很大贡献，那么当人们已经完成核心团队成员的工作时，这只是通过访问存储库和正式标题来给予他们认可。

Drew：这很好，因为在这种情况下，为开源项目做出贡献可以真正回报个人。 他们得到了一些认可，这可能会对您的职业生涯以及您拥有的东西产生影响。

Drew：对于可能不习惯 Vue 但可能熟悉其他响应式框架的听众，例如您知道 React、Angular 等。 Vue 3 有哪些重大的标题变化，特别是它们试图解决的问题是什么？ 您之前提到构图是其中之一，那是大的变化吗？

Natalia：是的，这是最大的变化之一，它实际上是其中之一，首先，让我在这里明确声明。 组合 API 纯粹是附加的。 不是你需要重写你的组件，你可以给它们添加 TypeScript。 或者您可能更喜欢使用所有语法，现在我们将其称为选项 API，这些术语不会对您有所改变。 就像，当我们谈论新的 API 时，这并不是一个重大变化。 我只想真正强调这一点，这真的很重要，因为当它第一次宣布 Composition API 时，那是一个糟糕的时刻。

Natalia：我认为我们并没有很好地描述这些变化，而且我们让标准构建看起来像是 Composition API。 这完全是我们的坏事，选项就像，也许我们会在未来的构建中弃用它，而不是在 Vue 3 中，很明显。 如果人们有可能读错你说的话，他们就会读错。

Natalia：在这个声明之后，我们刚刚在 RFC 中提出了改变，Reddit 爆炸了。 Reddit 上充满了类似的东西，“哦，我的上帝。 我将需要写下一切。 我的天啊。 Vue 是新的 Angular。 他们会破坏所有的东西。” 还有一个人在 dev.to 上写了一篇文章，叫做 Vue's Darkest Day。 老实说，那是最黑暗的一天。 我们是这么认为的，但我想在自己的 Twitter 上与此作斗争，比如，“我们不是真正的人……他们说我们开始改变 RFC，我认为 Evan 开始改变 RFC 却没有宣布改变。 所以他就像，“我会很快重写这个。 让我们像推入大师一样”。 人们对此很生气。 因为他们在争论某些观点，所以你只需刷新一个页面，这些观点就不再存在了。 你觉得，我是个傻瓜还是只是……什么鬼？ 我的意思是，它就在那里。 我记得这个。 而且我相信我们的沟通策略可以更好，这不是我们。

娜塔莉亚：现在，每次我谈到作曲时，这纯粹是加法，人们。 这只是一个不错的功能。 你可以使用它，你不能使用它，你没有义务这样做。 只是……它存在。

Drew：如果Composition API 是一种新事物，可以帮助他们摆脱这个问题，那么人们可能会遇到什么样的问题？ 它在解决什么问题？

Natalia：想象一下内部有一些功能的组件。 假设它是搜索和排序。 假设我们搜索某个列表并尝试对其进行排序。 这已经是两个不同的特性，而 Vue 组件的特点是，它们是根据选项而不是逻辑进行拆分的。 想象一下，您的搜索可能有一个查询，因为您需要对搜索和结果数组进行查询。 这是两个反应属性。 就您的组件而言，您将它们放在称为数据的选项中。 显然你需要一些方法来执行排序。 也许是单击按钮，也许是其他东西，运行搜索的东西。 您创建方法。 对于排序，您需要在排序选项上构建一些东西，这是另一个反应性属性。 然后你执行一些计算来对结果进行排序。

Natalia：在 Vue 中，为此，您还拥有计算属性，这是另一种选择。 最后，您的组件变得非常碎片化。 想象一下我是一名开发人员，我的任务是只在搜索部分工作。 我现在不能拆分组件，因为这两个功能在它们的方式上有点交叉。 我搜索一些结果并对它们进行排序。 而且我需要从数据跳转到方法，从方法跳转到计算，最后真的很难切换上下文。 特别是如果组件变得非常大。

Natalia：我们在 Vue 2.0 中有哪些选择？ 第一个选项称为 mixins，mixin 只是一个对象，它可以包含组件可以具有的相同属性，我们正在将它们与组件混合。 听起来不错，我可以将所有搜索移到那里，有什么问题？ 有几个。 首先，这完全不灵活。 如果我想搜索某个端点并将其移动到 mixin，这将是我可以搜索的唯一端点。 Mixin 不接受参数。 我创建了一个 mixin，它完全是静态的。 第二个问题是混入了 mixin，这意味着对于某些属性，它就像合并一样发生。 例如，如果您创建了钩子，它将被合并。 来自 mixin 组件的生命周期钩子中的所有逻辑都合并在一起。 但是，如果您有一个数据属性，mixin 中有一个冷查询，并且您有任何机会在组件中具有相同的属性，则该组件具有优先级。 它将被覆盖。 您不会收到任何警告。 绝对地。 它会发生，你不会知道这会发生。

德鲁：所有的范围都是完全混合的？

娜塔莉亚：是的，完全。 你没有机会看到，而且，mixin 的来源非常不清楚。 您只需导入带有名称的mixin并将其放入查看组件属性mixin，就是这样。 这是非常含蓄的，我是从我自己的经验来看的。 我们在 GitLab 中有一个逻辑，其中一个组件包含两个 mixin，而这两个 mixin 中的每一个都包含另一个 mixin。 到这里，这是您需要检查的属性，它不在组件中。 让我们更深入，第一级混合。 这个不包含它，这个也不包含它。 在哪儿？ 您正在深入研究，就在兔子洞的深处，只是为了找到这个属性，测试也变成了一场噩梦。

Natalia：让我说，Mixins 是一种非常愚蠢的提取逻辑的方法。 很简单，很清楚，很容易得到。 如果您想在高级级别上使用它，它会给您带来很多问题。 Vue 2.0 中抽象逻辑的下一个方法是无渲染组件。 在 Vue 中，组件可以包含一个插槽。 基本上，您可以在其中放置父组件中的任何内容。 一个小窗口，实际上是一个插槽。 并且有一个范围插槽的想法。 想象一下子组件可以将自己的作用域暴露给父组件，并且插槽内容将可以访问它。 想象一下，我有一个带有插槽的组件，组件执行有关搜索的所有逻辑，假设搜索的终点是过去的参数。 我们的子组件，例如搜索，然后将其范围的这一部分公开给父组件。 这些是搜索结果。 享受。 听起来不错。 听起来绝对比 mixins 好。 我们可以测试参数。 这里的逻辑很明确，我们正在返回一些东西。 问题？ 有几个。

Natalia：首先，您已经创建了组件实例。 这不是世界上最便宜的手术。 第二部分，运行时。 该组件仅在运行时有效，这意味着该组件的公开属性只能在您将其公开为插槽范围的插槽中，因此您的搜索结果仅在模板的一小部分中可用。 如果您想使用组件的离散部分，则无权访问那里。 它是运行时。 如果您在其他地方需要反应状态，则无需执行此逻辑。 当然它可以像纯函数一样创建助手并返回结果，但是，如果我需要对反应属性进行操作怎么办？ 这就是组合 API 的创建方式。 使用 Composition API，您可以拥有独立的反应状态。 反应状态不再只是组件的一部分。 您可以使任何对象或原语具有反应性。 你可以把它暴露给父母，这是非常明确的。

Natalia：你想归还给父母的每一个财产都暴露了。 很明确，你可以点击这个，你可以看到它在哪里，它是什么，等等。 最好的部分是，如果您将 Composition API 的部分包含到具有数据方法、计算机属性等的旧组件中，它就可以正常工作。 它工作得很好，您只需向组件添加一些反应性属性和方法，您也可以将它们与旧选项 API 一起使用。

Drew：当涉及到非常复杂的组件甚至是轻度复杂的组件组合时，这听起来真的会帮助开发人员清理他们的代码库。 你提到了 mixins 和事物的可测试性，Composition API 是否允许更好的可测试性？

Natalia：是的，绝对是因为 Composition API，如果我们从中排除生命周期钩子，因为您还可以在 composeable 中运行另一个生命周期钩子。 它实际上是纯函数。 你有 S 参数，你正在做某事并且在生命周期钩子之外仍然有副作用。 如您所知，测试纯函数可能是最简单的事情。 它只是一个黑匣子，你有 S 参数，你有东西要返回。

Drew：这听起来是一个非常全面的解决方案，我相信很多使用 Vue 构建更复杂应用程序的人都会喜欢它。 这听起来确实是一种非常好的方法来消除我知道可以通过 mixins 潜入的那种错误，其中很容易引入错误，就像你提到的那样，合并范围和所有这些事情。

Drew：我一直认为，在选择在框架之上构建时，一个重要的考虑因素是它的 API 随着时间的推移的稳定性。 也许稳定性不是一个正确的词，但我认为我们中的许多人已经被构建在一个框架之上，然后经历了一次大的改造，并给我们留下了需要大量投资才能迁移的应用程序，或者它们最终会被绑定到不再支持的旧版本的框架。 这是一个可怕的情况。将一个大项目从 Vue 2 迁移到 Vue 3，我会失去多少睡眠？

Natalia：首先，API 表面与原来的 90% 相同。 我们没有那么多可被弃用的事件中心替换的弃用的东西或弃用的过滤器。 如果您想使用 EventEmitter，您还需要将基于视图的视图替换为一些外部库。 这些都是很大的变化，但说到迁移……让我说清楚，我现在真的很伤心，因为一方面我是 Vue JS 核心团队的成员。 另一方面，我是使用 Vue 的大项目中的一名高级工程师。 如果您现在要开始迁移，我不建议您这样做。 首先，生态系统没有发布，我的意思是，如果我们谈论 Pure Router、PUX、Vue CLI 等核心库，这些库的状态很好，但它们仍然是候选发布版，而不是发布版。 如果我们谈论其他生态系统，比如可能不是核心库、UI 组件库，可能是一些表单验证库，它们大多还没有为 Vue 3 做好准备。如果你有一个大项目，你需要有很多依赖项关心。 所以这将是一件复杂的事情。

娜塔莉亚：有什么选择？ 你有一个大项目，你想使用所有这些 Composition API 的优点。 如何做到这一点？ 首先，我们计划发布 Vue 2.0、Vue 2.7 的 LTS 版本。 这将包括大量弃用警告，因此您将能够看到将要弃用的内容，以及如何重构它以不使用 Vue 3 破坏它。所以从技术上讲，您仍将使用 Vue 2，但您将准备 Vue 3无论如何，因为你有所有的警告。

Natalia：其次，我们将使用一个能够运行它的迁移工具，它将作为一个 codemod 工作，用 Vue 3 替代品替换与 Vue 2 相关的东西。 当然，没有代码模块是完美的。 首先，我们的目标是尽可能进行替换，但在不容易处理弃用时也会显示警告。 Codemod 将能够识别事物并发出警告，但不能自行替换它。 这就像一个大计划，当 Vue 2.7 发布时，如果我没记错的话，我认为现在他们的估计时间是 12 月，我需要查看路线图，但我认为是 12 月。

Natalia：生态系统也将或多或少准备就绪。 如果您有一个使用 Vue 2.0 的大型项目，请稍等一下，直到 Core 稳定下来，因为即使您制作了一个完美的库，它仍然需要一些时间来稳定，因为人们开始使用它，人们开始报告错误。 如果您打算将它用于宠物项目并报告错误，请非常欢迎您这样做。 在此之后将有一个很好的平滑方式迁移到 Vue 3。

Drew：所以你提到的迁移工具听起来很有趣。 这基本上是一个静态分析工具，可以查看您的代码并......

Natalia：是的，是的，是的，它是一个代码或一个工具。 现在它以非常有限的方式可用。 它可以作为 Vue CLI 的插件使用。 如果您有基于 Vue CLI 的项目，您可以运行 Vue 升级并查看该工具的工作原理。 到目前为止，它还不是我们想要的形状。 不幸的是，我不从事基于 Vue CLI 构建的项目。 我需要等待并检查发生了什么，但是，例如 GitHub，即使没有准备迁移工具，我们也已经采取了一些步骤，因为我们知道不推荐使用的内容。 它实际上在 Vue 3 文档中有所说明。

Natalia：有迁移指南。 您可以看到所有重大更改和已弃用的内容，甚至可以在 Vue 2.0 代码库上处理其中的一部分。 例如，在 Vue 2.6 中，我们更改了插槽的语法。 范围槽的语法已被弃用但未被拒绝，它仍然存在。 它会发出警告，但您可以运行它。 当然，对于一个已经有 7 年历史的代码库，没有人会关心替换所有已弃用的语法，如果它正常工作的话。 生产中没有警告。 插槽工作。 在开发中，“哦，我在控制台中看到了一些警告。 可能有20个，很好。 是黄色不是红色。 我不在乎”。

娜塔莉亚：你知道这发生在每个人身上。 我们创造了一个巨大的史诗来解决这个问题。 查找所有当前的旧语法集。 我们努力替换我们的 EventEmitters，同样，七年的项目，不要评判我们。 我们有 EventEmitters。 GitLab 正在开发 EventHubs。 我们用外部库替换了基于 Vue 的乐趣。 我建议也这样做。 通过迁移指南检查已经可以替换的内容以及您已经可以进行哪些更改以准备并开始工作。

Drew：在迁移工具的当前状态下，这是一个用代码库测试水域的好方法。 只是运行它，看看它已经标记了什么，看看它是否看起来还可以，或者是否有一些大的东西，或者它是否仍然不成熟？ 等到 12 月才能真正解决问题会更好吗？

Natalia：如果我有一个大项目，我不建议这样做。 如果您有一个小的坏项目或者一些个人项目，但它不是那么大，我建议您运行它并检查您拥有的任何问题，因为对于两个中型项目，我一直在运行它。 我想一两个问题。 我不能说它不成熟。 它已经处于良好状态。 但是对于大型项目来说，它是遗产，是一些异国情调的东西。 不要在生产中这样做，人们。

Natalia：另外，如果您想使用项目的脚手架，现在 Vue CLI 支持两种模式。 您可以创建 Vue 2 项目，也可以创建 Vue 3 项目。 至少一定要试一试。 这对我们来说也是一个好方法，因为当您玩游戏时，您会发现错误，报告错误，我们会尝试修复它们等等。

Drew：在文档和开发路线图中，我看到提到了迁移构建。 这与我们谈论的内容不同还是我们正在谈论的内容不同？

娜塔莉亚：不，不，都是一样的。 它是同一个，它应该已经准备好了，但是现在，如果您计划迁移，主要路径就是阅读文档并遵循那里所说的任何内容，因为只要我们没有迁移工具，我们肯定会努力，文档团队继续前进并创建了详细指南，说明了更改内容、进行更改的原因以及此处实际替换的内容。

Drew：是的，作为 Vue 3 文档的一部分，文档中有一个非常全面的迁移指南，其中提到了需要迁移的大量更改。 我想其中一些不会影响每个项目。 对于很多人来说，其中很多基本上都是边缘案例。 这公平吗？

Natalia：是的，其中很大一部分，例如过滤器，肯定是一些边缘案例，因为即使在 GitLab，第三次使用七年的代码库和一个大代码库。 我们有一两次过滤器出现，它们不再使用了。 我们搜索并完全删除它们是一件好事，因为就像“哦，未使用的代码”，再说一次，谁在乎它只是存在。

Natalia：我会说完全颠覆性的变化是模型的变化。 看看这个，因为我知道的每个项目都至少包含一个 Vue 模型，这是肯定的。 这应该被检查，也许属性也会改变，因为目前我们包括类和风格，管状和以太。 如果你曾经使用过 Vue，以前它不包括在内。 现在，将类和样式传递给子组件的方式略有不同，它们绝对值得关注。

德鲁：很高兴知道。 与 Vue 一起发布的 3.0 版本，我的意思是你提到了生态系统和它周围的一切，Vuex 和生态系统的所有其他部分，需要推进到那个水平。 这就是为什么，目前，网站、“开始”这个大按钮仍然全部使用 Vue 2 吗？ 感觉就像 Vue 3 已经发布但没有完全的信心。 但是否因为生态系统问题，它仍然如此？

Natalia：不，我想你只是发现了一个错误，让我快速检查一下。 不，get started指向Vue 3，没问题。 我的意思是，如果您访问 vuejs.org，它会指向第二版。 这是有意的，因为我们计划用 Vue 2 之类的子域替换它，该子域正在进行中，但到目前为止，我们决定将 vuejs.org 留在原处并创建 Vue 3，这就是为什么在 vuejs 上有一个横幅。组织。 如果你去看任何文档-

德鲁：是的，顶部有一个非常小的横幅。

娜塔莉亚：是的，就像小号一样。

德鲁：是的。

娜塔莉亚：我想我们应该把它弄大点。 更大并且具有更好的色彩对比。 我的可访问性感觉就像，“哦，那里没有对比”。

德鲁：这是个好消息。 如果有人开始，也许不是一个大项目，但如果有人开始个人项目或想学习 Vue，当然，Vue 3 是开始的地方吗？

娜塔莉亚：我会这么说。 顺便说一句，学习曲线并没有那么不同。 因为文档团队打算使用旧的语法选项，所以我不应该说旧的，它实际上是当前的语法。 熟悉的语法作为默认语法。 因为如果您浏览 Vue 3 文档，您只会在高级主题中看到 Composition API，并且您使用 Vue 3 的学习路径与您在 Vue 2 中的学习路径有点相似。从较新的开始没什么大不了的如果你只是学习 Vue 并尝试使用它，我相信如果我们谈论职业，这将是一个更好的投资。 开始学习新版本，因为它会超过所有项目。 最终，可能半年，一年，即使是大型项目也会有迁移。

Drew：在我的个人职业生涯中，我似乎拥有进入平台的真正才能，就像他们正处于大迁移的过程中一样。 我的意思是，你还记得吗？ 当他们正在过渡到点语法时，我想到了这一点，我必须同时学习两者。 我在这里，我发现自己在上个月第一次在 Vue 中工作，这是一个 Vue 2 项目，我边走边学习，并期待 Vue 3 中的所有内容。当然，在迁移过程中学习一些东西是一个有趣的时间，但听起来 Vue 并不太难，一旦生态系统赶上了 Core，那么我们应该处于一个好位置。

娜塔莉亚：哦，德鲁，我只是想说明一下你所说的关于大项目移民的一切。 你可以想象我，2018 年，我加入了 GitLab。 我不是核心团队的成员，我只是此刻的贡献者。

Natalia：就在 Evan 说“哦，我们要制作 Vue 3”的同时。 每个人都喜欢，“是的，很酷”。 2019 年春天，您是核心团队。 我的意思是整个 GitLab 就像，“哦，这很可爱。 我们都有移民，你知道谁应该对此负责吗？” 你只能想象当你为 Vue 3 编写文档时会发生什么，每个人都会阅读，而你自己的公司会说，“哦，我想了解一些关于 Vue 3 的知识，我看不懂你的文档。” 所以你会说，“哦，该死的，这太痛苦了”，因为你是那里的开发人员和技术作家，有点在这里。

Natalia：你在这中间，但是，我不得不说它对框架也非常有益，因为任何用框架创建的大产品都是一个伟大的、绝对伟大的战场，可以找到错误并将它们带回库，以生态系统。 可以说是测试，而且 GitLab 是开源的，Vue Test Utils，是 Vue 的一个测试工具。 一个团队正在使用我们基于测试的测试代码，这很有意义，对。 因为你可以找到一些边缘情况等等。 但是，当我考虑将 GitLab 迁移到 Vue 3 时，我觉得自己对此负有责任。 我不仅在迁移中，而且我个人对我们将发现的每一个错误负责。

Drew：回顾上一代的 JavaScript 框架，我认为其中最成功的框架之一是 jQuery，在当时，我认为它之所以受到关注，是因为它有一个设计得非常好的 API。 正是这种使用 CSS 选择器并使用它来查询 JavaScript 中的 DOM 的概念是 jQuery 普及的东西。 而且我认为这确实引起了勤奋的开发人员的共鸣，他们不需要学习使用 JavaScript 的新方法。 I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it's doing. And if I need to do something I've not done before I can sort of guess at how it would be implemented and usually I'm right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It's changed slightly but we had a concept that was called Documentation Driven Design. And it's a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that's why it's intuitive. If it's easy to explain, people probably will get it on themselves. That's why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don't need to explain what v-if is doing because it's clear, right.

德鲁：确实如此。

Natalia: It's kind of insulting and same with v-else. V-if, v-else-if, v-else and that's it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It's all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn't work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It's so nice to use”. I'm just building the same stuff and it's just been a pleasure. I don't need to think about the tool, I'm thinking about what I'm going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I've been working with Angular from version two to version six on a commercial project and it's a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it's just hard being a developer. And after this, working with Vue is like, “Oh, it's just like a walk in the park”.

Drew: There can be a danger with software that when it's so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that's a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it's better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I'd been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it's easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You're free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it's not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I'm like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it's good and stable and it's developing and it's not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it's actually better for the framework.

Natalia: Last year we introduced the RFC process. It's actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it's not decided, it's not set in stone. We just have an idea and we want to hear what community thinks. I believe it's great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it's true. It's actually shaped by community. It's not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They're not shaping the framework and I believe this is great.

Drew: It's quite telling when you mentioned the list of active Core Team members is 20ish people and they're all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you're at GitLab and there are other people who are just independent consultants and it's not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We're changing direction, we're not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I've spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you're listening to this, the site will have changed and will just be Vue, but that's also where you find the docs and in the docs is that really good migration guide that we mentioned. I've been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I've been learning about Apollo Client version three. It's funny, because if you look at versions and I've been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we're adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you're curious about Apollo Client version three definitely give it a try. It's interesting to see how it's evolving.

Drew: I'm definitely going to give that a try. I've used Apollo on a couple of projects and it's really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.