第2章 历史与演进
9 分钟阅读
2.1 诞生背景：传统构建工具的速度瓶颈
话说前端圈子的构建工具发展史，就是一部"蜗牛进化史"。
2010 年代初期，前端项目还很单纯——写几个 HTML、几个 CSS、几个 JS 文件，用手直接在 <script> 标签里写代码，搞定了。那时候的"构建工具"基本等于一个 FTP 上传工具，把文件拖进服务器就完事了。
然后 JavaScript 变得越来越复杂，模块化成了刚需。CommonJS 出现了，AMD 出现了，require.js 和 Browserify 出现了。前端工程师们终于过上了"import 一个模块就像写 Node.js 一样优雅"的日子。
但是问题来了——当你的项目有几百个模块、几十个第三方依赖的时候，浏览器每次加载页面都要发几十个网络请求来拿这些文件。网络请求越多，加载越慢，用户就越不耐烦。
这时候，打包工具（Bundler）横空出世。Webpack 就是这个时代最耀眼的明星。
然而 Webpack 有一个致命的弱点——慢。
有多慢呢？慢到前端工程师们开始流传一个段子：“Webpack 编译的时候，你可以去泡一杯咖啡，回来还没编译完，于是你又去泡了一壶茶，茶喝完了还没好，于是你又去逛了一圈超市……”
这还真不是夸张。随着项目越来越大，Webpack 的构建时间从几秒到几十秒，甚至几分钟不等。开发时改一行代码，等半天才能看到效果——这种感觉，就像你点了一个外卖，骑手已经出发了，结果他绕地球一圈才给你送到。
为什么这么慢？因为 Webpack 是用 JavaScript 写的，运行在 Node.js 上，而 Node.js 只有一个线程——Webpack 只能用到一个 CPU 核心。更要命的是，Webpack 为了兼容各种古老的模块化方案，内部逻辑极其复杂，就像一辆为了能在泥地、山路、雪地都能开、结果造得无比沉重的坦克。
2017 年，Parcel 横空出世，打出了"零配置打包工具"的旗号，一度让人眼前一亮。但 Parcel 虽然配置简单，速度上也没有质的飞跃。
前端社区急需一个真正快到离谱的打包工具。
2020 年，一个人用 Go 语言写了 esbuild，这个工具的诞生，直接把打包速度从"泡咖啡"级别拉到了"眨眼之间"级别。前端工程师们终于发出了这样的感叹：“原来打包可以这么快！”
2.2 创始人 Evan Wallace 与开源故事
Evan Wallace 是一个典型的"技术宅"，平时话不多，但一出手就是王炸。
他的背景很有意思——不是什么大厂的光环加持，而是一个普普通通的独立开发者，自己在 GitHub 上维护着好几个项目。他最早做 esbuild，纯粹是因为自己被 Webpack 的龟速折磨得受不了了。
据他自己在博客里回忆，那是一个普普通通的下午，他打开一个中等规模的项目，运行 npm run build，然后去倒了杯咖啡。咖啡喝完了，编译还在跑。他又去泡了杯茶。茶喝完了，编译还在跑。他把茶水间能喝的都喝了一遍，最后编译终于结束了。
Evan 看着这个场景，陷入了沉思：“我能不能自己写一个快的？”
于是他拿起了 Go 语言——一种以高性能著称的编译型语言，开始了 esbuild 的开发。
2020 年 7 月，esbuild 正式发布。Evan 把代码上传到 GitHub，并写了一篇介绍博客。结果呢？帖子在 Hacker News 上一路飙升，直接冲到了榜首。前端社区炸锅了：“什么？一个打包工具能快成这样？”
评论区里有人惊叹，有人质疑，有人立刻开始在自己项目里实测。结果实测数据出来后，所有人都沉默了——esbuild 的速度，真的是其他工具的几十倍到上百倍。
esbuild 的代码仓库地址是 github.com/evanw/esbuild，有兴趣的可以去围观一下。一个有意思的细节是：Evan 把这个项目设为 MIT 开源协议，也就是说——随便用，随便改，随便商用，不用有任何顾虑。
2.3 版本演进时间线
esbuild 的版本演进历史，并不像某些"祖传代码库"那样复杂曲折，而是一部简洁清晰的进化史。
2.3.1 0.x 实验阶段
esbuild 的第一个版本是 0.1.0，发布于 2020 年 4 月 13 日。
这个阶段的核心目标只有一个：验证 Go 语言写打包工具这条路到底行不行得通。
说实话，最初版本的 esbuild 非常简陋——支持的特性很少，插件系统更是没有。很多人当时的态度是：“哦，挺快的，但那又怎样，功能太少了，不实用。”
但 0.x 阶段解决了最重要的问题：证明了 esbuild 的速度不是吹的，是真的。
2.3.2 0.7.x 首个稳定版
2020 年 9 月，esbuild 发布了 0.7.0 版本，标志着它从"实验品"向"实用工具"迈出了关键一步。
这个版本开始支持更多的 JavaScript 特性，CSS 处理也更加完善。很多开发者开始认真考虑把 esbuild 用在自己的项目里。
2.3.3 0.9.x 插件系统引入
2021 年 3 月，esbuild 发布了 0.9.x 系列，其中 v0.9.6 正式引入了插件系统（Plugin API）。
这是一个重要的里程碑——在此之前，esbuild 的能力是固定的，你想扩展它的功能？没门。插件系统出现之后，开发者可以自定义 esbuild 的行为，处理更多类型的文件，比如 .vue、.yaml、.png 等等。
从此 esbuild 从一个"单打独斗的打包工具"变成了一个"有插件生态的平台"。
2.3.4 0.12.x 代码分割与更多特性
2021 年 5 月，esbuild 发布了 0.12.0 版本，这是 esbuild 发展过程中的一个重要节点，带来了许多开发者期待已久的功能——包括代码分割功能的完善与改进。
这个版本之后，esbuild 补齐了更多能力短板，生态也日趋完善，逐渐成为前端工作流中不可或缺的一环。
2.3.5 0.x 持续迭代阶段（至今）
截至 2026 年 3 月，esbuild 的最新稳定版本为 v0.27.x，依然保持在 0.x 版本区间。
Evan Wallace 对 0.x 版本的态度很有意思——他曾多次在博客中表示，esbuild 还没有到达他心目中的"1.0"标准，原因是他认为还有一些 API 设计和功能上的问题没有彻底解决。不过这并不影响大家积极地把 esbuild 用在生产环境里。毕竟，速度已经快到这种程度了，谁还等得起一个"正式版"呢？
这个阶段 esbuild 的发展方向主要是两个：
- 兼容性更好——支持更多浏览器版本、更多 TypeScript 特性
- 插件生态更丰富——越来越多的工具开始基于 esbuild 开发插件
2.4 里程碑版本回顾与关键功能更新
如果说 esbuild 的历史是一条河流，那么以下几个版本就是河流中最重要的几个"水闸"——每一个都打开了新的可能。
v0.7.0：初次可用
这是 esbuild 第一个真正意义上的稳定版本。它解决了"能不能用"的问题：打包能跑了、TypeScript 能转了、CSS 能处理了。对于很多小型项目来说，这个版本已经足够用了。
v0.9.6：插件时代
v0.9.6 引入插件系统，是 esbuild 生态建设的起点。你可以把它理解为：“esbuild 从一辆整车变成了一个平台，你可以在上面插各种零件。”
从此，esbuild 的能力边界不再由官方决定，而是由社区决定。
v0.12.x：代码分割（Code Splitting）支持
这是一个让很多人惊喜的功能。代码分割可以让打包产物分成多个文件，浏览器按需加载，而不是一口气把整个 bundle 塞进去。
虽然 esbuild 的代码分割有一些条件限制（后面注意事项章节会详细讲），但对于很多场景来说已经够用了。
v0.17.0：上下文 API 与热更新
v0.17.0 是另一个重要节点，引入了全新的 context API，将增量构建、watch 模式和 serve 模式统一管理。这是 esbuild 走向成熟的重要一步，也让开发体验更加友好。
2.5 当前稳定版本与发展现状
截至 2026 年 3 月，esbuild 的最新稳定版本为 v0.27.x（持续迭代中），版本号随着小版本更新不断攀升。
现状可以用一句话总结：esbuild 已经从"实验工具"变成了"行业标配"。
看看这些数据你就知道了：
- Vite 默认使用 esbuild 作为开发服务器
- Remix 基于 esbuild 做构建
- SvelteKit 使用 esbuild
- Astro 使用 esbuild
- 无数类库用 esbuild 来打包 npm 版本
esbuild 的 GitHub 仓库已经收获了数万颗星（截至写作时约四万多颗），社区插件也已经有上百个。可以说，esbuild 已经成为前端工具链中不可或缺的一环。
未来发展方向
根据 esbuild 的发展动态和作者的博客透露，未来主要方向包括：
- 更全面的 TypeScript 支持——继续完善对 TS 高级特性的处理
- 更好的错误提示——让开发者在出问题时能更快定位
- 性能进一步提升——Go 语言的优化空间还有不少
- 插件生态深化——让更多复杂场景可以在 esbuild 生态里解决
2.6 与同类工具的竞争格局变化
esbuild 的出现，改变了整个前端构建工具的竞争格局。
以前：Webpack 一家独大
在 esbuild 诞生之前，Webpack 是绝对的霸主。不管你喜不喜欢 Webpack，如果你要做前端项目，几乎没有别的选择。那时候的竞争格局是：Webpack vs “没人用的小众工具”。
Webpack 的缺点大家都知道——慢、配置复杂。但因为别无选择，大家只能忍受。“真香"和"真难用"同时存在，这就是 Webpack 时代的真实写照。
现在：三分天下
esbuild 出现之后，竞争格局发生了巨大变化：
- esbuild：速度最快，但功能相对简单，适合需要极致速度的场景
- Rollup：生态成熟，输出干净，适合打包类库
- Webpack：功能最全面，插件最多，但速度最慢，适合超大型复杂项目
更重要的是，它们之间不是非此即彼的竞争关系，而是互相补充。很多工具已经把 esbuild 内置进来——比如 Vite 的开发服务器就是用 esbuild 驱动的。
未来：融合趋势
一个明显的趋势是：不同工具之间的边界正在变得越来越模糊。
- Rollup 开始引入 esbuild 的压缩插件
- Vite 同时用 esbuild 和 Rollup
- esbuild 的插件生态越来越丰富
未来的构建工具，可能不是"谁取代谁”，而是"各有分工，共同协作"。esbuild 找到了自己的生态位：作为极速的转译和压缩引擎，被集成到各种更上层的工具里。
本章小结
本章我们回顾了 esbuild 的前世今生。
我们知道了它诞生于 2020 年，是作者 Evan Wallace 因为受不了 Webpack 的龟速而一气之下写出来的。短短几年时间，它从 0.x 实验版发展到功能完善的 0.27.x，插件系统从无到有，从"大家觉得不实用"到"成为行业标配"。
esbuild 改变了前端构建工具的格局，让"速度"成了评价打包工具的一个重要维度。它不是来取代 Webpack 的，而是来填补"极速转译和压缩"这个空缺的。
了解了历史之后，下一章我们来看看 esbuild 到底能干什么——打包、转译、压缩、Tree Shaking、开发服务器，这些能力的背后原理是什么？