鹤仙人

前端构建工具 2023

标准

这里定义的前端构建工具需要符合以下条件：

  • 能够构建生产用的前端资源。
  • 提供带 HMR 的 Dev Server。
  • 支持常见的前端技术，比如 Sass, LESS, CSS modules, code splitting。
  • 支持插件扩展。
  • 不限于某种 UI 框架，不捆绑不必要的运行时内容，比如 Redux。（排除 UMI 之类的深度定制框架）

生产可用

这里定义的生产可用条件：

  • 流行度高。(npm 周下载量 >100k)
  • 维护活跃。(六个月内至少发布了一个版本。)
  • 没有严重的性能或兼容性问题。

Vite 4

Vite 基于 esbuild (用 Go 语言编写) 和 Rollup。它采用了 Unbundled Dev Server 模式，通过浏览器原生 ESM 特性，省去了 Bundle 步骤，以达到比 Webpack Dev Server 更快的 HMR 和启动速度。Vite 4 提供了一个新的基于 SWC 的 React 插件 @vitejs/plugin-react-swc ，用于替换旧的基于 Babel 的插件。这让 React Fast Refresh 的速度快了 20 倍。目前，Vite 仍然是速度最快的前端构建解决方案之一。

Vite 易于使用。即使不进行任何配置，也能开始使用。如果需要定制，它的文档也非常详细好用。Vite 兼容 Rollup 插件和配置接口，甚至可以借用 Rollup 的文档。用户更容易找到需要的插件，遇到问题也更容易找到解决方案。编写 Vite 插件也相对容易。所以 Vite 的社群和生态系统成长很快。Vite 的 JS API 设计简单清晰，功能丰富。基于 Vite 开发你自己的构建工具很容易。

Parcel 2

Parcel 2 基于一系列用 Rust 重写的高性能模块，比如 SWC 和 Parcel CSS，实现了优于 Webpack 的性能。默认配置下，Parcel 2 的性能介于 Vite 4 和 Webpack 5 之间。但是可以通过启用一些实验性功能提升性能，比如 swc 压缩。

Parcel 2 的另外一个特点是开箱即用。它的默认配置已经涵盖了 TypeScript，CSS modules，JSX，React Fast Refresh，图片压缩，SVG 优化等特性支持。另外，当检测到 Sass 或 LESS 时，Parcel 2 会自动帮你安装需要的依赖包。对于常规的前端应用，你完全不需要配置文件。

Parcel 有自己独特的架构和接口设计，这让它几乎不可能直接借用 Webpack 和 Rollup 的插件。因此它的生态系统中第三方插件很少。另外，由于 Parcel 发布大版本的频率很低，内置插件为了避免 Breaking Change 而很难升级，比如 MDX 2.0 至今没有被支持。这可能是 Parcel 2 最大的劣势。

Webpack 5

Webpack 依然是最流行的选择，有最完善的特性，以及最大的生态系统。

Webpack 很慢，但是你可以用一些 loader 和插件替换默认组件来提速：

观察列表

一些还处于早期阶段的有潜力项目。

Rspack

用 Rust 写的 Webpack 替代品，由字节跳动创建。虽然还处于早期阶段，但是已经表现出比 Vite 更快的构建速度。同时兼容 Webpack 插件，可扩展性很强。

未入选

Turbopack

为 Next.js 框架设计的高性能构建工具，原生支持 SSR。未入选原因是因为目前只能用于 Next.js 框架。

UMI

蚂蚁集团的构建工具。未入选原因是因为过度定制化，只支持 React，内置了过多 Redux 之类的运行时。

ICE

阿里巴巴的构建工具。未入选原因是因为过度定制化，只支持 React，内置了过多 Redux 之类的运行时。

Create React App

React 官方的构建工具。未入选的原因是因为过度定制化，只支持 React，不支持配置和插件。

性能测试

dev server cold startdev server warm startproduction build
rspack 0.1.12.2s2.0s1.4s
vite 4.2.14.3s1.3s6.5s
parcel 2.8.313.0s1.3s15.7s
webpack 5.76.214.2s14.2s15.8s

详情参见 https://github.com/guoyunhe/front-end-builder-benchmark

技术趋势

一些可能会让前端构建工具更快更好的技术。

原生 Node.js 模块与 WASM 模块

用 Rust，Go 等语言编写的 Node.js 模块，其性能与产物格式有很大的关系。不考虑多线程的情况，从高到低分别是 Native > WASM > JS。JS 和 WASM 本身都是单线程的，除非使用 Cluster 模式（目前还没有在前端构建工具上比较成功的）。支持多线程的 Native 模块，性能会更强，esbuild 就是一个例子。

但是，原生模块必须为不同的平台预编译对应的二进制文件，不如 WASM 或 JS 的“一次编译，到处运行”方便。

在实践中，原生模块通常用于核心高负载模块，比如 rspack，swc，esbuild。而插件还是广泛采用 JS。WASM 仍然比较少见，一个例子是 swc 的插件开发。

从 Unbundled 回到 Bundled？

用 JS 写的 Webpack Dev Server 采用 Bundled 模式启动。即先由 Webpack 将多个源码文件打包成一个，再传输给浏览器。在浏览器的网络记录中，你只会看到几个网络请求。因为 Webpack 打包的效率低，启动速度很慢，热加载也很慢。

后来出来了 Snowpack （已废弃），可能是第一个 Unbundled 模式的 Dev Server。采用 Unbundled 模式启动 Dev Server，通过原生 ESM 加载，省去了 Bundle 的过程，提高了启动速度。当 Dev Server 启动时，不会进行编译，而是在接到浏览器请求时，动态编译每个文件，每次传输一个源文件对应的代码。过程大致是：

请求 → 编译 → 响应 → 请求 → 编译 → 响应 → … → 请求 → 编译 → 响应

这导致 Snowpack 的启动速度极其缓慢，对比 Webpack Dev Server 并没有显著优势。

后来 Vite 继承并改进了 Snowpack 的思路。它将 node_modules 中大量的依赖用 esbuild 先 Bundle 成单个文件，而项目源码依旧采用 Unbundled 模式。得益于 esbuild 的强大性能，不管是依赖的 Bundle，还是单个源码文件的转译，都非常快。因此 Vite 对比 Webpack Dev Server 取得了巨大的性能优势。

然而，随着项目体积增大，需要加载的 ESM 模块越来越多，Vite 的启动速度会变慢。假设项目的 src 中有 1000 个 JS/TS 文件，就会有 1000 个 HTTP 请求。现代的浏览器只允许每个服务器建立 6 个连接，也就是说最多只能并发 6 个 HTTP 请求，导致阻塞。

因此 Parcel 2，Turbopack 和 Rspack 选择了回到 Webpack Dev Server 的 Bundled 模式，通过用 Rust 重写关键部件，改进打包和编译性能来提高性能。

但是根据 Turbopack 的 Benchmark，只有在 src 中有 1000 个以上的 React 组件时，Turbopack 对比 Vite 才会有比较明显的优势。但实际应用中，1000 个组件（约100K到1M行代码）已经是相当大规模的应用了。而 Vite 的冷启动速度仍然可以接受：4.2s。另外，我觉得这个 Benchmark 用 Turobopack 的 Server Side Rendering 对比 Vite 的 Client Side Rendering，并不公平，因为 Vite 也是支持 Server Side Rendering 的。

总结一下，我觉得 Vite 的 Unbundled 策略和 Parcel 等的 Bundled 策略各有所长，在实际应用中并不能拉开明显的性能差距，未来很长一段时间仍然会共存，而不是此消彼长。

更快的 Sass 编译器

Sass 的老编译器 node-sass 已经被官方废弃，不再维护。新的官方编译器 Dart Sass 令人迷惑：

  • 原生构建二进制程序没有 Node.js 接口，无法集成到现有的 Node.js 工具中。除非你用 Node.js 的 exec 函数执行。(不推荐在生产中这样做)
  • JavaScript 构建要比 node-sass 慢 4 到 30 倍 (取决于项目大小)。如果你的构建工具调用 Sass 接口的方式不正确，速度甚至会更慢。详见 Issue #1557 和 #1534。

对于大量使用 Sass 的生产项目，这肯定是不可接受的。很多项目选择继续使用废弃的 node-sass 编译器。

现在已经有人在开发用 Rust 重写的 Sass 编译器：

  • grass。只提供编译成 WASM 的版本，但是性能并不好。
  • rsass。可惜，这个项目也没支持 Node.js API，也无法直接用于现在的前端构建工具生态。

更快的 TypeScript 检查器

TypeScript 很慢，因为它完全是 JavaScript 写的。幸运的是，我们通常不需要在构建前端项目的时候检查类型。Babel, esbuild 或 swc 会直接忽略所有类型。但是，如果你项目有很严格的 QA 要求，你不得不运行 tsc 命令检查类型，CI 工作流就会被拖慢，即使对于小型项目 (10k lines) 或中型项目 (100k lines) 也很明显。

于是乎，重写 TypeScript 检查器的呼声越来越高。我们已经能看到一些这方面的尝试：

2023年 3月 19日 | 评论

Switch游戏模拟指南

经过我个人测试，大部分 Switch 游戏都能在 PC 上流畅运行。偶有崩溃的情形，但是频率不高。

模拟器

目前最流行的是 yuzu 和 Ryujinx, 两者模拟效果差不多，yuzu 有中文翻译。我这里选了 yuzu。

硬件要求

  1. CPU：五年内的主流 x86_64 CPU 应该都没问题，推荐四核心以上。我用的 AMD 5600X。
  2. GPU：需要 GTX 1060 及以上水平的显卡才能流畅运行。我的 AMD RX 6700 可以跑两倍分辨率。
  3. 手柄：通用的双摇杆手柄就行。

系统要求

yuzu 目前只支持 Windows 和 Linux。

安装模拟器

Windows 用户没有官方的公开下载渠道，要付费订阅 Patreon 才能下载。非官方下载链接： https://archive.org/download/yuzu-windows-msvc-20221119-c0e2f8bcb/yuzu-windows-msvc-20221119-c0e2f8bcb.zip

Linux 用户有几种选择：

  1. 从官网下载 AppImage 包 https://yuzu-emu.org/downloads/
  2. 从 Flathub 安装 https://flathub.org/apps/details/org.yuzu_emu.yuzu
  3. 在你发行版的 OBS, AUR, PPA 找一找有没有打包好的

安装好，运行应该是这样子的：

如果启动后界面是英文的，从菜单栏选择 Emulation –> Configure… –> General –> UI –> Interface language 修改成中文。

安装Switch系统固件（非必需）

大部分游戏没有固件也能运行。但是安装固件可以让更多游戏能玩，减少一些游戏崩溃的概率。

https://archive.org/download/nintendo-switch-global-firmwares

下载固件 zip，我测试 14.1.2 版本的固件最好用。解压后会得到几百个小文件。

打开 yuzu，通过菜单栏 文件 –> 打开 yuzu 文件夹，然后依次打开 nand –> system –> Contents –> registered 文件夹，将之前解压的所有小文件都复制到这里。

安装 prod.keys 和 title.keys

这两个是关键的密钥文件。去网上搜一搜就好了，这里就不提供下载了。

prod.keys 是必需的系统密钥，缺少了 prod.keys 密钥就玩不了游戏。prod.keys 和游戏无关，不管是新游戏还是老游戏，都不用更新 prod.keys。

title.keys 不是必需的，只有联机才需要。

打开 yuzu，通过菜单栏 文件 –> 打开 yuzu 文件夹，然后打开 keys 文件夹，将你找到的 prod.keys 和 title.keys 文件都复制到这里。

下载游戏 ROM

最常见的游戏 ROM 有 NSP 和 XCI 两种格式。yuzu 都能识别。下载完 ROM 之后，建议放到一个文件夹下面。

双击 yuzu 窗口中间，选择你的游戏文件夹，yuzu 会自动扫描文件夹里的游戏。

安装更新和 DLC

如果你还下载了游戏更新和 DLC（通常也是 NSP 和 XCI 格式），点击菜单栏的 文件 –> 安装到 NAND, 选择你的更新和 DLC 文件即可安装。

运行游戏

单击游戏即可运行。

差不多就是这样！

安装 MOD

Switch 性能比较差，像塞尔达这样的游戏，只能锁了 30 帧运行。但是在 PC 上模拟，硬件性能不再是问题。通过安装 60FPS 的 MOD, 我们可以玩到比 Switch 更流畅的体验。

首先打开官方 MOD 下载页面，搜索英文“Zelda”，找到对应的游戏。然后下载名为 60FPS 的 MOD。注意：尽量选择 MOD 支持的游戏版本，以免游戏崩溃。

下载完成后，解压文件，得到一个 60FPS 文件夹。

打开 yuzu，在游戏列表中找到塞尔达，右击，选“打开 MOD 数据位置”。

将之前解压得到的 60FPS 文件夹，复制到此处即可。

然后启动塞尔达，就能够以 60FPS 的流畅度玩了！如果有 3080 / 6900 这样的高端显卡，甚至可以2倍缩放画面，实现 4K@60FPS 的体验。

还有很多其他类型的 MOD, 大家可以自行探索。

2022年 12月 20日 | 评论

浏览器兼容性与 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。

横向对比

babelesbuildswcpolyfill servicepostcss
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日 | 评论

扒一扒深圳外企的前端/全栈招聘

最近找工作接触过的一些深圳外企。

Artflow AI（远程）

职位：全栈。

来源：猎头。

流程：

  • HR 直接拉了一个群，初创公司，CEO 和 CTO 都是华人。
  • 技术笔试，做一个全栈 demo, 重视单元测试。
  • 技术面试，中文，两个面试官分别是 CTO （算法/架构）和全栈开发。问的都是一些实际项目的问题，没有很偏门很细节的问题。
  • 综合面试，英文，两个面试官分别是 CEO 和另外一个 Co-Founder。主要问项目经历，以及对这个公司做的产品有什么想法和建议。
  • 谈薪资待遇（最后没谈拢）。

优点：

  • 不用八股文，不用刷题。
  • 流程很快，从递简历到拿 offer 一周时间。
  • 全员远程，灵活办公。
  • 可以谈 14 薪，比 16 薪或 18 薪要保险一点。

缺点：

  • 试用期三个月，发正式工资的 80%。
  • 公积金 7%。
  • 因为时差的原因，开会时间是中国的晚上 9 点到 11 点。

SkyScanner

职位：全栈。

来源：LinkedIn。

流程：

  • HR 电话。
  • 待续。

亚马逊 AWS

职位：前端架构（偏全栈）。

来源：LinkedIn。

流程：

  • HR 电话，没啥特别的。
  • 技术面试1，主要是介绍自己做过的项目，不会问技术细节问题。
  • 技术笔试，做一个全栈的系统 demo （技术栈不限）。要用到至少一种 AWS 服务，最常用的是 S3，要实际部署到 AWS 上运行，还要写系统架构设计报告，比较耗时。我觉得他们的岗位描述有问题，笔试全是全栈+运维的东西，前端的比例很少。
  • 技术面试2，要求做 PPT 介绍笔试题目的系统设计。我到这一步就被通知招聘冻结了，没有后续了。

优点：

  • 不用八股文。
  • 不用刷题。
  • 薪资水平在外企中算高的。

缺点：

  • 做 demo 比较耗时，前后搞了一周的时间。主要是 AWS 比较难搞，之前的工作都是有专门的运维搞AWS, 开发是不会直接去操作的。
  • 突然终止招聘不太靠谱啊，可能很长一段时间都没岗位了。
  • 开发也要求走客户，出差可能会比较多。

Flexport

职位：全栈。

来源：公司官网。

流程：

  • HR 电话，聊完之后说安排面试但又没有后续了。

缺点：

  • HR 不靠谱。
  • 薪资的现金部分比阿里低，期权妥妥的废纸。

Nike

职位：全栈。

来源：脉脉。

流程：

  • HR 面试，有英文口语部分。
  • 技术笔试，做一个全栈 demo, 技术栈不限，重点要求单元测试和 CI （GitLab）。
  • 技术面试，有英文口语部分，不涉及笔试 demo 的内容，也没有问技术细节，主要介绍项目经历和个人发展的问题。
  • HR 沟通职级和薪资，因为降薪太多，就没继续了。

优点：

  • 不用八股文。
  • 不用刷题。
  • 面试过程比较轻松友好。

缺点：

  • 薪资比较低。
  • 要对接 Nike 收购的数据公司，可能要处理一堆技术债务。

避坑

  • 国内小厂：不要相信小而美。
  • 假外企，假国企：都是大厂出来的，比大厂还能卷。

总结

我个人是比较喜欢偏实践的面试/笔试的，毕竟啥 service worker 啥 event loop 的技术细节，工作中也是随用随搜，工作中 99% 用不到。面试的大部分都是全栈或者前端偏全栈，在做 demo 的过程中我会尝试一些新的技术，比如 Vitest, Adonis, 还是很有收获的，比每天上班重复那一套东西要有趣。

技术上，纯前端不多，大部分是全栈。前端 React 还是比较通吃，有些公司用 Vue，不建议学 Angular 了。后端 Node.js, Python, Java 比较多，但是面试很多不限制编程语言，可以后面再转。除了基本的功能实现，单元测试基本上每家都会考一下。另外 CI, 云服务，也是常会遇到的。笔试考 demo 的好处是可以边做边学，不用事先背一大堆可能用不到的东西。

外企的薪资普遍比较低。薪资高的要么是亚马逊这样的大厂，要么是搞区块链的不差韭菜。阿里的开发 P6 英文叫 Software Engineer II, 对应到其他外企同级别的岗位一般也叫这个，再上面是 Senior Software Engineer 和 Lead Software Engineer。但是普通外企的 Software Engineer II 的年薪也就是阿里开发 P5 的水平，甚至 Nike 这种 Senior Software Engineer 也给不到阿里 P6 的水平。

但是另一方面，大部分外企的评价体系决定了他们是真的闲。有项目就做项目，没项目就自行安排。不会像国内大厂一样，盲目上项目堆人力，做十个烂九个。开会没完没了，对接数不清的人。国内大厂的小领导们，带着下属疯狂卷影响力，对公司业务和个人成长基本是负作用。这种又累又绝望的感觉，让我觉得工资低一些的外企也变香了。

继续找。

2022年 11月 20日 | 评论

下一代前端构建工具

2022 年，Webpack + Babel + Terser 仍然是前端项目构建工具的主流，广泛用于各种生产环境。不可否认，Webpack 和 Babel 仍然在持续进化，对各类研发提供了最稳定且全面的支持。但是随着前端项目规模的增长，CI 流水线的普及，构建性能问题已经成为了影响开发效率的一个关键因素。下一代构建工具，试图从不同的角度实现对构建效率的提升。

esbuild

用 Go 语言实现的构建工具，提供了编译，打包，压缩能力。由于是原生程序，且几乎不依赖第三方库，充分利用 CPU 多核架构等原因，esbuild 实现了夸张的毫秒级编译速度，效率数百倍于 Webpack + Babel。

优点：

  • 高性能。目前最快的实现，整体上略优于 swc。
  • 低占用。Go 语言对字符串的内存优化很好，即使采用多线程工作方式，内存占用仍然远低于基于 Webpack 的工具。

缺点：

  • 自身不提供 HMR，需要依赖其他工具实现。
  • 不支持 React Refresh，对 React 的 HMR 不能用 webpack-dev-server + esbuild 编译的方案。
  • 产物代码分割功能仍处在实验阶段，相比 Webpack 和 Rollup 还是比较简单，不太可靠。
  • 插件生态不健全。

适用场景：

  • 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
  • Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
  • Jest 和 SSR 等 Node 运行环境的代码转译。
  • 嵌入其他构建工具。比如 Vite 用了 esbuild 的编译和压缩能力，不足的部分用 Rollup 插件体系和自己实现的 HMR 补全。

swc

用 Rust 语言实现的构建工具，swc 实现了编译和压缩能力，swcpack 实现了打包能力（实验性）。swc 设计之初就是完全对标 Babel 的，相比 esbuild 拥有更广泛的适用场景。

优点：

  • 高性能。实际测试略慢于 esbuild，但也比 webpack+babel+terser 快上几十倍。
  • 支持 React Refresh。这一点是对 esbuild 的巨大优势，且短期内 esbuild 无法克服的问题。

缺点：

  • 自身不提供 HMR，需要依赖其他工具实现。
  • 打包能力还是实验性质，缺乏高级配置支持。
  • 插件生态不健全，用 Rust 编写插件门槛较高。

适用场景：

  • 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
  • Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
  • Jest (@swc/jest) 和 SSR 等 Node 运行环境的代码转译。
  • 嵌入其他构建工具。比如 Parcel 用了 swc 的编译和压缩能力，不足的部分用自己实现的 HMR 补全，并有 Parcel 自己的插件体系。

Vite

基于 esbuild 的编译和压缩能力，Bundleless 的 HMR 实现，并用 Rollup 插件生态补足了常用的打包特性。目前性能和特性综合考量的最佳选择。

更早的 Bundleless 实现 Snowpack 已经泯然众人了。Bundleless 最大的问题在于，现在前端应用的依赖树太深太广，模块文件太多，逐个文件加载导致启动速度极其缓慢。而 Vite 则是融合了 Bundle 和 Bundleless 两种策略，对 node_modules 还是用 esbuild 去快速 bundle，一次性加载，对于源码再采用 bundleless 策略。这样就平衡了启动速度和热加载速度。

优点：

  • 构建速度更快
  • 热更新速度更快
  • 能够使用众多的 Rollup 插件

缺点：

  • 由于 esbuild 不支持 React Refresh，React 项目还是要走 Babel，一定程度上拖慢了速度。
  • Rollup 及其插件生态还是以 JS 为主，性能优化空间有限。Vite 作者寄希望于 esbuild 打包能力和插件生态成熟，用 esbuild 替换掉 Rollup。

适用场景：

  • Web 前端应用
  • 浏览器插件
  • Electron 应用
  • 小程序

Parcel 2

Parcel 基于 swc 并有自己的 HMR 和插件生态。设计上与 Vite 类似，但 Parcel 自研部分更多，而 Vite 依赖且受限于 Rollup。性能上 Parcel 甚至更快一些，尤其是缓存性能，热启动极快。但在稳定性上 Parcel 控制的并不好，一个最简单的 React 应用都需要一些 hack 才能工作。

优点：

  • 构建速度快
  • 缓存效率高
  • 热更新速度快

缺点：

  • 不兼容 pnpm
  • 插件生态不足

适用场景：

  • Web 前端应用
  • 浏览器插件
  • Electron 应用
  • 小程序

Turbopack(Alpha)

用 Rust 实现 Webpack 替代，工作原理和 Webpack + Webpack Dev Server 保持一致，而没有走时下流行的 bundleless 路线。当项目源码（不包括 node_modules）文件数量达到数千，Vite 启动速度会随文件数量降低，即使本地几乎不存在网络延迟，数以千计的 HTTP 请求以及代码转译任务仍然耗时不菲。而 Turbopack 则通过提升打包性能，在保持 Webpack 工作方式的情况下，实现了快速启动和 HMR。当前 Turbopack 的测试性能是领先 Vite 的。

假如 Vite/Parcel 也用 Rust/Go 完全重写，那么 Vite/Parcel 和 Turbopack 应该具有以下关系：

  • 在文件数量小于 N 时，Vite/Parcel 的冷启动速度更快，但是 Turbopack 也足够快。
  • 在文件数量大于 N 时，Turbopack 的冷启动速度更快，且于 Vite/Parcel 的差距越来越大。
  • Vite/Parcel 的 HMR 速度总是快于 Turbopack，但是两者都足够快，以至于差异肉眼无法分辨。

可惜 Turbopack 目前并没有推出正式版本，完全没有达到 Vite/Parcel 的成熟度，因此完全没有可比性。目前只能关注，深入分析或评测意义不大。

2022年 10月 28日 | 评论

JavaScript 十进制库选型

众所周知，计算机以二进制存储数字，而真实世界中用十进制表示数字。二进制和十进制的差异可以用一个乍看非常怪异的例子说明：

> 0.1 + 0.2
0.30000000000000004

不管是 JavaScript, Python 还是 Java，都能够得到类似的结果。

分析原因，就像十进制中的 1/3 是无限循环小数，二进制中的 1/10 和 1/5 也是无限循环小数。计算机的基本数字类型都是有精度限制的。两个无限循环小数相加，导致精度损失，产生了 0.30000000000000004 这样的结果。

在很多情况下，这个并不会有实际影响。因为十进制同样有精度误差，十进制并不比二进制更精确。它真正导致的问题是违反直觉。对于人直接可见的数字计算，比如购物车结算总价，出现二进制精度问题显然会让不了解二进制原理的普通用户感到诧异。

另外，原生浮点数的取整方法都是四舍五入。按照统计学规律，大量累加起来，总数会偏大。对于电商，银行和支付系统，会导致交易的某一方长期多付出，是违反公平的。因此这些系统常常采用银行家算法（四舍六入五成双）。

最后，整数和浮点数都有固定的精度限制，且受限于硬件或编译器无法更改。计算超出范围的大数会出错，不安全。

基于这三点原因，在电商和金融系统中，会使用十进制类而非基本数据类型来计算和存储交易数字。

JS 常用库比较

JavaScript 目前仍然没有原生的十进制类。我们只能从一些提供十进制类的 NPM 包中选择。不同的十进制库提供的功能不完全相同。通常功能越多体积越大。目前开发比较活跃且比较流行的 JS 库都来自同一位作者。差异详见此处。

NPM 包big.jsbignumber.jsdecimal.js
打包尺寸 Minified + Gzipped2.9kB8.1kB12.3kB
精度控制N位小数N位小数N位有效数字
除法精度损失有损有损有损
加、减、乘法精度损失无损无损有损
超大数支持，计算较慢支持，计算较快支持，计算较快
超小数支持，计算较慢支持，计算较慢支持，计算较快
舍入模式ROUND_DOWN
ROUND_HALF_UP
ROUND_HALF_EVEN
ROUND_UP		ROUND_UP
ROUND_DOWN
ROUND_CEIL
ROUND_FLOOR
ROUND_HALF_UP
ROUND_HALF_DOWN
ROUND_HALF_EVEN
ROUND_HALF_CEIL
ROUND_HALF_FLOOR		ROUND_UP
ROUND_DOWN
ROUND_CEIL
ROUND_FLOOR
ROUND_HALF_UP
ROUND_HALF_DOWN
ROUND_HALF_EVEN
ROUND_HALF_CEIL
ROUND_HALF_FLOOR
EUCLID
指数计算支持支持支持
对数计算不支持不支持支持
复数计算不支持不支持支持
三角函数计算不支持不支持支持

从简单到复杂排列：big.js < bignumber.js < decimal.js

从打包体积来看，big.js 最小，在浏览器端占据优势。

在电商和金融场景，更常见的精度控制方法是控制 N 位小数，big.js 和 bignumber.js 更加合适。而在科学计算和工程领域，可能 decimal.js 的控制 N 位有效数字的特性会更合适一些。

除法都是有精度损失的，这是无法避免的。但是 decimal.js 的加减乘法也有精度损失，这一点需要注意。

big.js 对于超大数的计算会比 bignumber.js 或 decimal.js 慢，要结合具体场景分析是否会性能瓶颈。在前端/客户端场景，或者小型电商后端，计算量很小，且大数不常见，那么 big.js 完全可以胜任。在大型电商平台和金融交易后端，大数计算量繁重，那么 bignumber.js 会更好一些。科学和工程领域需要的超大数计算，则 decimal.js 会更合适。（但是这些领域通常也不会用 JS 这么慢的语言，所以 decimal.js 的定位有点尴尬）

超小数通常只在金融，科学和工程领域出现，这种数据的计算 decimal.js 会比 big.js 和 bignumber.js 快。和上面的大数应用场景分析类似，要视情况选择。

默认的舍入模式都是四舍五入（ROUND_HALF_UP），且都支持银行家算法——四舍六入五成双（ROUND_HALF_EVEN）。对于大多数电商和金融场景都足够用了。

decimal.js 还支持对数，复数，三角函数等高级数学运算。

按应用场景选择

中小型电商

中小型电商的交易数字都偏小，big.js 在前后端都可以胜任，满足精度控制，舍入模式和性能的需求。同时 big.js 的体积较小，有利于优化前端传输速度。

大型电商平台和金融系统

前端/客户端通常只处理单一客户的计算需求，大数出现频率较少，通常不存在性能问题。 big.js 依然可以胜任。

后端则可能会频繁处理大数，这时候 bignumber.js 会更快一些。但是，这种情况通常表明整个系统都面临性能问题，更加实际的做法是将重度计算的服务用 Java 之类的更高性能语言重构……

科学计算和工程领域

decimal.js 功能更加丰富，对极大和极小数计算的性能更好，比 big.js 和 bignumber.js 更合适。

但是，这些领域通常对性能要求很高，用 JS 的情况非常少见。建议直接使用一种更合适的语言……

总结

前端选择 big.js 一般都没错。它简单小巧，却又能提供所有我们需要的功能。

后端 Node.js 不需要考虑打包尺寸，如果有比较多的大数计算量，也可以上 bignumber.js 的。

decimal.js 的定位则比较尴尬，除非你特别需要某些科学计算功能，否则没有必要选它。

实践

  1. 阿里巴巴 Fusion Design 从 bignumber.js 切换到 big.js PR 链接

2022年 6月 18日 | 评论

Linux 科学上网指南：DNS

最近经常出现 Firefox 可以打开 GitHub 网站，但是命令行 Git 无法拉取/推送代码的情况。甚至开了 VPN 也不行。运行 ping 命令发现 github.com 被解析到了 127.0.0.1，这是 DNS 被劫持了。是谁搞的鬼，相信你一定懂得。

为啥 Firefox 可以打开 GitHub

最新的 Firefox 桌面版默认启用了 DoH（DNS over HTTPS），通过向特定的服务器发送 HTTPS 请求获取域名的 IP 地址。这就绕过了电信/联通/移动等提供的有毒 DNS 服务器。因为 DoH 采用 HTTPS 协议，不容易被劫持。另外国内用 Firefox 的很少，这个技术并不普及，所以暂时没有被老大哥盯上。

但是很可惜，DoH 目前无法在 Linux 系统层面支持，运行命令行仍然是使用 ISP 提供的 DNS 服务器。电信/联通/移动经常抽风，甚至某些路由器都会给你下毒，让你打不开网页或者直接跳到某网址导航。

为啥开了 VPN 也不行

因为通常是先连接本地网络，这时候已经从 ISP 获取了一个 DNS 服务器。再连接 VPN，（以 OpenVPN 为例）仍然是用的这个 DNS 服务器。

某些商业 VPN 客户端是会在连接上 VPN 之后自动更换 DNS 服务器的。但是 Linux 自带的网络管理是没这个能力的。

因此，如果你只用 Linux 自带的网络管理，最好的解决方法依然是手动设置一个可靠的 DNS 服务器。

DNS 服务器哪家强

如果你去网上搜，很多老的文章会推荐这两个：

  1. Google 的 8.8.8.8
  2. Cloudflare 的 1.1.1.1

这两个 DNS 还是能用的，但是在有些地方不太稳定，甚至直接连不上。

目前还是推荐国内正规企业提供的 DNS 服务器：

  1. DNSPod/腾讯云 119.29.29.29
  2. 阿里云 223.5.5.5

并不能保证腾讯和阿里的 DNS 百分之百可靠，但是比电信/联通/移动好太多。起码 GitHub 是可以正常解析的。

如何设置 DNS

这里就只介绍普通桌面用户用 NetworkManager 和 KDE 的用法。GNOME 基本类似。用 Wicked 的都是技术大佬，相信也不用看下面这些了。

  1. 从系统托盘网络图标右击，打开“网络设置”。
  2. 选择你的有线或者 WiFi 链接，进行编辑。
  3. 切换到 IPv4 标签页。
  4. 将“方法”从“自动”改成“自动（仅网络地址）”。
  5. 将“DNS服务器”改成“119.29.29.29”。
  6. 点“应用”并关闭“网络设置”窗口。
  7. 点击系统托盘的网络图标，打开网络列表，断开并重新链接。

注意，如果需要频繁更换不同的 WiFi 链接，则需要对不同的 WiFi 配置添加自己的 DNS 服务器。

如果是自己家的网络，可以在路由器上配置，方法和上面类似，都是配置 IPv4 方法和 DNS 服务器。（注意，路由器的 WAN 互联网和 LAN 局域网设置都要配一下）这样家里的设备就不用单独配置了。

清空 DNS 缓存

因为 DNS 记录是有本地缓存的，即使你更换了 DNS 服务器，依然会优先从缓存里取 IP 地址。所以更换 DNS 之后，需要清空 DNS 缓存。

这是一个比较头疼的问题，因为各家 Linux 发行版用来管理 DNS 的方式不一样，清空 DNS 缓存的方法也不一样。

最通用的方法：重启系统。

如果不想重启系统，那么可以参考这篇文章 https://www.techrepublic.com/article/how-to-flush-the-dns-cache-on-linux/

我大概总结一下，就是逐个试下面的命令：

sudo systemd-resolve --flush-caches
sudo systemctl restart nscd
sudo systemctl restart named

如果没有用的话，还是重启系统吧。

测试 DNS 解析

首先用 nslookup 测试一下 DNS 服务器是否能解析，如果解析出来的 Server 是你之前配的地址，Address 不是 127.0.0.1 或者 0.0.0.0 这种，应该就是好的。

$ nslookup github.com
Server:         119.29.29.29
Address:        119.29.29.29#53

Non-authoritative answer:
Name:   github.com
Address: 20.205.243.166

但是 nslookup 能解析，并不意味着就能连上。实际连接还要看 ping 命令。注意 github.com 并不回应 ping 请求，也就是数据包都会 lost，这是正常的。只要 ping 能解析到 IP 地址就行了。

$ ping github.com
PING github.com (20.205.243.166) 56(84) 字节的数据。
^C
--- github.com ping 统计 ---
已发送 3 个包， 已接收 0 个包, 100% packet loss, time 2049ms

如果 ping 没问题，最后再试一下 git pull 命令。如果不能访问，则需要试试 VPN 了。

2022年 5月 29日 | 评论

前端最佳实践：字体

字体单位

px 依旧是最全面的选择，尤其是重交互的网站：

  1. 能够做到设计稿的像素级还原。
  2. 用户体验统一，变量少，可控。
  3. 方便配合 JS 动态计算布局，JS 接口通常只能获取像素为单位的尺寸和位置。
  4. icon，图片和 border 通常都是使用像素尺寸，字体采用像素单位更容易配合。

rem 在文字内容型网站上更加灵活，适合新闻，博客等：

  1. 自适应不同设备，不同用户偏好，获得最佳阅读体验。
  2. 无需手写繁复的 media query。

有些创意内容网站使用 vw 尺寸系统，字体和图片总是同窗口比例缩放，以实现类似海报布局的整体感，但也仅限于这一类型的网站。

em 和 % 会用在局部使用，但存在嵌套后尺寸不容易控制的问题，极少在项目中大范围使用。

pt 是印刷常用单位，不适合现如今的 Web 环境，且和 px 对应关系复杂，应该避免。

正文字体大小

12px 是 Chrome 浏览器默认支持显示的最小字体。即使 CSS 设置了 9px，最终用户看到的仍然是 12px 字体。因此在设计中使用小于 12px 的字体是一个严重的错误。12px 的英文字体可读性尚可，但是中文可读性比较差。建议作为次要文本字体的尺寸。

13px 是信息密度较高，中文可读性尚可的选择。比如 Facebook 和百度用的就是 13px。

14px 是信息密度和中文可读性的一个比较好的平衡点，适合界面复杂且空间比较紧张的网站的正文字体大小。比如

16px 是大部分浏览器的默认字体大小，可读性好，但是信息密度不高，适合一般网站。

18px 以上通常只有在创意营销网站上才会作为正文字体大小使用。

一个比较通用的策略是：

  • 12px：次要文字，页脚链接，标签分类，面包屑，输入框提示，小按钮，小输入框
  • 14px：普通文字，正文，输入框，按钮
  • 16px：突出文字，卡片标题，大按钮，搜索栏

标题层级字体大小

HTML 支持 H1 到 H6 共六级标题。但实际应用中，我们应当控制标题的层级数量，层级越多，使用体验会越差。

功能为主的网站对标题依赖比较小，更多是靠 Card 和 Tab 等容器进行界面层级管理。

内容型网站对标题层级的需求会更高一些，但也尽量不超过三级。

H1 字体大小取决于网站类型对信息密度的要求。以功能为主的系统通常 H1 会比较小，不会超过 40px。

H1, H2, H3 之间应当有 30% 左右的递减，视觉上差异才够显著。比如：

  • H1, 36px：页面标题
  • H2, 24px：章节标题
  • H3, 16px：子章节标题，卡片标题，弹窗标题

字重

最早字体只支持两种字重，正常（normal, 400）和粗体（bold, 700）。现代 Web 字体的字重支持 100 到 900 等 9 种字重，100 最细，900 最粗。但是系统字体支持的字重数量通常较少。

Windows 默认中文字体“雅黑”支持 300, 400 和 700 三种字重。macOS 和 iOS 默认中文字体“苹方”支持 100/200/300/400/500/600 六种字重（苹果更喜欢使用较细的字体设计）。也就是说“苹方”的粗体，会比“雅黑”要细一些。Android 系统默认字体 Noto Sans CJK 支持 200/300/400/500/700/900 六种字重，最为全面。部分 Android 系统，比如魅族 Flyme 和小米 MIUI，甚至搞出了字重的无极调节。

由于中文字体体量巨大，通常网站不会加载远端中文字体，而是使用系统字体。因此，在使用字重的时候，就需要考虑系统字体的字重支持。综合主流操作系统，得出兼容性最好的字重集合：细体 300，正常 400，粗体 700/600。

2022年 4月 5日 | 评论

变更日志 Changelog 的书写方法

变更日志（Changelog）是软件工程中的一种常用手段，用于记录每个软件版本所发生的变更。一方面，可以方便下游及时兼容；另一方面，让协作开发者和用户了解项目进展。变更日志需要打版本号，但并不一定要遵循 Semantic Versioning。

最简单的形式

  1. 推荐使用 Markdown 语法，文件名为 CHANGELOG.md。
  2. 用二级标题标记版本号，建议标注发布日期，以便日后回溯。合并主干分支但尚未发布的，用“未发布”标题，放在开头。
  3. 对于不兼容的变化，用“破坏性变更”标记。
# 变更日志

## 未发布

- 修复 Button

## 2.0.0 - 2021-09-17

- **破坏性变更**: Table 组件重命名为 Grid

## 1.1.0 - 2021-03-21

- Card 组件支持 size (small/large/medium)
- 新增 List 和 Table 组件

## 1.0.0 - 2021-02-08

- 新增 Card 组件
- 新增 Button 组件

增加模块标记

对于模块比较多的库或应用，变更项目会很多，不容易阅读。比较好的方式是在开头标记这个变更属于哪个模块，不属于任何模块的用 Other 标记。比如说你的应用有很多页面，则可以按页面来划分。如果是组件库，则可以按组件来分。如果是单个复杂组件，则可以按属性或功能来分。

## 2.1.0 - 2021-09-17

- Card: 增加 size (small/large/medium) 属性
- List: 新组件
- Button: 修复 loading 样式
- Input: 增加 warning 图标
- Other: 修复 IE 11 兼容性

细分变更类型

实践中，分类越详细，开发者维护变更日志的工作量越大。不分类是完全可行的，只有当你有充足的时间和很高的追求的时候，再考虑。

有很多种方法可以给变更分类。

按特性（Feature）和修复（Fix）分类是最简单可行的，也更符合当下软件工程的模型，容易配合各种项目管理工具。最重要的是，通常没有什么争议。

## 2.1.0 - 2021-09-17

### 特性

- Card: 增加 size (small/large/medium) 属性
- List: 新组件
- Input: 增加 warning 图标

### 修复

- Button: 修复 loading 样式
- Other: 修复 IE 11 兼容性

如果你听说过 Keep a Changelog ，它提供的分类方法要复杂得多。

## 1.0.0 - 2022-02-02

### 新增

- List: 新组件
- Input: 增加 warning 图标

### 更改

- Card: large size 的 padding 从 12px 调整为 16px

### 移除

- Card: align 属性，用 headerAlign 和 footerAlign 替代

### 废弃

- Input: focus 属性，建议用 Ref 

### 修复

- Button: 修复 loading 样式
- Other: 修复 IE 11 兼容性

对大部分项目来说，这样做意义不大，会消耗开发者更多的精力。因此建议变更不做细分，或者按照上面特性+修复的简单分类方法。

为什么不用 Git 历史

大多数项目的 Git 历史 commit message 含义不清，很难去阅读。

为什么不用项目管理系统

JIRA 和 AONE 之类的项目管理系统，或者 NPM 这样的软件包平台，确实能够在一定程度上记录软件发布历史。但实际项目中，会出现不得不从一个平台迁移到另一个平台的情况。这些发布记录有时候并不能随代码迁移到新平台。另外，软件分发给客户或者下游之后，他们并不一定能访问我们内部系统的发布历史。

2022年 3月 19日 | 评论

React 页面加载速度优化（非SSR）

React 应用页面首次加载通常比后端渲染静态页面慢，这对用户体验有着极大的负面影响，尤其是移动端。服务器端渲染（SSR）是非常有效的手段，但实现成本过高，不止要调整技术架构，也会增加服务器负载。那么在不使用 SSR 的前提下，如何优化 React 应用的首屏加载速度呢？

加载过程分析

使用 Firefox 开发者工具网络面板对页面加载过程中的网络流量进行监控，是最常用的分析方法。

注意右侧的进度瀑布图有两根线条，一根红色，一根蓝色：

  • 蓝色是 DOMContentLoaded 事件触发的时间点
  • 红色是 load 事件触发的时间点

但是对于 React 应用而言，以上两个事件并不标志着页面内容已加载完成。React 应用通常会需要请求一些 JSON 接口（比如商品信息），然后再加载 UI 组件（比如商品列表）。实际加载时间，我们可以通过 performance.now() 接口在组件实际挂载（componentDidMount 或 useEffect）时获取：

import React, { useEffect, useState } from 'react';

function App() {
  const [products, setProducts] = useState([]);
  useEffect(() => {
    fetch('api/products').then(res => res.json()).then(setProducts);
  }, []);
  if (products?.length > 0) {
    return <ProductList products={products} />
  } else {
    return <div>Loading...</div>;
  }
}

function ProductList({ products }) {
  useEffect(() => {
    console.log('ProductList loaded in ' + performance.now()/1000 + 's');
  }, []);
  return products.map(({name}) => <div>{name}</div>);
}

本地的测试分析不能反映实际用户的加载速度。建议将加载时长结果上报到服务器，进行统计分析，制作按日/小时的趋势图，以及按加载秒数的分布图。统计结果将有助于判断后续的优化工作的效用有多大。

数据加载优化

首屏展示依赖的数据，后端直接注入到 HTML 中，从而减少网络请求数量。

<script>
  window.user = {{ JSON.stringify(user) }};
  window.productInfo = {{ JSON.stringify(productInfo) }};
  window.translations = {{ JSON.stringify(translations) }};
</script>
<script src="path/to/js"></script>

要小心控制注入 HTML 中的数据数量，过大的 HTML 可能会导致页面加载失败的概率增加。首屏不展示的数据，或者不重要的数据要排除：Select 的数据源，弹窗中用到的数据，通知数据等。翻译数据最好按首屏需要做一次切分，且只透出当前用户语言。

从实践经验来看，这一项措施，对加载速度提升最为明显。

图标加载优化

icon font 是图标加载方式的主流，但加载字体文件会多发出一个请求。且字体请求通常是在 CSS 中触发，会阻塞页面加载。另外，字体文件很难根据首屏内容进行切分，不够灵活。某些大型应用，图标高达上百个，加载数 MB 的图标字体会让体验变得很差。

更好的方案是用 SVG Sprite 直接嵌入 HTML 中，或用 Inline SVG 直接嵌入 JS 中，减少一次网络请求，同时只加载首屏需要的图标。

打包尺寸优化

首先，建议所有使用 Webpack 4 的项目迁移到基于 Webpack 5 或者 Rollup 的构建工具，以使用 ES6 Module 的特性进行 Tree Shaking，去掉未被使用的部分，缩减产物尺寸。

对于 lodash 这种非 esm 包，建议用 lodash-es 替代或者采用分量引用：

// Bad
import _ from 'lodash';

// Good
import get from 'lodash/get';

最后，使用 Webpack Bundle Analyzer 插件分析产物尺寸，识别对产物体积影响较大的包。

  1. 存在多版本的包，考虑升级依赖版本进行优化。
  2. 尺寸过大的包，考虑轻量级替代品，比如 moment -> date-fns/day.js

代码分割

注意：不支持 IE，Edge < 16，Firefox < 60，Chrome < 61 和 Safari < 11

常见的构建工具都支持以下语法进行代码分割：

import React from 'react';
import Header from './Header';
const Description = React.lazy(() => import('./Description'));
const Comments = React.lazy(() => import('./Comments'));
const FeedbackDialog = React.lazy(() => import('./FeedbackDialog'));
const Footer = React.lazy(() => import('./Footer'));

function ProductDetailPage() {
  return <div>
    <Header/>
    <Description/>
    <Comments/>
    <FeedbackDialog/>
    <Footer/>
  </div>
}

对于首屏需要展示的组件，Header，我们用传统的引用方式打包，在页面加载时直接加载其 JS 和 CSS。而对于不会首屏展示的组件，用 ES6 模块动态加载。这样做之后，首屏加载的 CSS 和 JS 尺寸会缩小，从而加快首屏展示。

参考 React 官方文档

但实际项目中，构成项目产物的大部分来自第三方包，比如 React，Moment 和 Ant Design 这样的库，也就是 vendor chunk。如果你的业务代码产物 app chunk 在 gzip 压缩之后不超过 200KB，做代码分割的意义就不大了。

总结

在实际工作中，由于技术架构限制或是资源限制无法使用 SSR，我们还是有很多手段可以去快速优化 React 应用加载速度。

本文没有涉及 HTTP2，缓存策略，CDN 等优化传输速度的方法，因为这些是 DevOps 考虑的范畴，在大的 IT 公司中，都已经做得比较到位了，前端开发者不需要亲历亲为。

2022年 2月 27日 | 评论