卷？能有搞开源打包工具的大佬们卷？

最近，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方案，不和你们卷了。

编译速度对你来说重要么？欢迎留下你的讨论。