Vite：纪录片

本纪录片探讨了 Vite 这一现代前端构建工具的起源、发展历程及其对整个 JavaScript 生态系统产生的深远影响。故事的开端可以追溯到更早的时期，那时 JavaScript 尚未被业界广泛认真对待，开发者们正在努力应对应用规模增长带来的挑战。

JavaScript 长期以来被认为存在一些固有的缺陷。在当时的环境下，开发者们开始意识到将过多的 JavaScript 代码发送到客户端是不可持续的。早期的需求集中在代码压缩和整合不同的包，这催生了许多粗糙的工具来处理这些任务。

开发者们通常会构建由 Grunt 或 Gulp 等工具组成的链条，试图将 JavaScript 构建流程缝合在一起。这种方法本质上是让开发者编写 UI 代码，然后将构建管道像意大利面条一样杂乱地串联起来，导致应用最终只是简单地倾倒在浏览器中，缺乏创新性。

（早期的构建）就像一团意大利面条式的混乱，开发者们只是将不同的工具拼凑在一起。

大约在应用规模和复杂性增长到单页应用（SPA）的时期，Webpack 出现了。Webpack 的核心理念是让一切都通过 JavaScript 运行，无论是 HTML、图像还是 CSS，JavaScript 都充当构建工具，一切都假设需要进行捆绑处理。

尽管今天捆绑大小依然重要，但在当时，捆绑是一个极其重要的环节。几乎所有元框架都建立在 Webpack 之上，使其成为当时市场上的主要参与者。然而，随着应用变得越来越庞大，在 JavaScript 中处理所有数据不再是最快的方案，每次保存文件都需要等待大量的捆绑工作，而这些工作在开发时可能并不需要。

人们普遍认为 Webpack 难以驾驭，配置复杂到需要专业知识才能设置。它被称为“有史以来最大的‘选择你自己的冒险’”。社区开始意识到需要一个新的层次来整合所有组件，并探索是否存在不同的前进路径。

Evan You 在 2014 年创建了 VueJS，其官方 CLI 也是基于 Webpack 构建的。Webpack 的热模块替换（HMR）功能在初期具有吸引力，但随着项目规模增大和工作负载增加，HMR 的性能会逐渐恶化，导致构建性能和扩展性问题。

Evan You 个人对项目启动缓慢、热更新缓慢的现象感到非常沮丧。他质疑为什么 Vue 开发者必须接受这种级别的开发体验。他研究构建工具的全部动机都是为了改善 Vue 用户的开发体验，这促使他寻找替代方案。

我当时最沮丧的可能就是我自己的项目，我注意到它在脚手架项目、启动项目以及热更新方面都很慢。

第一个想法是探索是否可以拥有一个不进行捆绑的本地开发服务器，而是利用浏览器原生的 ES 模块能力。这意味着浏览器原生支持模块，那么捆绑的必要性何在？可以直接将模块发送给浏览器，并希望这种方式能适用于 Vue 组件。

在 2020 年 4 月，一个想法突然出现：如果通过原生 ESM 实现热模块替换会怎样？这个想法出现后，必须立即尝试。Evan You 决定回到办公室开始编码，最终在深夜 2 点到 3 点左右成功运行了原型，速度快得惊人。这证明了即使是巨大的 Vue 项目，保存后也能在一百毫秒内更新，比原来快了约 50 倍。

在原型工作完成后，Evan You 感到非常兴奋，并很快想出了 Vite 这个名字。在原型成功的一两天内，他便发布了 Vite 的第一个版本，并发布了推文向社区宣告。

当 Evan 发布 Vite 时，社区成员注意到了它。然而，由于它最初只是一个概念验证（Proof of Concept），功能尚不完善，许多人只是认为它很有趣，但尚未完全投入使用。Vite 的发布时间与 Snowpack 的第一个版本相近。

Vite 的早期阶段主要集中在 Vue 应用的构建上，这使得一些非 Vue 开发者对其持观望态度。最初，一些人认为这只是又一个构建工具的尝试，并且由于其处于早期阶段，显得有些粗糙，因此被视为一种好奇心而被搁置。

为什么要构建另一个捆绑器？这有点粗糙，功率有点低，还处于早期阶段。

在 Vite 的早期阶段，Snowpack 也开始崭露头角，两者几乎在同一时间起飞。从最高层面来看，Evan You 是为了解决 Vue 开发者的问题而努力，而 Snowpack 则旨在彻底取代 Webpack，消除捆绑的需要。

尽管出发点不同，但两者最终在功能上产生了大量重叠，这使得它们成为了竞争对手。双方都意识到这是一个全新的模型，有大量的领域有待探索，当时除了他们两个工具外，几乎没有其他工具在做类似的工作。

在 2020 年，一位开发者因对 Webpack 的长期不满，开始寻找更快、更好的工具来构建应用程序。Svelte 语法非常吸引人，但 Svelte 的 Rollup 设置同样存在开发周期缓慢的缺点，因此他开始研究如何改进这一点。

该开发者尝试了 Vite 的第一个版本，但它最初是为 Vue 构建的，并非框架无关。他与同事花了几个晚上进行修改，绕过了 Vite 的一些限制，成功地让 Svelte 组件编译和热模块重载工作起来。这种方法效果出奇地好，Svelte 社区开始青睐它，并在几周内获得了大约 300 个 GitHub Star。

Evan You 持续迭代 Vite 的设计，致力于将其打造成一个真正可用于生产环境的工具。当时 Vite 版本号仍处于 0.x 阶段，这促使一些开发者决定尝试使用它。

Vite 1.0 阶段主要针对 Vue。下一步是使其更加通用，并引入插件系统。当发现 WMR 等竞争性解决方案支持 Rollup 插件时，Evan 意识到可以在不进行捆绑的开发服务器环境中模拟 Rollup 插件的运行环境。这意味着可以使用同一个插件接口同时支持开发和生产，并支持其他框架。

当我做出那个决定时，我们已经在 1.0 RC 阶段，但我感觉这个方向的改变非常值得，所以我决定完全放弃 1.0 的发布计划，开始彻底重写，这最终成为了 Vite 2.0。

最终的结果是，所有期望中的复杂功能，如插件、转换、捆绑拆分、优化和路由处理，都可以由 Rollup API 来处理，这具有颠覆性的意义。这引发了一场竞赛，因为 Vite 正在努力将 Snowpack 的特性整合进来。

Vite 2.0 带来了“魔力般的感觉”，它神奇地快速运行且开箱即用。许多人喜欢 Vite 的一个主要原因是它简化了一个传统上对初学者来说非常复杂的问题：设置带热重载的开发服务器和生产构建管道。

Vite 2.0 的新设计和架构引起了人们的共鸣，早期采用者主要来自 React 社区，他们正在寻找 Create React App 的现代替代品。许多人声称在安装并测试后的几分钟内就提供了积极反馈。

当时基于 Web 的 IDE StackBlitz 启动速度很快，但基于 Webpack 的开发服务器可能需要数分钟才能启动。在了解到 Evan You 创造了 Vite 之后，StackBlitz 团队阅读了文档，立即意识到 Vite 就是他们所需要的解决方案。

Vite 的设计方式鼓励整个生态系统进行协作，这使得 StackBlitz 团队下定决心在财务上支持 Vite 团队，以确保他们拥有继续投入资源所需的资源，从而跟上即将到来的爆炸性增长。

Svelte 团队在 2019 年维护的 Sapper 框架未能实现其对现代应用框架的愿景。随着前端开发格局的变化，他们有机会重新思考现代开发工作流程。他们决定采用 Snowpack，并在一次演示中展示了使用 Snowpack 配置的 SvelteKit。

SvelteKit 团队的 Rich Harris 曾公开宣布支持 Snowpack，认为这是 Svelte 团队的“Webpack 时刻”，是不可避免的未来。这为 Snowpack 提供了很大的可信度。与此同时，社区中也出现了 SVite 这样的工具，旨在快速设置 Vite。

SvelteKit 团队在使用 Snowpack 时遇到了问题，因为作为一个新工具，它有自己独特的工作方式，许多事情需要重新发明。在他们遇到这些问题时，Vite 2.0 恰好发布了。

Vite 2.0 的出色之处在于它决定使用 Rollup 进行生产构建，这意味着用户可以立即访问整个 Rollup 插件生态系统。这解决了新项目面临的巨大障碍——如何使用现有工具而无需从零开始。因此，SvelteKit 团队不得不向 Snowpack 团队表示，他们认为 Vite 更好。

我们非常抱歉地告诉 Snowpack 团队，实际上我认为我们必须和你分手。

SvelteKit 团队联系了 SVite 的维护者 Dominik Gopel，邀请他加入团队协助构建。最终，SVite 成为了官方的 Svelte Vite 插件，并在 SvelteKit 稳定发布时，成为其官方插件，尽管这一决定当时引起了争议，但被认为是完全正确的。

在 SvelteKit 宣布转向 Vite 之后，Astro 团队也做出了选择。与其继续与 Vite 竞争，不如加入其中，将 Vite 作为一个台阶来构建自己的工具。Astro 团队从第一天起就决定与 Vite 社区联手。

通过这种合作，Astro 团队获得了一批拥有完美技能集的贡献者，他们立即开始为 Vite 社区做出贡献。

2021 年初，尽管 Vite 2.0 发布了，但下载量仍然不高，直到社区开始热议其速度后才迅速增长。随着 SvelteKit 和 SolidStart 等社区的加入，Vue 社区也已在其中，Evan You 意识到自己不能成为 Vite 未来发展的瓶颈。

Evan You 发布了 GitHub 讨论串，表示希望将项目发展壮大并组建团队。Anthony Fu、Underfin 和他自己成为了首批核心团队成员。在 2.x 时代，大部分工作集中在修复 Bug 和打磨功能上，但随着使用量的增长，这不再是令人兴奋的工作。

随着采用率的提高，测试问题成为阻碍 Vite 进一步普及的一个主要障碍。许多早期用户在尝试将 Create React App 迁移到 Vite 时，发现很难让现有的测试框架 Jest 很好地与 Vite 兼容，因为 Vite 太新了。

在一次团队会议中，有人开玩笑说应该有一个“Vite 原生”的单元测试运行器，能够理解 Vite 的配置并使用相同的插件。这个想法催生了“Vitest”这个名字。Anthony Fu 立即行动，在短短四小时内就拿出了原型，并在第二天展示了工作成果。

随着下载量和用户数量的持续增长，维护负担也随之增加，团队需要找到一种方法来扩大团队的带宽。Eric Simons 主动联系团队，表示 Vite 对他们来说已成为关键路径，希望有意义地参与到 Vite 生态系统中。

Eric Simons 提议全职投入 Vite 工作，并于次年二月加入 StackBlitz 负责 Vite。随后，其他团队成员也开始获得允许花费带薪时间在 Vite 上的职位，例如 Matias 被 StackBlitz 雇佣，Bjorn 参与 Svelte 和 Astro，Anthony 则受雇于 NuxtLabs。

2022 年情况变得更加疯狂，下载量增长了约 5 倍，到年底达到了每周 250 万次左右。越来越多的元框架开始采用 Vite，包括 Nuxt 3、Qwik、Laravel、Storybook 和 SolidStart 等。

框架采用 Vite 的趋势持续到 2023 年，Shopify 的 Hydrogen 团队也全面拥抱 Vite。Vite 似乎在一夜之间从 Vue 领域的工具，变成了几乎所有前端解决方案的默认选择。

它从‘通常是 Vue 领域’的工具，在一夜之间变成了‘字面上是所有东西的默认解决方案’。

在此期间，Create React App 中存在的大量功能已经严重过时。许多人对继续被引导使用这种过时工具感到心痛。Theo Browne（t3.gg）发布了批评 Create React App 的视频，引发了相当大的争议。

该争议获得了极高的关注度，Dan Abramov 在评论区发表了经典文章。讨论之所以引人注目，是因为 Vite 在如此短的时间内成功地改变了基准线，使得选择 Vite 成为显而易见的决定。

在加入 StackBlitz 后，Evan You 与 Eric Simons 讨论举办 Vite 会议的想法，旨在聚焦于 Vite 身上正在发生的特殊事件。他们开始组织第一届 ViteConf，并邀请了所有维护者参加。

Speaker 名单令人印象深刻，涵盖了 SvelteKit、SolidStart、Storybook 等利用 Vite 的工具框架的作者。这种来自不同竞争框架的作者在同一会议上讨论共同主题的情况非常罕见，Evan You 意识到 Vite 所做的一切开始对大量 Web 开发者社区的开发体验产生显著影响。

看到来自不同竞争框架的人们来到同一个会议上就一个共同主题进行交谈，这是非常罕见的成就。

随着项目规模和使用量的增加，在发布新版本之前进行测试变得至关重要，因为担心一个错误可能会破坏生态系统中许多其他工具。过去的做法是手动协调，通知每个元框架维护者进行检查，这种协调工作无法扩展。

Dominik G. 出现并开始构建一个工具，用于测试 Vite 与 Vite 插件 Svelte 之间的变更，以确保 Vite 的更新不会破坏插件。Vite 团队开始使用这个工具来验证未来的构建，这证明了该工具的实际用途。最终，他们决定不仅测试 Vite 自己的 CI，还要测试所有主要下游项目的 CI。

Remix 团队在早期并没有将 Vite 视为首选选项，尽管他们基于以速度著称的 ES Build。然而，随着时间的推移，他们开始遇到性能问题，例如每次更改都会导致整个应用重新构建，社区对 Vite 支持的呼声越来越高。

Remix 团队开始再次询问是否应该使用 Vite。Mark 加入团队后，他们决定在个人 GitHub 账户下创建一个原型进行尝试。SvelteKit、Astro 等其他框架的作者都在生态系统频道中向 Remix 团队提供帮助，协作过程比预期的要快得多。

Mark 发了一条推文说，我们正在协作，没有竞争感。在那一刻，我们都为我们共同建立起来的东西感到非常自豪。

这一趋势持续到 2023 年，出现了更多重大的采用案例，例如 Angular、Storybook（增加了一流的 Vite 支持）以及测试工具如 Playwright 和 Cypress 也开始使用 Vite 进行组件测试。

前端生态系统中不再仅仅是元框架，而是许多支持工具也意识到 Vite 已经成为一股不可忽视的新力量。如果使用任何现代 JavaScript 框架（NextJS 除外），那么很可能正在使用 Vite。

在开始支持 Vite 时，它尚未成为主流。但很快，Vite 就成为了默认选择。任何新的项目或新技术都倾向于支持 Vite，不再有特定于框架的构建工具，这似乎是所有人都心照不宣的共识。

每个人似乎都得出了相同的结论：Vite 已经有效地成为了无处不在的默认标准。

Evan 和整个团队希望 Vite 成为一个易于使用、快速且安全的开源工具。恰好这些特性使得它非常适合像 Bolt AI 实验室这样的前沿 AI 实验室，用于训练他们的模型。Bolt 于 2022 年 10 月推出，其上创建的所有项目本质上都是 Vite 项目。

Vite 的下载量本已呈指数级增长，但随着 Bolt 的推动，其增长势头变得更加迅猛，被视为一股不可阻挡的力量。

截至目前，Vite 每周在 NPM 上的下载量已超过 1400 万次。认识到 Vite 正在成为共享的基础设施，存在一个机会来改进其底层的一切。JavaScript 生态系统需要一个统一的工具链。

构建统一工具链的想法从未消失。JavaScript 和 TypeScript 现已成为全球最大的应用开发语言。尽管 JavaScript 生态系统历来非常分散，且库作者意见强烈，但 Vite 成功地促使这些人就应该建立在何种基础之上达成了一致。

团队希望利用这种前所未有的共识势头，推动对 JavaScript 生态系统更基础的改进。他们审视了自身的依赖项，发现仍然依赖于 ES Build 和 Rollup，而对这些第三方依赖项的控制权有限。

团队明确表示，目标是为 JavaScript 构建一个统一的工具链，使开发者空前高效，并使人们更容易长期创建和维护这些应用程序。

宇宙似乎会奖励那些出于正确动机做事的人。工具的流行很大程度上源于其文化，而非仅仅是技术上的优劣之争。这是一个关于协作的故事，许多不同的社区齐聚一堂，共同构建了这个共享的基础。

这个时代的命运已经注定。