共计 1171 个字符,预计需要花费 3 分钟才能阅读完成。
最近,Parcel2
公布 beta3
版本。
该版本最大的更新是:替换底层所用的 JS
编译器,从 Babel
替换为SWC
,使整体编译速度较之前快了 10x 倍。
SWC
是用Rust
写的JS
编译器,指标是代替Babel
。他的作者是 97 年生的강동윤,他写swc
时上大二。
被速度所累的 parcel
为了与打包工具老大哥 Webpack
差异化竞争,Parcel
将 零配置 作为他的卖点(对标 Webpack
繁琐的配置)
其中,高级 ES
语法会依据开发者提供的 browserslist
指标版本降级为对应 ES5
语法。
非标准语法,相似 JSX
、TS
,开发环境个性,相似React Fast Refresh
都是开箱即用的。
这所有的实现,都建设在基于 Babel
的JS 编译器 上。
而 JS
相比 Rust
语言层面的速度劣势,是 Babel
再怎么优化也无法弥补的。
于是,便有了开篇提到的替换 JS
编译器。
Parcel
团队示意,SWC
比Babel
快 20x 倍
值得玩味的是,在提供 benchmark
秀性能时,Parcel
应用了 esbuild
的benchmark
。
esbuild
应用 10 份threeJS
的生产包,比照不同打包工具在默认配置下的打包速度作为benchmark
速度之卷
esbuild
是一个用 Go
写的 JS
打包工具,于 2020 年 1 月开源。他的作者是 Figma
的CTO
Evan Wallace。
一经开源,没有任何花里胡哨的新性能,上来就是硬刚编译速度。
成绩斐然:
能够看到 Parecel2
倒数第三。
而老大哥 Webpack5
之所以没有倒数第一,是因为倒数第一是Webpack4
。
Evan随后又更新了benchmark
:
尽管 Parcel
的劣势是:极简、零配置。但被这么拉进去比速度,后果还如此惨烈。
想必 Parcel
团队成员心里是极度憋屈的。
于是,兄弟们,其余事件先放一放,让咱们一起卷编译速度!
通过几个月开发,终于有了开篇提到的 beta3
。而且必须用你esbuild
的benchmark
跑一遍,找回场子!
JS 打包工具的降维打击
事实上,在 Webpack
曾经倒退多年的明天,可能突出 Webpack
重围,占有一席之地的打包工具,都走着差异化竞争的路线。
在 Google
工程师 Surma 和其他人一起开发的打包工具评估网站 tooling.report 上能够看到:
Webpack
是反对性能最全面的。其余支流打包工具则各有偏重。
剧本的走向本应是:
Webpack
持续走他 六边形兵士 的路线
其余打包工具各自安好,走差异化路线。
然而,esbuild
的异军突起,对这些工具造成了降维打击。
编译速度 在开发时的确是刚需。
Parcel
不是第一个,也绝不是最初一个作出扭转的工具。
聪慧的 Vite
有人拥抱变动,有人被迫承受变动。
Vite
则说:卷 bundle
速度?那我在开发时采纳 No-Bundle
计划,不和你们卷了。
编译速度 对你来说重要么?欢送留下你的探讨。