关于javascript:精读新一代前端构建工具对比

本周精读的文章是 Comparing the New Generation of Build Tools。

前端工程畛域近期出了不少新工具，这些新工具都使用了一些新技术或者跨畛域技术，实现了一些冲破，因而有必要理解一下这些工具都有什么个性，以及是否能够投入生产环境。

因为原文比拟啰嗦，所以具体用法和反对细节不在这里开展，如果想进一步理解细节，能够间接浏览原文 )。

依照从底层到下层的封装粒度，以 esbuild、snowpack、vite、wmr 的程序介绍。

esbuild 应用 go 语言编写，因为绝对 node 更为底层，且不提供 AST 操作能力，所以代码执行效率更高，依据其官网 benchmark 介绍提速有 10～100 倍：

esbuild 有两大性能，别离是 bundler 与 minifier，其中 bundler 用于代码编译，相似 babel-loader、ts-loader；minifier 用于代码压缩，相似 terser。

应用 esbuild 编译代码办法如下：

esbuild.build({entryPoints: ["src/app.jsx"],
  outdir: "dist",
  define: {"process.env.NODE_ENV": '"production"'},
  watch: true,
});

但因为 esbuild 无奈操作 AST，所以一些须要操作 AST 的 babel 插件无奈与之兼容，导致生产环境很少间接应用 esbuild 的 bundler 模块。

侥幸的是 minifier 模块能够间接替换 terser 应用，能够用于生产环境：

esbuild.transform(code, {minify: true,});

因为 esbuild 就义了一些包大小换取了更高的执行效率，因而压缩后包体积会略微大一些，不过也就是 177KB 与 165KB 的区别，简直能够疏忽。

esbuild 比拟底层，所以能够与后续介绍的下层构建工具联合应用，当然依据工具设计理念，是否内置，内置到什么水平，以及是否容许通过插件替换就是另一回事了。

snowpack 是一个绝对轻量的 bundless 计划，之前也写过一篇精读 snowpack，其实 bundless 就是利用浏览器反对的 ESM import 个性，利用浏览器进行模块间依赖加载，而不须要在编译时进行。

跳过编译时依赖加载能够省很多事，比方不必思考 tree shaking 问题，也不必为了最终产物减速而应用缓存，相当于这些工作交给最终执行的浏览器了，而浏览器作为最终运行时容器，比编译时工具更理解应该如何按需加载。

仅从编译时来看，批改单个文件的编译速度与我的项目整体大小无关，而若不思考整体我的项目，仅编译单个文件（最多递归一下无限的依赖模块，解决比方 TS 类型变量判断问题）工夫复杂度肯定是 O(1) 的。

实际上咱们很少独自应用 snowpack，因为其编译应用的 esbuild 还未达到 1.0 稳固版本，在生态兼容与产物稳定性上存在危险，所以编译打包时往往采纳 rollup 或 webpack，但这种割裂也导致了开发与生产环境不统一，这往往代表着更大的危险，因而在 vite 框架能够看到这块的取舍。

snowpack 是开箱即用的：

// package.json
"scripts": {
  "start": "snowpack dev",
  "build": "snowpack build"
},

咱们还能够减少 snowpack.config.js 配置文件开启 remote 模式：

// snowpack.config.js
module.exports = {
  packageOptions: {"source": "remote",}
};

remote 模式是 Streaming Imports，即不必装置对应的 npm 包到本地，snowpack 主动从 skypack 读取文件并缓存起来。

snowpack 看起来更多是对 bundless 纯正的尝试，而不是一个适宜满足日常开发的工具，因为日常开发须要一个一站式工具，这就是前面说的 vite 与 wmr。

能够了解为联合了 snowpack 特色的一站式构建工具，从开发到公布全套流程都帮你搞定。

波及的用法十分多，具体内容能够看官网文档。

与 snowpack 不同的是，snowpack 生产打包的产物是独立的文件，而 vite 没有采纳 esbuild 而是 rollup 打包，目标是为了打包为一个整体，并躲避 esbuild 不稳固的危险。

另外因为 vite 集成化更高，比 snowpack 多了许多性能，比方 css 拆分、多页、应用 esbuild 进行依赖预构建、monorepo 反对、对多框架反对、SSR 等等。具体能够看文档介绍。然而原文说这有利有弊，益处是开箱即用，弊病是不足定制的灵活性。

其实革命性冲破次要是 bundless，在这根底上倒退出一系列便捷的性能，这值得每一个工程化团队学习。其实就算决定再造一个轮子，也是维持 90% 性能不变的根底上，在默认的偏好设置做一些微调，而这些大多能够用插件解决。

总结下来，Vite 是一个既踊跃拥抱新个性，又为生产环境思考的工程化全家桶，相比之下，技术栈过于前沿的工具只能称为玩具，而 Vite 是真的能够用一用的。

由 preact 作者开发，能够了解为 preact 版的 vite。所以对于 preact 技术栈的开发者更加敌对，集成度更高。

原文提到的另一个特色是，wmr 应用了 htm 转换 JSX，使其取得了更加准确的报错体验，即能够准确到源码行的同时指定到具体列。

综合性能和 vite 差不多，单页 + ssr 都反对，如果你平时应用 preact，或者想开发一个体积极小的我的项目，能够思考用 wmr 全家桶。

新一代前端构建工具最大特色有两个：更底层的语言编写、bundless，如果用一个词形容就是高性能。踊跃拥抱浏览器新个性或者常识跨界都能够帮忙前端畛域获得新的冲破。

另外构建工具曾经变得越来越集成化，从仅用于编译的 esbuild，到反对开发的 snowpack，再到内置了最佳实际、甚至反对比方 ssr 等后端能力、最初到垂直场景的 vitePress，每形象一次，都更开箱即用，但带来的灵活性升高也成为各团队本人造轮子的理由，越下层越是有本人造轮子的激动。

这和可视化畛域很像，可视化从最底层的 svg、canvas、webgl 到基于其封装的命令式框架，再到数据驱动开发框架、齐全 JSON 配置化的图表库、甚至到零配置，依据数据猜配置的智能化我的项目，也是配置越来越少，但灵便度越来越低，应用什么档次的齐全看我的项目对细节的要求。

不过工程化绝对还是标准化的，因为可视化面向的是用户，而工程化面向的是程序员，咱们不能管制用户需要，但能够管制程序员的开发习惯 :P。

最初，除了降级你的共建工具外，换一台 M1 芯片电脑也能够极大晋升开发效率，笔者亲测 webpack 构建速度晋升 3 倍！

探讨地址是：精读《新一代前端构建工具比照》· Issue #316 · dt-fe/weekly

如果你想参加探讨，请点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。

关注 前端精读微信公众号

版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）