前端工资涨不上去？可能是你没掌握构建工具：关于 Webpack、Babel、esbuild、Vite、Rollup、Parcel、SWC......的那些事

每个前端都应该掌握构建工具

大概从 2019 年到现在的这三年多的时间里，构建工具几乎已经成为前端发展最快的一个部分。
构建工具，属于前端工程化领域。而前端工程化，是每一个高级前端开发人员都必须要去深入了解的内容，这也是想要拿到高薪不可避免的一个关键因素。

在我过往的工作中，接触和面试过具备 5 年+工作经验的前端开发人员要超过 200 位，有一部分人对前端工程化的理解和实践比较深刻，所以他们可以比较容易的通过一些高级别的面试。但仍然有相当多一部分人对这块知识存在很多盲区，以至于他们在职业的道路上无法走的更轻松。

前端构建，就像是通往高手之路上的一个屏障，早晚都需要迈过去。
这篇文章会介绍目前大部分关注度较高和主流的构建工具。将它们彼此的关系梳理清楚，方便你能够更好的认清楚它们，进而有针对性的去学习和使用。

转译器与打包器

首先这些构建工具的侧重点不同、作用也不一样，所以说它们并不全部都是竞争关系，相反，某些构建工具之间反而是相互依存的关系。
它们大多都在转译器和打包器之间，但是很多构建工具的能力范围都不仅仅是单纯的转译器或者打包器。
转译器很好理解，就是将一种高级编程语言转换翻译成另一种高级编程语言，比如 TypeScript 转译到 JavaScript。这个过程和汉语翻译成英语差不多。

打包器也很好理解，就是将项目中用到的各种类型的资源进行打包，比如 SASS、PNG、JSON 等，让它们能够在指定的环境中正常工作，比如浏览器或者 Node.js。

我将构建工具简单地分为两类：

• 底层 JS/TS 转译器：纯粹用于将 TypeScript/JavaScript/JSX 编译到某种特定运行环境下的底层转译器，代表有 Babel、TSC、esbuild 和 SWC 等。虽然我将它们归类为转译器，但是它们大都也支持打包的能力，比如 esbuild 就把自己定位为打包器。
• 上层打包器：它们通常不会具备转译能力，而是借助上面提到的这些转译器来实现转移能力。它们更专注于完成一些范围更广、更加具体的打包任务。代表有 Webpack、Rollup、Parcel、esbuild、Snowpack、Vite、wmr、microbundle、tsup、tsdx、tsup 等。

发展迅猛的因素：痛点

前端工程化发展这么快的原因，大概就是因为前端应用越来越复杂，对应的痛点也越来越多。每种工具其实都在某个或者某几个痛点上面下功夫，最终都是在不断解决各种痛点。
构建通常有分两种情况，本地开发时的构建和线上部署时的构建。
本地开发时构建首要追求的是速度。很多人会去吐槽 Webpack 很慢。

线上部署时构建首要追求的是体积。很多人会去吐槽 Webpack 打包体积过大。

当然还有一些和构建环境无关的其他痛点：比如说配置复杂度。很多人会自嘲自己是 Webpack 配置工程师。

因为 Webpack 和 Babel 是业内最老牌的构建工具之一，所以很多工具在一开始都会去挑战 Webpack 和 Babel。
这也就是营销学中的蹭流量，拿自己的产品和业内最强的产品做对比，从而达到提高自身价值和知名度的目的。就像各大安卓手机碰瓷苹果；各大电动车去碰瓷特斯拉一样。
esbuild 在碰瓷各大打包器。

SWC 也在碰瓷 Babel。

连现在如日中天的 Vite 也不例外。

转译器

转译器可以分为两类，一类是基于 JavaScript/TypeScript 实现的，另一类是使用其他语言实现的。

传统转译器

在转译器中，最老牌的是 babel，同样它的生态也是最好的。但是它是基于 JavaScript 实现的转译器，在性能上存在瓶颈。
tsc 是 TypeScript 的官方编译工具，它是基于 TypeScript 实现的，性能同样存在瓶颈。

其他语言实现的转译器

esbuild 和 SWC 在性能方面都很有优势，原因是它们采用了性能更好的编程语言。
esbuild 采用的是 Go 语言，所以在性能上和 Webpack 比较算是降维打击了。

SWC 采用的是 Rust 语言，性能同样和 Babel 不在一个纬度上。

我们可以看到，前端的底层的技术方向在逐渐向 Rust 和 Go 迁移。因为这两门语言在性能上存在很大的优势。

打包器

上文中有提到，打包器的使用场景有两种，分别是开发场景和部署场景。部署场景频次比较低，所以性能对这类场景来说不是最重要的。但是对开发场景非常重要，没有人愿意修改一次代码要等几分钟才能看到效果。
按照开发场景的视角出发，打包器也可以分为两类，一类是通过监听源代码变化然后重新构建项目将打包后的代码推送到浏览器的传统模式。另一类是通过浏览器的原生 module 来实现动态打包的 bundleless 模式。

传统打包器

Webpack 在现代打包器中资历最老，同样生态也最好。在目前的前端生态中，仍然有大量的项目是采用 Webpack+Babel 技术方案进行打包构建的。它会采用大量缓存技术来提高性能。
Rollup 通常用来打包第三方库，而不是应用。它比 Webpack 生成的代码更加精简。
Parcel 和 Webpack 的功能类似，但是它简化了配置，号称零配置、开箱即用。Parcel 2 的 JS 转译器部分基于 SWC 进行开发，性能有很大提升。

bundleless 打包器

Snowpack 是最早的 bundleless 打包器之一，它最大的特点就是闪电般的速度。最终部署它会使用 Webpack/Parcel 插件。但是在 2022 年 4 月，负责它的团队已经不再积极维护它了，因为他们去开发 Astro 了。
Vite 和 Snowpack 类似，也是以速度著称，打包部分使用 Rollup，所以最终部署时打包体积相比 Snowpack 会更小。由于积极维护，和很好的生态，目前 Vite 也是首选的 bundleless 解决方案。
wmr 是一个非常轻量级的打包工具，它没有任何 npm 依赖。所以它没有 Snowpack 和 Vite 成熟，但是 wmr 更适合用在 Preact 或者一些简单的项目上，因为它的作者也是 Preact 的作者。

TypeScript 打包器

除了上述的两种类型打包器以外，还有一类是专门针对 TypeScript 的打包器。
TSDX 是比较成熟的一个选项，但是它对自身的定位不是一个打包器那么简单，而是覆盖了一个 TypeScript 项目开发时所需的所有东西的零配置 CLI：Rollup、Jest、tsc、yarn、TSLint、VSCode…，有点 All in One 的感觉。有些人喜欢这一点，也有些人反对这一点。
tsup 是另一个针对 TypeScript 的打包器，它的优势也是零配置，并且底层是使用 esbuild 作为支持的。相比于 TSDX 在速度上可能会更快，功能就没有那么多了。

总结

前端构建工具虽然很多，但是它们有着唯一的目标，那就是改善开发人员体验。
目前所有的前端构建工具在最终构建产物上基本不会有太大差异，目前最大的痛点还是在于开发时的性能上，其次是配置复杂度。
由于篇幅所限，后续会针对每种工具进行单独讲解。