关于前端:卷能有搞开源打包工具的大佬们卷

40次阅读

共计 1171 个字符,预计需要花费 3 分钟才能阅读完成。

最近,Parcel2公布 beta3 版本。

该版本最大的更新是:替换底层所用的 JS 编译器,从 Babel 替换为SWC,使整体编译速度较之前快了 10x 倍。

SWC是用 Rust 写的 JS 编译器,指标是代替 Babel。他的作者是 97 年生的강동윤,他写swc 时上大二。

被速度所累的 parcel

为了与打包工具老大哥 Webpack 差异化竞争,Parcel 零配置 作为他的卖点(对标 Webpack 繁琐的配置)

其中,高级 ES 语法会依据开发者提供的 browserslist 指标版本降级为对应 ES5 语法。

非标准语法,相似 JSXTS,开发环境个性,相似React Fast Refresh 都是开箱即用的。

这所有的实现,都建设在基于 BabelJS 编译器 上。

JS 相比 Rust 语言层面的速度劣势,是 Babel 再怎么优化也无法弥补的。

于是,便有了开篇提到的替换 JS 编译器。

Parcel团队示意,SWCBabel 快 20x 倍

值得玩味的是,在提供 benchmark 秀性能时,Parcel应用了 esbuildbenchmark

esbuild应用 10 份 threeJS 的生产包,比照不同打包工具在默认配置下的打包速度作为benchmark

速度之卷

esbuild是一个用 Go 写的 JS 打包工具,于 2020 年 1 月开源。他的作者是 FigmaCTO Evan Wallace

一经开源,没有任何花里胡哨的新性能,上来就是硬刚编译速度。

成绩斐然:

能够看到 Parecel2 倒数第三。

而老大哥 Webpack5 之所以没有倒数第一,是因为倒数第一是Webpack4

Evan随后又更新了benchmark

尽管 Parcel 的劣势是:极简、零配置。但被这么拉进去比速度,后果还如此惨烈。

想必 Parcel 团队成员心里是极度憋屈的。

于是,兄弟们,其余事件先放一放,让咱们一起卷编译速度!

通过几个月开发,终于有了开篇提到的 beta3。而且必须用你esbuildbenchmark跑一遍,找回场子!

JS 打包工具的降维打击

事实上,在 Webpack 曾经倒退多年的明天,可能突出 Webpack 重围,占有一席之地的打包工具,都走着差异化竞争的路线。

Google 工程师 Surma 和其他人一起开发的打包工具评估网站 tooling.report 上能够看到:

Webpack是反对性能最全面的。其余支流打包工具则各有偏重。

剧本的走向本应是:

Webpack持续走他 六边形兵士 的路线

其余打包工具各自安好,走差异化路线。

然而,esbuild的异军突起,对这些工具造成了降维打击。

编译速度 在开发时的确是刚需。

Parcel不是第一个,也绝不是最初一个作出扭转的工具。

聪慧的 Vite

有人拥抱变动,有人被迫承受变动。

Vite则说:卷 bundle 速度?那我在开发时采纳 No-Bundle 计划,不和你们卷了。

编译速度 对你来说重要么?欢送留下你的探讨。

正文完
 0