最近，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 计划，不和你们卷了。
编译速度 对你来说重要么？欢送留下你的探讨。