为什么又造个轮子？
为什么又要构建一个 JavaScript 构建工具呢？因为当前用于 Web 的构建工具比用户期望的性能至少慢一个数量级。我希望这个项目可以作为一种“存在证明”，证明我们的 JavaScript 工具实际上能比现在快得多。
基准测试
我想到的用例是打包用于生产的大型代码库。这个流程包括压缩代码以减少网络传输时间，以及生成源映射（对于调试生产中的错误是非常重要的）。理想情况下，构建工具还应该具备快速构建能力，而不必先预热缓存。
我的主基准测试会将 three.js 库复制 10 次并从头开始构建单个包，过程中没有任何缓存，从而模拟一个大型代码库。在这个基准测试中，esbuild 比我测试的其他 JavaScript 打包器（Webpack、Rollup、Parcel 和 FuseBox）快 10-100 倍。这个基准测试可以使用’make bench-three’来运行。
时间数据取三次运行中最好的一次，主要运行环境如下：
使用’–bundle --minify --sourcemap’来运行 esbuild。使用’rollup-plugin-terser’插件，因为 rollup 自身不支持压缩。Webpack 使用的是’–mode = production --devtool = sourcemap’。Parcel 使用默认选项。FuseBox 使用’useSingleBundle: true’配置。绝对速度基于总行数（包括注释和空白行），当前为 547,441。测试是在配备 16GB RAM 的 6 核 2019 MacBook Pro 上完成的。为什么这么快？
几个原因：