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

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

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