浏览器兼容性与 Polyfill 技术

开发者通常在最新的浏览器上进行开发，以使用最新的 JavaScript 语法，浏览器接口，让工作更有效率，代码质量更高，更不容易过时。

而用户则可能仍然在使用旧版的浏览器。比如，某些政府教育系统仍然在使用 Windows XP，用户能安装的最新的浏览器是 Chrome 49。有些用户可能只是没有升级浏览器的习惯，导致他们的 Chrome 还是 86 版本。

为了平衡两方面，开发者通常会借助一些工具，自动转译语法，并 Polyfill 新的接口，以兼容某个特定版本的旧浏览器。通过语法分析，按需插入 core-js 中的 Polyfill 代码。而 core-js 缺少的部分，可以用 polyfill-service 补全。

ES 语法转译

Optional Chaining 这种比较新的 ES 语法在老版本浏览器无法支持，运行时会报错。

const dogName = adventurer.dog?.name;

为了兼容旧版浏览器，必须在构建过程中就将其转译成 ES5/ES3 语法。

var _adventurer$dog;
const dogName = (_adventurer$dog = adventurer.dog) === null || _adventurer$dog === void 0 ? void 0 : _adventurer$dog.name;

转译功能通常由 babel，swc，esbuild 等 JavaScript 转译工具提供。

ES 特性 Polyfill

Promise，Stream 等特性需要插入特定的 Polyfill 代码。

esbuild 无法自动分析并 Polyfill 特性，只能手动导入。而 swc 和 babel 可以自动分析源码，按需自动导入。swc 和 babel 都是基于 core-js 进行 polyfill。

浏览器特性 Polyfill

core-js 只提供 ES 特性的 Polyfill（准确的说，是浏览器和 Node.js 交集的部分）。但是浏览器除了 ES 标准外，还提供其他浏览器特有的特性，比如 ResizeObserver。这就需要一个补充方案。

方案1是手动取导入 Polyfill 代码，比如在项目中 import 'whatwg-fetch' 就可以支持 fetch() 接口。但是这对开发者而言是一个比较大的负担。

方案2是在页面中引用 polyfill.io 的脚本，服务器会根据 UA 判断需要加载哪些 Polyfill 代码。开发者也可以用 polyfill-service 自建服务器。缺点是增加了一些服务器开销，也会阻塞应用本体脚本的加载，造成一些成本提高和性能损失。

CSS 语法转译

很多 CSS 特性在未成为正式标准之前便已经被浏览器支持了。但是在这个成为标准的过程中，CSS 特性的提案可能会修改。浏览器厂商为了防止自己目前的实现与之后的正式标准冲突，会在选择器和属性名之前，加上自己的前缀，Firefox 是 -moz-，Chrome 和 Safari 是 -webkit-，而 IE 是 -ms-。

比如下面这段代码：

:fullscreen {
}

为了兼容不同的浏览器，尤其是老浏览器，需要转译成：

:-webkit-full-screen {
}
:-ms-fullscreen {
}
:fullscreen {
}

转译过程主要通过 postcss 实现。当前流行的前端应用构建工具，比如 create-react-app, vite, parcel, 都集成了 postcss。

横向对比

	babel	esbuild	swc	polyfill service	postcss
ES 语法转译	✅	✅	✅
ES 特性 Polyfill	✅		✅	✅
浏览器特性 Polyfill				✅
CSS 语法转译					✅

总结

综合来看，目前没有一种技术能够单独达成全自动的浏览器兼容性。建议使用 babel + polyfill service + postcss 之类的融合方案。

当使用一种新特性时，可以先查一下 caniuse.com 支持的浏览器版本。如果需要 Polyfill，要看自己选用的 Polyfill 方案（core-js，polyfill-service）是否支持。如果不支持，则需要手动 Polyfill 这个特性。

实践

Create React App

以 create-react-app 项目为例。首先我们需要配置项目支持的浏览器版本，让底层的 babel 和 postcss 将 JS 和 CSS 转译到目标浏览器支持的语法，并尽可能注入所需的 Polyfill 代码：

{
  "browserslist": {
    "production": [
      "chrome > 49",
      "firefox > 53",
      "ie 11"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

然后，我们需要修改 HTML 模板，注入 Polyfill.io 的脚本，以支持额外的 Polyfill 特性：

<!DOCTYPE html>
<html lang="en">
  <head>
    <script src="https://polyfill.io/v3/polyfill.min.js"></script>
  </head>
  <body>
    ...
  </body>
</html>

Vite

Vite 默认只支持 Chrome 87+，这个要求对大部分实际应用可能太过苛刻。如果要支持更早的浏览器，则必须使用 legacy 插件：

import react from '@vitejs/plugin-react';
import legacy from '@vitejs/plugin-legacy';
import { defineConfig } from 'vite';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    react(),
    legacy({
      targets: [
        "chrome > 49",
        "firefox > 53",
        "ie 11"
      ],
    }),
  ],
});

然后，我们需要修改 HTML 模板，注入 Polyfill.io 的脚本，以支持额外的 Polyfill 特性：

<!DOCTYPE html>
<html lang="en">
  <head>
    <script src="https://polyfill.io/v3/polyfill.min.js"></script>
  </head>
  <body>
    ...
  </body>
</html>

2022年 12月 5日 | 评论

前端构建工具测评

2022-04-02 更新：增加测评 JS Compiler 的测试数据

2022-03-21 更新：增加测评 Bundler 和 JS Minifier 的测试数据

前端构建工具已经形成了一个或多个复杂的生态系统。从最基础的 webpack, rollup 和 babel, esbuild, swc 等工具库，衍生出各种各样的插件，封装组合成 crate-react-app, vite, parcel, snowpack 这样通用解决方案，进而发展出 Next.js, ICE.js, UMI.js 这种特异化的行业解决方案。

这个生态中的每个部分，都有其替代品。比如 swc 可以替代 babel, rollup 可以替代 webpack。swc 确实比 babel 快得多，但是插件生态不如 babel 全面，两者互有胜负。项目的实际需求，决定了构建工具的选型。

随着前端工程越来越大，构建性能和热加载性能逐渐下降，大型项目不得不面临两个选择：

对仓库/应用进行拆分，采用微前端等复杂技术整合多个子应用。这样固然能够减少每次发布构建的时间，但是会增加开发人力开销。由于影响了项目架构，严重依赖人工，无法大批量复用到多个项目。
提升构建工具的性能，比如用 esbuild 这种原生程序替代 babel 这种 Node 程序，用 Vite 这种 Bundleless 工具替代 webpack-dev-server。相比迁移项目架构，改造构建工具的成本更低，完全可以通过迁移脚本自动化。

这篇文章会介绍和评测当前各种流行的构建工具，从底层库到完整解决方案，帮助大家选择和定制最适合自己的方案。

Bundler

Bundler 是能够通过 import/export 将很多 JavaScript 文件，打包成一个/几个文件的工具。在前端开发中，也经常会 Bundle 其他文件类型，比如 CSS/LESS/SCSS，以及图片和字体。这些部分通常是以 Bundler 插件的形式提供。因此 Bundler 通常是一个平台，可以通过插件来扩展特性。

Webpack 是最流行的 Bundler。Rollup，Parcel 则是后起之秀。以编译器见长的 esbuild 和 swc 也提供了 Bundle 能力，但是插件生态不足。

特性比较

spack 还处在实验阶段，功能缺失非常多，因此不建议在任何实际项目中使用。

esbuild 稍好一些，如果你不需要 CSS Modules，不用代码分割，不需要支持 IE，也不需要输出 UMD，那么 esbuild 是可以满足你的需求的。对于个人项目来说，这完全是可行的。对于企业项目，esbuild 作为 bundler 显然还不够全面，但它作为编译器和 Rollup 配合使用还是很好用的。

parcel，rollup 和 webpack 是功能最为全面的，能够应对绝大多数前端项目需求。webpack 的插件生态最丰富，兼容性也最好。rollup 和 parcel 则更加轻量化。Parcel 的 UMD 打包格式缺失，不适合用于组件库或微前端构建，但是对普通应用还是够用的。

	webpack	rollup	parcel	esbuild	spack
CSS Modules	✔️	✔️	✔️	✔️	❌
LESS	✔️	✔️	✔️	✔️	❌
Sass	✔️	✔️	✔️	✔️	❌
代码分割	✔️	✔️	✔️	❌	❌
CJS 输出格式	✔️	✔️	✔️	✔️	✔️
ESM 输出格式	✔️	✔️	✔️	✔️	✔️
UMD 输出格式	✔️	✔️	❌	❌	❌

性能比较

测试打包 antd + lodash + react + react-dom + three.js 的速度。为了控制变量，统一采用 esbuild 作为 minifier（spack 不支持除外）。

详细测试数据见 https://github.com/guoyunhe/benchmark-bundlers

	webpack	rollup	parcel	esbuild	spack
ThinkPad T480	5.347s	14.548s	6.069s	0.249s	1.082s
MacBook 16, 2019	4.229s	12.790s	5.225s	0.227s	1.012s

esbuild 是用 Go 语言编写，spack（swcpack）是用 Rust 语言编写。两者都编译成二进制文件运行，速度比其他 JS 编写的 Bundler 快几十倍。从 20s 到 0.2s 已经是一个质的飞跃了。

相比之下，传统的 JS Bundler 就慢得多了。令人意外的是，被很多人认为过时了的 webpack 居然比 parcel 和 rollup 更快。尤其是 rollup 的性能，令人意外地差。我们分析是因为 lodash 和 react 都是 CJS 模块，rollup 需要将其转化成 ESM 才能使用，因此比 webpack 慢了一倍多。

综合评价

目前 webpack 仍然是最全面的 Bundler 选择，支持特性最丰富，生态最为庞大。而且它的性能并不差，在应用打包场景要优于 rollup 和 parcel。

而放眼未来，esbuild 的潜力最大。它的性能无与伦比，且具有成熟的插件接口。它的代码分割能力已经在测试中，前途一片光明。甚至 Vite 也希望在 esbuild 成熟之后，移除 rollup 而直接用 esbuild 打包。

JS Minifier

Production 构建需要对 JS 文件和 CSS 文件进行 Minify 处理，让生成的文件更小，加载更快。JS 的 Minifier 包括 terser，esbuild，swc。衡量它们优劣的主要指标是速度和压缩率。

以下测试用 webpack + terser/esbuild/swc 打包和压缩 antd + lodash + react + react-dom+three.js。详情见 https://github.com/guoyunhe/benchmark-js-minifiers

	no-minify	terser	esbuild	swc
产物尺寸	4.7MB	1.8MB	1.9MB	1.9MB
运行时间 ThinkPad T480	4.677s	17.046s	5.615s	8.997s
运行时间 MacBook 16, 2019	3.556s	13.834s	4.052s	6.892s

esbuild 和 swc 在速度上大幅度领先 terser。对于这类高计算量任务，Node.js 的性能比原生程序差得多。同为原生程序，esbuild 比 swc 的性能更好，说明它的设计更优秀。而从压缩率上来看，terser 略好于 esbuild 和 swc 但差距不大。因此综合来看，我认为 esbuild 是最佳的 minifier。

JS/TS Compiler

我们在开发中喜欢使用最新的 ES 语法，但在发布时需要兼容旧的浏览器。JSX 和 Vue 文件还包含了特殊语法，即使最新的浏览器也无法识别和运行。因此越来越多的前端项目需要用 JS Compiler 或者叫 Transpiler 来转换源码。这也是一项非常耗时的任务。目前最广泛使用的编译器是 babel，它功能全面，但性能堪忧。而 esbuild 和 swc 则是以速度见长的面向未来的编译器。TypeScript 有自己的编译器 tsc，支持 TypeScript 的类型系统检查，但是它的效率极差。因此 Babel, esbuild 和 swc 都提供了自己对 TypeScript 转译的支持。

特性比较

从特性上来看，babel 仍然是最全面的。esbuild 和 swc 则注重对最新 ES 标准的支持，因此少了对非标准的 JS 修饰器语法（但是支持 TS 修饰器语法）和 Flow 语言的支持。esbuild 不兼容 ES5 和 IE 浏览器，但某些项目仍然有这方面的需求，开发者需要平衡利弊。

	babel	esbuild	swc
ES Next	✅	✅	✅
ES5, IE11	✅	❌	✅
JS 修饰器语法	✅	❌	❌
Flow 语言	✅	❌	❌
TypeScript 语言	✅	✅	✅
TS 修饰器语法	✅	✅	✅
JSX	✅	✅	✅

性能比较

以下测试用 Webpack + babel-loader/swc-loader/esbuild-loader 转译 antd + three.js 源码到 ES5 语法，不进行 minify。详见

	babel	esbuild	swc
运行时间 ThinkPad T480	10.133s	0.464s	0.549s
运行时间 MacBook 16, 2019

综合评价

如果不需要支持 IE11，那么 esbuild 是最好的选择，它的性能非常好。

如果需要支持 IE11，那么推荐 swc，性能接近 esbuild 且浏览器兼容性更好。

只有当 esbuild 和 swc 都无法支持你的项目需求时（比如用到了 JS 修饰器语法），再考虑 babel。babel 虽然功能最为全面，但性能比 esbuild 和 swc 慢几十倍，已经无法支持大型项目了。

Dev Servers

Webpack Dev Server

Webpack Dev Server 的出现，极大提升了 React 应用开发的效率：修改代码时，组件会自动被替换，无需手动刷新，也不会重新加载页面。然而早期的 Webpack 和 Webpack Dev Server 每次修改文件都会重新编译打包，给人越来越慢，又无能为力的痛苦感受。Webpack 5 和 Webpack Dev Server 4 已经在性能方面有了极大的改善。中小型项目的瓶颈大多不是 Webpack 本身造成，而是上面介绍过的 Compiler 和 Minifier。如果结合 swc 和 esbuild，Webpack Dev Server 仍然很能打。

但是在大型应用场景，Webpack Dev Server 还是有不足的。想象一下，你有一个包含几万行代码的 SPA 应用，且没有做代码分割。Webpack Dev Server 会将所有代码编译打包之后才能启动。这样一来，启动速度就会变得很慢。但实际上，我们每次只开发项目中很小的一部分，余下的页面/弹窗等组件并不需要提前编译加载。

但是这也并不是我们一定要抛弃 Webpack Dev Server 理由。大型应用场景，也极少硬着头皮上 SPA，而是用微前端框架将应用做进一步的切分。开发时 Webpack Dev Server 只需要运行子应用即可。

但是如果我们就是要做巨石 SPA 应用呢？在本地开发场景下，可以利用浏览器原生的 ES Module 能力动态地按需加载模块，而不需要编译打包所有内容。这样是不是就可以解决我们上面遇到的那个问题了呢？理论上行得通，但实际效果不尽如人意。

Snowpack

Snowpack 就是这样一个设计。理论上动态加载本地 JS 文件几乎没有延迟。但是这些模块并不都能直接在浏览器中运行。比如有很多 NPM 依赖是 CJS 而非 ESM 模块，我们写的代码有 JSX 和 TypeScript，更不要说还有 Sass，LESS，CSS Modules 这些要处理。因此动态加载每个文件时，都有一定的等待时间，而且无法并行处理。结果是在冷启动过程奇慢。在中小型项目开发中，不及 Webpack Dev Server 有效率。大型项目。而且，它并不能构建部署生产环境，仍然需要使用 Webpack 或 Rollup 来补足，无疑增加了项目维护成本。

因此在实际项目中，很难看到 Snowpack 的身影。Snowpack 本身的开发也陷入了很长时间的停滞不前。不过，Snowpack 的思路被 Vite 和 Parcel 2 所继承并改进，取得了成功。

Vite

Vite 给出了更好的答案：将依赖模块预先用 esbuild 进行 Bundle 以快速加载，项目模块采用 Unbundle 模式动态编译加载。

但是，Vite 对不同前端框架的支持程度是不同的，实际运行效率也差别很大。它的 Vue 插件用 esbuild 编译，速度极快。而它的 React 插件用的是 Babel 编译，速度一般。

另外我们发现，Vite 的缓存校验机制存在比较大的问题。更新 node_modules 中的依赖之后，Vite 缓存并没有更新。在开发过程中只能禁用缓存，这导致开发效率进一步降低。

Parcel 2

Parcel 2 和 Vite 的思路类似，但是有两个重要改进：

缓存范围更广，效率极高，热启动在 1s 内
采用了 swc 而非 babel 编译，构建和刷新速度更快

这两个优势使得 Parcel 2 在几乎各个性能指标上都领先于其他竞争对手。

性能比较

TODO

2022年 1月 24日 | 评论