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

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

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