序
能被 JavaScript 重写的都将被 JavaScript 重写
能被 rust 重写的都将被 rust 重写？
省流
新我的项目倡议间接 vite，rspack 能够当作历史巨石我的项目的的一个过渡品，长期张望，farm 目前阶段还不举荐应用。
rspack（Rust）
为什么要做 Rspack
咱们创立 Rspack 的起因是要解决在 ByteDance 保护构建工具时遇到的各种性能问题。因为 ByteDance 外部存在许多巨石利用，它们都具备简单的构建配置，生产环境构建须要消耗十几分钟，甚至超过半小时；开发环境的耗时也超过十几分钟。
咱们在 Webpack 上尝试了多种办法来优化这些巨石利用，然而成果甚微。咱们意识到在 Webpack 上的优化曾经难以为继，必须要从底层革新，能力适应咱们的需要。
比照数据
目前仅与 webpack 比拟
相干链接
【官网】Rspack
【Github】https://github.com/web-infra-dev/rspack
Farm（Rust）
阿里系，很低调根本没宣传, 我的项目还在很晚期阶段
文档仅英文，很多内容没有，处于不可用状态，玩玩还行
Why Farm?
As the web project scales, building performance has been the major bottleneck, for a huge project, compiling with webpack may cost 10min or more, a hmr update may cost 10s or more, heavily reduced the efficiency.
Then some tools like vite comes out, it uses native ESM and is unbundled for source files in dev mode, pre-bundle dependencies using esbuild, which makes the dev server launch and the HMR very fast.
But Unbundled is not perfect, there are still big problem when comes for a large project:
- The huge numbers of module requests: For a large project, there may be thousands of modules that should be loaded, using native module system to load thousands of modules will make the browser get stuck or even crashed.
- Inconsistency between Dev and Production: Native module can not be used in production for most situations, For the compatibility and request numbers. So Unbundled tools choose to bundle in production. This brings inconsistency, when there are production bugs caused by this inconsistency, it’s really hard to debug and really painful. And vite is using esbuild in dev and using rollup in production, which enlarged the inconsistency.
- And Vite is so fast in dev because of esbuild, which is written in go. Go takes advantages of native platform and much faster than Js.
So I thing we just need a fast, powerful, consistent web bundler, which can solve the problems above and fast, then I designed Farm.
And Farm is not just a normal bundler re-written in Rust, it has a lot of powerful and progressive designs:
比照数据
性能晋升很无限
| Webpack | Vite | Farm | Compare | |
|---|---|---|---|---|
| cold start | 853ms | 276ms | 67ms | Farm is faster: 12x webpack，4x vite |
| HMR | 43ms | 23ms | 2ms | Farm is faster: 20x webpack，10x vite |
| onload | 83ms | 310ms | 57ms | Farm is faster: 5x vite |
| accessible time | 936ms | 586ms | 124ms | Farm is faster: 8x webpack，5x vite |
相干链接
【官网】https://farm-fe.github.io/
【GitHub】https://github.com/farm-fe/farm?version=2.5.50001.11&platform=win
Turbopack
Turbopack 建设在新的增量架构上，以提供最快的开发体验。在大型利用上，它的更新速度比 Vite 快 10 倍，比 Webpack 快 700 倍。在更大的利用上，通常会比 Vite 快 20 倍。
因为 Turbopack 只打包开发所需的起码资源，因而启动工夫十分快。在具备 3000 个模块的利用上，Turbopack 须要 1.8 秒即可启动，而 Vite 则须要 11.4 秒：
最初
新出的两个打包工具，目前阶段 rspack 曾经根本可用，farm 可能还有一段距离，比照上次据说比 webpack 快 700 的低调了很多。数据上没有怎末富丽，重点可能就是 rust 重写。
rspack 文档比拟全，对标 webpack，有可取之处。尤大原话：
不能看出两个新出的工具都是解决各置公司的历史巨石我的项目的问题呈现的产物。farm 指出 vite 开发生产环境不统一，生产问题调试艰难，rspack 则是历史我的项目包袱过重迁徙艰难。
所以新我的项目还是 vite。🤔
参考
- 字节跳动自研 Web 构建工具 Rspack 正式公布
- 比 Webpack 快 700 倍的 Turbopack，到底快在哪？
本文首发于 @阿乐去买菜，转载请署明出处