能被JavaScript重写的都将被JavaScript重写

能被rust重写的都将被rust重写?

省流

新项目主张直接vite,rspack能够当作前史巨石项目的的一个过渡品,长期张望,farm现在阶段还不推荐运用。

rspack(Rust)

为什么要做 Rspack

咱们创建 Rspack 的原因是要处理在 ByteDance 保护构建东西时遇到的各种功能问题。由于 ByteDance 内部存在许多巨石使用,它们都具有杂乱的构建配置,出产环境构建需求消耗十几分钟,乃至超过半小时;开发环境的耗时也超过十几分钟。

咱们在 Webpack 上尝试了多种方法来优化这些巨石使用,可是作用甚微。咱们意识到在 Webpack 上的优化现已难以为继,必须要从底层改造,才干习惯咱们的需求。

比照数据

现在仅与webpack比较

webpack沦为对比单位?前端整活圈又出新品了

相关链接

【官网】Rspack

【Github】github.com/web-infra-d…

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 webpack4x vite
HMR 43ms 23ms 2ms Farm is faster: 20x webpack10x vite
onload 83ms 310ms 57ms Farm is faster: 5x vite
accessible time 936ms 586ms 124ms Farm is faster: 8x webpack5x vite

相关链接

【官网】farm-fe.github.io/

【GitHub】github.com/farm-fe/far…

Turbopack

Turbopack 建立在新的增量架构上,以提供最快的开发体会。在大型使用上,它的更新速度比 Vite 快 10 倍,比Webpack 快 700 倍。在更大的使用上,一般会比 Vite 快 20 倍。

由于 Turbopack 只打包开发所需的最少资源,因而启动时间非常快。在具有 3000 个模块的使用上,Turbopack 需求 1.8 秒即可启动,而 Vite 则需求 11.4 秒:

webpack沦为对比单位?前端整活圈又出新品了

最后

新出的两个打包东西,现在阶段rspack现已根本可用,farm可能还有一段距离,比照上次据说比webpack快700的低调了许多。数据上没有怎末华丽,重点可能便是rust重写。

rspack文档比较全,对标webpack,有可取之处。尤大原话:

webpack沦为对比单位?前端整活圈又出新品了

不难看出两个新出的东西都是处理各自公司的前史巨石项目的问题出现的产品。farm 指出vite 开发出产环境不一致,出产问题调试困难,rspack 则是前史项目包袱过重搬迁困难。

所以新项目仍是vite。

参阅

  • 字节跳动自研 Web 构建东西 Rspack 正式发布

  • 比Webpack快700倍的Turbopack,到底快在哪?

本文正在参与「金石计划」

本文首发于@阿乐去买菜,转载请署明出处