打包

目前前端世界主流的前 3 名模块打包器仍然是Webpack、Rollup和Esbuild。

(相关资料图)

Webpack

本质上，Webpack 是一个用于现代 JavaScript 应用程序的静态模块打包工具。当 Webpack 处理应用程序时，它会在内部从一个或多个入口点构建一个依赖图(dependency graph)，然后将你项目中所需的每一个模块组合成一个或多个 bundles，它们均为静态资源，用于展示你的内容。

使用如下命令来安装：webpacknpm install webpack -g

安装完后，可以输入webpack -v命令查看是否安装成功。

文档：https://webpack.docschina.org/concepts/

Esbuild

Esbuild 是一个用 Go 编写的模块打包工具。因为它大量利用了 Go 中并行的特性，所以 Esbuild 非常快。

Esbuild 内部的算法经过精心设计，在可能的情况下它将饱和使用所有可用的 CPU 内核Esbuild 中的所有功能在开始编写时就充分考虑了性能

文档：https://esbuild.github.io/

Rollup

Rollup 是一个 JavaScript 模块打包工具，可以将多个小的代码片段编译为完整的库和应用。与传统的 CommonJS 和 AMD 这一类非标准化的解决方案不同，Rollup 使用的是ES6版本 Javascript 中的模块标准。

与 Webpack 相比快速且轻量级支持 Tree Shaking

文档：https://www.rollupjs.com/

Parcel

Parcel 是一个众所周知的零配置 Web 应用程序打包器。

默认启用 Tree Shaking使用 Rust 编写的 Javascript 编译器，以利用并行性并提高性能支持原生 ES Moduls 和 CommonJS 两种模块标准自动代码拆分

文档：https://parceljs.org/docs/

Turbopack

Turbopack建立在 Turbo 之上：Turbo 是一种用于Rust的开源增量记忆框架。Turbo 可以缓存程序中任何函数的结果。当程序被执行多次时，函数不会重新运行，除非它们的输入发生变化。

这种方法使 Turbopack 在计算增量更新方面非常快。这也优化了 Turbopack 使得开发过程中增量更新非常快，确保 dev server 能够快速响应代码变更。

Turbopack 还使用请求级编译方法来只编译请求的代码。如果浏览器请求某些 CSS，则只会编译该 CSS，而不编译引用的 images。采用请求级编译有助于减少请求数量并能够快速编译它们。

目前，Turbopack 比现有打包工具快 10 倍～700 倍。但它目前只可以在 Next.js v13 中使用。未来计划发布独立的 CLI、插件 API，并支持 Svelte 和 Vue 等其他框架。

文档：https://turbo.build/pack/docs

Nobundle：Vitejs

Vite 通过在一开始将应用中的模块区分为依赖和源码两类，改进了开发服务的启动时间。

依赖大多为在开发时不会变动的纯 JavaScript。一些较大的依赖（例如有上百个模块的组件库）处理的代价也很高。依赖也通常会存在多种模块化格式（例如 ESM 或者 CommonJS）。Vite 将会使用 esbuild (https://esbuild.github.io/) 预构建依赖(https://cn.vitejs.dev/guide/dep-pre-bundling.html)。源码通常包含一些并非直接是 JavaScript 的文件，需要转换（例如 JSX，CSS 或者 Vue/Svelte 组件），时常会被编辑。同时并不是所有的源码都需要同时被加载（例如基于路由拆分的代码模块）。Vite 以 原生 ESM (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) 方式提供源码。这实际上是让浏览器接管了打包程序的部分工作：Vite 只需要在浏览器请求源码时进行转换并按需提供源码。根据情景动态导入代码，即只在当前屏幕上实际使用时才会被处理。

对于生产环境，Vitejs 使用 Rollup 进行打包。

文档：https://vitejs.cn/

编译工具

编译工具（Compiler）可以理解为将一种语言编写的源代码转换为另一种语言的过程。在前端开发过程中，我们经常遇到如下两类编译场景：

将 TS 转换为 JS；将新版本 JS 语法转换为低版本浏览器支持的语法；

当前前端界的编译工具，如下四个占据了大部分市场：

名称	描述	Star	底层语言
Babel (https://babeljs.io/)	JS 编译器，用于将新版本 JS 语法转换为向后兼容的 JS 语法。也可以通过插件(https://babeljs.io/docs/en/babel-plugin-transform-typescript)支持 TS 语法编译，但不支持类型检查。	41.8K	JS
TSC (https://www.typescriptlang.org/)	TS 官方编译器，用于将 TS 编译成 JS。同时也支持旧版本语法转换，但不能自动 polyfill。	87.5K	TS
SWC (https://swc.rs/)	新一代 JS 编译器，特点是速度非常快，宣称单核下比 Bable 快 20 倍。支持 TS 编译，但不会做类型检查。	25.5K	Rust
esbuild (https://esbuild.github.io/)	一款超级快且融合编译&打包的工具，宣称比现在生态（说的就是你：webpack + babel）快10-100倍。支持 JS/TS，编译 TS 不会做类型检查。	34.3K	Go

Babel

最早开始出现JS编译工具之一，也是目前使用最多的 JS 编译工具。随着 Babel 的出现，前端开发者可以直接编写现代 JS 代码，同时又不失去对旧浏览器的支持。

简单来说，Babel 是一个工具链，主要用于将 ECMAScript 2015+ 版本的代码转换为向后兼容的 JavaScript 语法，以便能够运行在当前和旧版本的浏览器或其他环境中。Babel 可以做如下事情：

语法转换，比如 const、let、?.、箭头函数等最新 ES API 和 ES 实例/静态方法的 Polyfill，如 Promise、Array.prototype.includes等。这部分主要通过第三方库来 polyfill，如 core-js (https://github.com/zloirock/core-js)源码转换（codemods）

Babel 官方提供一个 在线编译网站(https://babeljs.io/repl)，大家可以使用它便捷的体验 Babel 的编译效果。

Babel 构建在插件之上，默认情况下，Babel 不做任何处理，需要借助插件来完成语法的解析、转换、输出。

TSC

TSC（TypeScript Compiler） 是 TS 语言官方的编译器，最初 TS 语言只能使用 TSC 进行编译，随着 Babel 等工具也相继支持编译 TS，你可能有疑问，他们之间有什么区别吗？答案是有的， 相对于 Babel，TSC 有如下 优势：

可以进行类型检查；可以识别所有的类型并生成 .d.ts 类型文件；

原因在于 Babel 是单个文件编译的，不会解析其他文件的信息，而 TSC 的类型检查需要拿到整个工程的类型信息，需要做类型的引入、多文件 namespace 的合并等。而 Babel 编译 TS 只是去掉类型声明，保留原有 JS 功能。

通过配置 target也可以让 TSC 编译出低版本浏览器支持的代码，但存在一些 缺点：

对一些新语法缺乏支持，如提案阶段的语法；对于ESAPI和 ES 实例/静态方法无法解析，需要单独添加polyfill；

综上，现在的前端 TS 项目一般还是会使用 Babel 做编译，使用 TSC 做类型检查。

Babel for transpiling, TSC for types ：

(https://www.typescriptlang.org/docs/handbook/babel-with-typescript.html#handbook-content)

SWC

一款基于 Rust 语言开发的编译工具，它相对于 Babel 的优势就是编译速度非常快，在它的官网上，写着如下一句话。

SWC is 20x faster thanBabelon a single thread and 70x fasteron four cores.

SWC 的成功得益于 Rust 语言，这是一门高效、性能更好且内存安全的语言。随着 SWC 的崛起，很快它就被 Next.js 采用，进而取代 Babel 作为 JS 编译工具。

优缺点：

SWC 最大的优势就是编译速度快，另外在可扩展性、WASM 支持、社区和生态系统方面也是做的非常不错的。

但是，如果从 Babel 切换到 SWC，也有一些问题需要考量：

相对于Babel，SWC的编译支持上有一些区别，参考 官方列表 (https://swc.rs/docs/migrating-from-babel) 可能会导致代码的浏览器支持度降低SWC 也有插件系统，但仍是实验性的，且开发插件要学习 Rust 和 WebAssembly，上手门槛明显很高

SWC并不满足只是一个编译工具，未来或将支持如下能力：

编译工具，替代 Babel打包器，替代 Webpack，目前正在建设中：swcpack (https://swc.rs/docs/usage/bundling)类型检查器，替代 TSC压缩器，替代 Terser

esbuild

esbuild 更多是作为打包工具被大众熟知，我们在打包工具章节也做了介绍。

其实 esbuild 也是支持编译能力的，且速度要比 Babel 快很多，但是它不兼容低版本浏览器，产物无法降级到 ES6 以下。esbuild 也原生支持编译 TS 语言，同样不支持类型检查，遗憾的是官方也没有计划去做这件事。

优化技术

1、LightHouse

通过LightHouse获取页面FCP (First Contentful Paint)和Speed Index指标，首屏加载FCP要尽量减少白页，Speed Index越快越好（最多4s内）2、Frame Rate

通过Frame Rate 工具检测页面FPS，遇到轮播图动画等页面交互时应该尽量保证fps流畅，防止用户观看时出现卡顿闪烁等视觉体验3、NetWork

通过瀑布图NetWork，直观的看到接口的响应速度，尽量缩短响应的速度，同时也能看到一个页面的接口请求数，减少同时并发的请求，把不重要的请求往后排序，来提升性能4、Performance

通过Performance监听主线程性能，尽量减少DOM加载时间

参考：https://blog.csdn.net/m0_68324632/article/details/127487822

5、Tree Shaking

摇树优化Tree Shaking是Webpack里非常重要的优化措施，它的优化效果在Webpack 5中又得到了进一步的提升。Tree Shaking可以帮我们检测模块中没有使用到的代码块，并在Webpack打包时将没有用到的代码块移除掉，减小打包后的资源体积大小。它的名字也非常形象，通过摇晃树把树上干枯无用的叶子摇掉。

参考：https://zhuanlan.zhihu.com/p/467104092

标签：