Bun 的新 Bundler：比 webpack 快 220 倍？ _Bun

文章插图

Bun的快速原生捆绑器现在处于测试阶段。它可以通过 bun build CLI 命令或新的 Bun.build() JAVAScript API 使用。

文章插图

从头开始捆绑 10 份三份.js副本，带有源映射和缩小
使用捆绑器通过内置 Bun.build() 函数或 bun build CLI 命令构建前端应用。
JavaScript
【Bun 的新 Bundler：比 webpack 快 220 倍？】CLI
Bun.build({entrypoints: ['./src/index.tsx'],outdir: './build',minify: true,// additional config});降低 JavaScript 中的复杂性
JavaScript 最初是表单字段的自动填充，如今它为将火箭发射到太空的仪器提供动力。
不出所料， JavaScript 生态系统的复杂性呈爆炸式增长。你如何运行打字稿文件？您如何构建/捆绑用于生产的代码？该软件包是否适用于 ESM？如何加载仅限本地的配置？是否需要安装对等依赖项？如何使源映射正常工作？
复杂性需要时间，通常花费在将工具粘合在一起或等待事情完成上。安装 npm 包需要很长时间。运行测试应该需要几秒钟（或更短）。为什么在 2023 年部署软件需要几分钟，而在 2003 年将文件上传到 FTP 服务器需要几毫秒？
多年来，我一直对JavaScript周围的一切缓慢感到沮丧。当从保存文件到测试更改的迭代周期时间变得足够长，以至于本能地检查黑客新闻时，就出了问题。
这种复杂性是有充分理由的。捆绑器和最小化器使网站加载速度更快。TypeScript 的编辑器内交互式文档使开发人员的工作效率更高。类型安全有助于在将错误交付给用户之前捕获错误。作为版本控制包的依赖项通常比复制文件更易于维护。
当“一件事”被拆分为如此多的孤立工具时， “做好一件事”的Unix哲学就崩溃了。
这就是我们构建 Bun 的原因，也是为什么今天我们很高兴推出 Bun 捆绑器。
Yes, a new bundler是的，一个新的捆绑器
使用新的捆绑器，捆绑现在是 Bun 生态系统的一流元素，包括 bun build CLI 命令、新的顶级 Bun.build 函数和稳定的插件系统。
我们决定 Bun 需要自己的捆绑器有几个原因。
Cohesiveness
捆绑器是一种元工具，它编排并支持所有其他工具，如 JSX、TypeScript、css 模块和服务器组件——所有这些都需要捆绑器集成才能工作。
今天，捆绑器是JavaScript生态系统中巨大复杂性的来源。通过将捆绑引入JavaScript运行时，我们认为我们可以使交付前端和全栈代码更简单，更快。

快速插件。插件在轻量级的 Bun 进程中执行，启动速度快。
无冗余转译。使用 target: "bun" ，捆绑器生成针对 Bun 运行时优化的预转译文件，从而提高运行性能并避免不必要的重新转译。
统一的插件 API 。Bun 提供了一个统一的插件 API ，可以同时与捆绑器和运行时一起使用。任何扩展 Bun 捆绑能力的插件也可以用来扩展 Bun 的运行时能力。
运行时集成。构建返回一个 BuildArtifact 对象的数组，这些对象实现 Blob 接口，可以直接传递到 HTTP API 中，如 new Response()。运行时为 BuildArtifact 实现特殊的漂亮打印。
独立可执行文件。捆绑器可以通过 --compile 标志从 TypeScript 和 JavaScript 脚本生成独立的可执行文件。这些可执行文件是完全独立的，包括 Bun 运行时的副本。

很快，捆绑器将与Bun的HTTP服务器API（ Bun.serve ）集成，从而可以用简单的声明式API表示当前复杂的构建管道。稍后会详细介绍。
Performance
这个不会让任何人感到惊讶。作为一个运行时， Bun的代码库已经包含了快速解析和转换源代码的基础（用Zig实现）。虽然可能，但很难与现有的本机捆绑器集成，并且进程间通信所涉及的开销会损害性能。
最终，结果不言自明。在我们的基准测试（源自 esbuild 的三.js基准测试）中， Bun 比 esbuild 快 1.75 倍，比 Parcel 2 快 150 倍，比 Rollup + Terserr 快 180 倍，比 Webpack 快 220 倍。