Vue 十年复盘，如何进入开悟之坡？

“本文内容来自 Evan You 在 2024 年 Vue 阿姆斯特丹大会的演讲 由童欧巴翻译润色 ”

我们刚庆祝了 Vue 上线十周年，Vue 首次在 2014 年 2 月对外公布。当我回想起来，自己也感到非常惊奇，我们已经坚持了十年。在 JavaScript 或整个前端领域，这样的时间可谓非常漫长。

记得十年前，每天似乎都会出现新的框架，大家都在抱怨。而 MVC 当时有着五十种不同的实现方式，Vue 只是众多选择中的一个。我还记得第一次在 Hacker News 上发布 Vue 时，许多评论都是：“太好了，又一个框架。”

大家都在猜测它是否能在下一年这个时候存活。而现在，十年过去了，我们依然在这里。

至于今天的 Vue，让我们来看看一些数字。这些数据结合了 Vue 2 和 Vue 3 的仓库。两者加起来，我们拥有超过 9,000 次的提交记录。

Vue 这个组织下还有更多的项目。我没有进行完全统计，因为下面有太多不同的事情在进行。不过，我们这里主要关注 Vue 核心本身的数据。

在过去十年里，Vue 核心在 npm 上有超过 490 次的发布，全球有超过两百万的用户。这基于我们的工具扩展和两个仓库的统计，包括超过 25 万的新手入门，每周超过 460 万的 npm 下载量，以及每月超过 10 亿的 CDN 请求量。

说实话，有一段时间我已经不太关注 GitHub 星标或下载次数了，但在这样一个特殊的时刻，我还是觉得记录一下这些成就是很棒的，也能给大家一个大致的了解。

我们确实在技术上产生了很大的影响。我不是来炫耀的，但我确实想谈谈一些事情，因为随着时间的流逝，当最初的想法或实验首次出现时，它们有时会被历史所掩埋，人们知道这些东西的存在，但可能不太确定是谁首创的。

Vue 在几个方面确实是首创。我们是第一个实现基于深度跟踪的响应式系统的框架。在 Vue 中，你可以对一个对象进行任意深度的修改，而整个系统仍然能够保持响应性。

我们是第一个真正追踪实际变化以实现响应性的框架。Angular 也试图实现深层响应性，但它依赖于“脏检查”。Vue 是第一个决定尝试让系统真正响应的框架。

我们还是第一个将单文件组件与构建工具相结合的。虽然我不能说 Vue 最初发明了单文件组件这一概念，事实上，Vue 的单文件组件是受到 Google 内部实验的启发。

但我们确实是第一个将其与流行构建工具，如 Webpack 和 Browserify 结合起来的。这在当时是前所未有的，我们通过构建时转换，将单文件组件转换为浏览器能理解的普通 JavaScript。如今，这已成为常规实践。

现在我们看到了像 Astro 这样的自定义格式，人们正在将它们的 SFC 转换成各种不同的格式。单文件组件实际上为这种概念铺平了道路。Vue 3 中的 Composition API 是第一个将信号样式的响应性与现代组件模型结合在一起的。

这听起来可能有些复杂，但简而言之，如今许多框架都在采用信号这一概念，Vue 在其中发挥了先锋作用。我们旨在让你能够将基于信号的响应性模型与现代的组件模型结合使用。

“童欧巴解读： Signals 并不是新事物，在 JavaScript 框架中的实现可以追溯到十多年前[1]。在去年，由 Vue 带头掀起了 Signals 浪潮。

• Solid 信号[2]
• Angular 信号[3]
• Preact 信号[4]
• Qwik 信号[5]

Vue 的 Composition API 就是 Signals 范式的一种体现。目前，框架作者们已经与 TC39 合作，争取出一份 Signals 提案，将其变成 JavaScript 语言的一部分。如果能落地，前端框架的响应式实现将变得非常简单。 ”

我们还是第一个探索如何将编译器的强大功能应用于信号的反应性转换，这是一种特别的语法糖。可能你们中的一些人以前已经使用过它。不过，最终我们认定这条路可能并不是 Vue 最适合的发展方向，因此我们选择放弃了。但不管怎样，这次的探索还是非常有意义的。我们注意到其他框架也在尝试向这个方向发展，例如 Svelte 5。

Vue 可能还是唯一一个既支持基于模板的，也支持基于非虚拟 DOM 的渲染函数的组件渲染逻辑的框架，这是因为我们实际上是将模板编译成了虚拟 DOM 的渲染函数。

此外，我们还引入了渐进式框架的概念：一个整体连贯、可逐步采纳各种库层面的工具和实用功能。这些都是建立在 Vue 核心之上的，你可以根据自己的需求选择使用多或少。这种方式为不同的使用场景提供了极大的灵活性。你可以通过 CDN 将其用于增强后端渲染的页面，实质上，这是对 jQuery 的一种轻量级替代。或者，你可以选择全面使用 Vue。你的选择可以多样化，从构建一个简单的单页应用（SPA），到使用 Nuxt 实现全栈开发，都是可行的。

因此，我认为在框架生态系统内部构建不同组件的这种方式已经逐渐成为人们所期望的，而不是一种完全单一化的结构，在这种结构中，你无法自由挑选或者单独使用某些部分。

我们从何处起步？这里有一个简短的时间线。

Vue 首次以 Vue 名称发布是在 2013 年，那时它还未真正准备好公众使用。正如我之前提到的，首次公开发布是在 2014 年 2 月，几乎刚好十年前。我们在 2015 年达到了 1.0 版本，在 2016 年达到了 2.0 版本，那也是我开始全职投身于 Vue 并开始开发 3.0 版本的年份。3.0 版本的发展历程要长得多，早期研究始于 2018 年，软启动在 2020 年。

并且，最终在 2022 年 1 月，3.0 版本成为了默认版本，这已经是两年多前的事了。再说一次，这听起来真的很不可思议，因为对我来说，这仿佛就在昨天。而 2.0 版本在 2023 年 12 月结束了其生命周期。这是一个非常简短的时间线。

我还保留着一篇关于 Vue.js 启动首周的博客文章，我记得文章中提到获取了几百个 GitHub 星标，我当时欣喜若狂。我们尝试了不同的宣传渠道，我在 Reddit 上发帖，那时还在一个名为 badass JS 的 JavaScript 博客上发帖。

是的，回想起来，从一开始的谦逊到现在，事情确实发生了巨大的变化。但同样存在起伏，对吗？我们持续成长，但在这整个过程中也有时候事情并不如预期进行，或者我只是感到极度疲惫。

在技术采纳周期中，每当新技术出现时，总会有一个起始点。然后是期望过高的高峰期，也就是所谓的炒作期。人们对此感到兴奋，认为这将是有史以来最好的东西，将是未来的方向。但当你开始在生产环境中使用它时，你可能会意识到它还未完全准备好。

作为一个维护者，接收所有这些反馈，你可能会陷入幻灭的低谷，人们可能会意识到它并不像最初声称的那么好。但如果你能坚持下去，你最终会达到开悟之坡。最后，达到生产力的高原。

我想说的是，参与开源项目，作为一个维护者，你会经历一个非常类似的过程。

当你第一次进入开源，发布你的第一个项目，有多少人发布过一个开源项目？你还记得第一次点击发布按钮时的兴奋吗？你在向全世界展示一些东西。在接下来的几周内，你可能会处于兴奋和产出的高峰期。你关注每一个问题，每一条在 Hacker News 或 Reddit 上的评论。

你尽力回应每个人，解决所有问题，确保你的项目是最好的。不可避免的是，如果项目真正变得流行，就会暴露出真正的问题。你可能会意识到，你之前从未考虑过某些问题。也许这个想法并不那么好，也许整个前提都有问题，也许这只是一个愚蠢的库，甚至不应该发布出来。

你开始怀疑自己，怀疑这个库的存在意义。你必须跨越鸿沟，意识到你的项目不必完美，也许它不能解决每个人的问题，但如果它能解决某人的问题，那就足够好了。然后，你重新获得能量和信心，继续改进它，并最终达到生产力的高原。

如果你回顾我从很早以前到现在的 GitHub 贡献图表，你会看到，自从 Vue 发布的头两个月起，我就充满了激情，基本上回应了每一个问题。

截至 2014 年 2 月 20 日，自 Vue 发布以来的头两个月，我充满了极大的兴奋。我几乎回应了每个提出的问题。但是从四月到六月，我几乎要放弃了。我想，也许这只是我随意投出的一个东西。如果人们不想用，那也没关系。

但过了一段时间，我开始重新工作，这次我对它的预期少了些不切实际的幻想。因为那时，我并不期望它成为世界上最大的框架。没关系，我只是为了自己的使用，以及那些对它满意的现有用户去改善它。有时候，我确实感到了真正的疲惫，或者只是在怀疑自己。原因有很多。有时，我只是因为用户报告的错误数量太多而感到不知所措。

我开始怀疑自己的工程能力。我在想，我为什么会产生这么多问题？有时，只是因为 Reddit 上有人发表了一些刻薄的评论。这种情况发生了不止一次，或者一些竞争对手声称他们已经解决了 JavaScript 中的最大问题，宣称他们将成为下一个大事件，而我则感到沮丧，觉得又来了一个。

这些不可避免的事情发生了。但如果你看长期的趋势，你会发现这样的时刻多次出现。生活中也发生了很多事情，如结婚、生子、跨国搬家、在口罩期间被锁定等。我的活动图表并不总是绿色的。我认为承认这一点很重要，即使从外表看我做了很多事，对吧？我并不总是生产力满满，我认为这是正常的。

你不需要一直拼命工作才能成就大事。重要的是意识到，我每次都设法反弹。有时需要更长的时间，有时较短。但这是一个过程，每次我感到疲惫时，我实际上都在尝试更多地了解自己，了解是什么导致我陷入这种状态，以及什么能帮助我走出来。每次我走出来，我对自己的了解更深，我对如何看待开源工作的想法更加成熟。

这是一个学习和成长的过程。更重要的是，没有来自 Vue 社区的惊人支持，我无法度过所有这些低谷。我为什么在这里三次强调“社区”这个词？因为它实在太重要了。

但说真的，Vue 社区确实是我在这整个旅程中最为骄傲的部分。Vue 是关于开源的，是关于人的。Vue 社区是我所知道的最多元、最包容、最欢迎的群体。正是因为有了这个社区，我才感到有动力继续前进，有理由继续做这件事。对，如果没有社区的支持，我根本不可能坚持这么长时间的工作。

在此，我要向我们的团队成员、贡献者、所有库和生态系统的维护者、我们的社区合作伙伴表达最深的感激。

感谢那些在世界各地组织 Vue 会议的了不起的人们，以及其他 Vue 会议。感谢 Vue 的支持者，那些在 Discord 上互帮互助、推广 Vue 的人们。感谢我们的赞助商。

谈到赞助商，我认为 Vue 的另一个重要方面是，我们成功找到了在可持续性、独立性以及支持人们工作方面的良好平衡。对吧？我们已经做了十年，没有任何主要的公司后盾。

实际上，如果你观察当前的框架生态，Vue 是目前唯一保持独立的主流框架，即它没有被任何单一公司主导或支持。我们很自豪能找到这样一个模型，以支持框架的持续维护和开发。

更重要的是，在这种模型下，赞助商或资助项目的人无法控制其技术方向。我认为这非常重要，因为这使我们能够真正专注于用户和开发者的需求。这也赋予我们，作为维护者，根据这些需求调整我们的兴趣和激情的灵活性。

因此，我们不会陷入仅仅为了金钱而做我们并不真心想做的事情的陷阱。大多数一直在这个时间段内坚持使用 Vue 的贡献者或团队成员之所以这样做，是因为他们真正享受在开源中的工作。他们喜欢参与到能使每个人的生活变得更好的事务中。

这不仅仅是为了一份工作而领取薪水。我认为这是另一个非常重要的方面。这种项目的独立性还使我们的团队和整个生态系统能够以开放的心态对待跨框架的特性或努力。

我们有一种真正的合作心态，我们所做的不仅仅是为了 Vue 框架本身的利益，因为我们不是一个以盈利为目的的组织。我们不在试图为投资者最大化回报。我们在这里是为了让开发者的生活变得更好，不只是限于 Vue 开发者。

有许多值得注意的努力起源于 Vue 生态系统，但最终不仅仅是为了 Vue 开发者。一些很棒的例子，如 Vite。Vite 起初仅用于 Vue，但我们最终使其变成了框架无关。现在，它可能是推动所有新一代元框架的最大因素。

Volar 是我们语言支持的基础。如果你在 VS Code 中使用 Vue 单文件组件，五年前，支持并不真的很好，但现在你可以获得完整的 TypeScript 智能提示、自动完成、类型检查。在你的 Vue 模板中，就像你在 TS 或 TSX 中得到的那样，所有这些都归功于 Volar。

类似地，Volar 的创造者决定将 Volar 下面的层抽象成支持跨框架的框架。因此，它是一个支持不同框架的语言服务的底层框架。它可以用来支持 Vue 单文件组件，Astro 组件。

同样的，我认为 MDX，这是一个在文件内嵌入 JSX 的技术，也在使用 Volar 来支持语言。所以，这是我们为 Vue 需要的东西的一个绝佳例子，但最终惠及了其他框架或语言。

其他出色的例子，如来自 Nuxt 团队的 Unjs。很多人现在使用或从这个集合中取出工具，以及 Nitro，这是 Nuxt 的底层动力。我们看到其他框架也在其基础上构建，然后我知道 Anthony Fu 对于在 Nuxt 工具之下支持其他类型工具有一些想法，这同样令人兴奋。

这是我们真正自豪的事情。而且有趣的是，我认为 Vue 是唯一一个能够孕育出如此多此类事物的社区。我们希望保持这种趋势，我认为这很棒。

现在，让我们看看当前和未来的情况。

在过去的一年中，Vue 的下载量显著增长，Vue 3 官方下载量已经超过了一半的阈值，现在占总下载量的 56%，而且这个数字还在迅速增长。

随着 Vue 2 进入生命周期末期，Vue 3.4 在 2023 年 12 月发布，仅仅两个月前。

令人振奋的是，尽管 Vue 已经有 10 年的历史，我们仍在不断对这些底层功能进行改进。我们为 Vue 3 完全重写了解析器，新解析器的速度提高了两倍。我们还对我们的反应性系统进行了重大的内部重构。因此，解析器、编译器和反应性系统实际上是构成 Vue 的基石，是底层元素。

但随着时间的推移，代码库开始显露出它的年龄，我们并不害怕刷新内部结构。就好比你在飞机上，我们正在把旧引擎换成更快的新引擎。因此，这两项更改都非常重要，它们使得一切都变得更高效，从根本上加快了运行速度。

但我们的目标是确保这些更改不会对您已经在运行的代码产生任何影响。显然，我们发现并尝试修复了一些回归错误。我们在生态系统 CI 中进行了大量投资，这使我们能够对诸如 Vuetify、Quasar 或 Nuxt 这样的生态系统库进行重大更改，以确保我们不会破坏任何东西。

因此，这将始终是 Vue 3 生命周期的重点。我们还稳定了 defineModel 和像 V-bind 同名简写这样的特性。如果您之前使用过 Vue 2，您可能已经使用了这些功能。

在即将到来的 3.5 版本中，我们有更多计划，其中有几个重点。首先是进一步提高反应性效率。目前，两个重要的 PR 已经合并到了次要分支中。第一个是对反应性系统的又一次重构，使我们的反应性系统的整体内存使用减少了一半以上。如果您感兴趣，可以在之后查看 PR 并查看确切数字。

另一个是改进大型反应性数组与反应性系统的交互。以前，由于我们使用代理，在遍历一个由代理包装的巨大反应性数组时，会有很多属性访问的开销，但我们通过这个出色的拉取请求找到了一种方法来大大减少这些开销，有些迭代可以变得快 10 倍。

接下来，我们将专注于 SSR 改进、懒水合、Suspense 稳定版本和 useId，这使您能够在服务器和客户端之间共享稳定的 ID。它们提升了很多，我知道你们许多人都很期待更新。

Vapor Mode 取得了很大的进展，不幸的是，Kevin 今天不在这里，但他一直在努力工作。它现在可以运行 TodoMVC，并且还有一个可以直接粘贴 Vue 组件并查看编译器和它们提升的差异的游乐场。你可以在游乐场中尝试它，我们也一直在对新的 Vapor Mode 进行基准测试。

我们正在改进代码生成策略，确保生成的组件代码保持精简，避免膨胀。接下来，Vapor Mode 的下一个重点是正确排序组件模型部分。这里的重点是希望 Vapor Mode 中的组件尽可能地低开销。

因此，无论您创建了多少个组件实例，都不应该因为组件数量过多而使您的应用变得极其缓慢。

同时我们也在开发体验方面进行更多改进。我们希望通过投资更底层的工具链进一步改进 Vite。

我们之前讨论过 Rolldown，它已经在开发中一段时间了。并且 Rolldown 已经能够进行基础打包，能够处理大部分的 CommonJS 和 ESM 源码。根据初步基准测试，它的速度实际上是传统构建工具的两倍，这是一个相当大的进步。

但要注意，它还未完全具备所有功能。我们还需要加入更多功能，如代码拆分、更高级的摇树（Tree Shaking）特性或是源映射修改。虽然还有很多功能缺失，但当前的性能统计非常令人鼓舞。

Rolldown 旨在拥有一个完全兼容 Rollup 的插件接口，这意味着我们的最终目标是使用 Rolldown 替代 Vite 内的 ESBuild 和 Rollup。因此，所有当前运行在 Vite 上的应用无缝地变得更加快速，无论是在开发还是生产构建中。

Rolldown 基于一个名为 OXC 的 Rust 基础工具链构建，在核心层面，它是一个极快的基于 Rust 的 JavaScript 解析器。在 OXC 上，还有其他工具链，例如基于 Rust 的解释器。

一旦 TypeScript 转换和代码缩减功能完全集成到 OXC 中，Rolldown 将能直接有效地处理你的代码，因为它建立在 OXC 之上。这允许我们将处理 JavaScript 和 TypeScript 源码的各种任务合并为一个单一工具。

与今天的情况相比，当你构建一个 Vue 应用时，你的源码实际上会经过五个不同阶段的处理，从 Vue 的解析器到 ESBuild、Rollup 解析器，再到代码再次处理，最后通过 Terser 压缩。

我们希望简化这些阶段，确保整个过程尽可能高效。但这项工作超出了 Vue 团队的范围，有一个专门团队负责这些事项，我也参与其中，我们会在今年晚些时候分享更多详情。

我们正在尝试简化 Nuxt 和 Vue 开发工具之间的层次结构。同时， Johnson Chu 仍在积极开展 Volar V2 的进一步改进工作，旨在消除对某些模式的需要。这应该能够大幅减少内存使用量，我们称之为 takeover 模式。这将使我们能够大幅降低内存使用，简化开发过程。

总之，Rolldown 的目标是提供一个完全兼容 Rollup 的插件接口，从而使用 Rolldown 替换 Vite 内的 ESBuild 和 Rollup，使所有当前运行的应用在开发和生产构建中都能获得速度提升。

Rolldown 建立在名为 OXC 的 Rust 基础工具链之上，这为 JavaScript 解析提供了极速的性能。随着 TypeScript 转换和代码缩减功能的完全集成，Rolldown 将使处理过程更加高效，将所有相关任务合并为一个单一工具，大大简化了处理流程。

这项工作由一个与 Vue 团队分开的专门团队进行，我们将在今年晚些时候提供更多细节。