关于前端:从-Bundleless-看前端构建

前言

Bundle or Bundleless？自 2015 年 ESM 规范公布后，路线之争就开始逐渐升温。转眼间，工夫已来到 2021 年。如果白酒的车你错过了，那么无妨看看 Bundleless，或者它就是前端圈的下一位「茅台」。

前端构建当下的问题

不得不说，已经把本人定位为「打包器」的 Webpack，现在已造成弱小的构建生态，俨然一统江湖。但前端构建的路线还远没有走到最初。随着业务的倒退，前端工程的复杂度越来越高，构建方面的也开始裸露出新的问题。

构建工夫逐渐拉长

置信许多前端同学刚入行时，都经验过「刷新一下全都有」的幸福时光：写几个 HTML 标签，写几句内嵌代码，浏览器中就会呈现出美好的 UI。而现在，业务工程越来越简单，代码量连年增长，构建的工夫也越来越长。已经「秒级构建」的前端，究竟跻身「分钟级构建」的圈子了。

前端工程构建工夫的拉长，天然使得前端开发者在日常业务工作中的状态，从图左逐步静止到了图右。

模块规范引领方向

如果咱们纵观前端畛域的倒退，就能够看到 规范 是如何推动各大 浏览器建设 ，整个 前端生态 又是如何产生的变动。

2002 年，AJAX 推出，尔后前端承当的工作越来越多。彼时，浏览器厂各行其是，因而 兼容性 是过后的次要问题。于是 2006 年，jQuery 的呈现进一步带动了前端的倒退。

2009 – 2011 年，CommonJS、AMD、UMD 相继为 JS 带来了模块标准。同一期间，局部遵循 CommonJS 的 Node 为 JS 带来了运行环境，为前端工程化的解锁奠定根底：

• 模块加载工具开始涌现，如 RequireJS、SeaJS 等
• 包管理工具，如 npm、spm 等
• 轻量的打包器开始呈现，如 Browserify
• 工作工具开始呈现，如 Gulp

Angular、React、Vue 等的相继火爆，也推动了前端的又一波浪潮：它们的倒退进步了前端在业务中的表达能力，并向更高水平的工程化提出诉求。

2015 年，HTTP/2.0 推出，同时 JS 迎来了本人的模块规范 ESM：ES2015 一公布，Babel 就让开发者们用上了 ES Module，真香。于是尔后的几年，Webpack & Babel 简直成了前端工程化的代名词，甚至让人认为，前端工程化已成定局。

2018 年，Chrome、Safari、Firefox 相继实现了对 ESM 的反对。但得益于 Webpack 生态对 CommonJS、AMD、UMD 的反对，开发者们对 ESM 的享受更多是在编码阶段和肯定水平的 Tree-shaking，在构建层面并没有间接的得利。

总结

当下工夫点，呈现了新的契机：
其一，「工程体积的日益增长」与「亟待晋升的构建性能」之间的矛盾；
其二，「先进的前端模块规范」与「落后的前端模块标准」之间的矛盾。

Bundleless 为什么是答案

Bundleless 说到底，就是指 无打包构建 ，与咱们当下风行的 打包构建 绝对，而 打包器 则是咱们前端开发者用于将 JS 模块打包成繁多的、可在浏览器内运行的文件的工具。

为什么过来须要打包

这一问题在社区也有十分多的总结，详情来讲，次要包含以下理由：

• HTTP/1.1 各浏览器有并行连贯限度
• 浏览器不反对模块零碎（如 CommonJS 包不能间接在浏览器运行）
• 代码依赖关系与程序治理

HTTP/1.1 各浏览器默认并行连接数

为什么开始尝试不打包

近几年工夫，规范的确立、浏览器大厂和前端生态的跟进，使得「不打包」成为可能：

• HTTP/2.0 多路并用
• 各大浏览器逐个反对 ESM
• 越来越多的 npm 包拥抱 ESM（只管很多包的依赖并不是）

咱们能够发现：

• 通过 打包来缩小网络申请数量从而进步性能的优化伎俩 实践上在 HTTP/2.0 下会变得不再必要；

• ESM 规范的推广和各大浏览器的反对：

  • 让模块代码能够 间接在浏览器中运行
  • 原生的解决了 代码依赖和复用 的问题
  • 会进一步推动越来越多的 npm 包反对 ESM，甚至会呈现新的包治理或散发形式

Bundleless vs Bundle

模块加载的比照

如果是打包式构建，在模块加载时，实际上加载的是若干模块的汇合。这种形式的长处是以大量的申请连接数实现 JS 脚本的下载。如果是无打包式构建，模块的加载则是基于原生模块计划，间接获取具体的模块脚本。

本地开发构建的比照

如果是打包式构建，无论是我的项目启动还是文件变更，都须要残缺的走一遍打包过程。以 Webpack 为例，咱们就会经验依赖剖析、代码转译和打包的过程，哪怕咱们只是简略的批改了一行文案。当然，Split chunk 会在肯定水平上缓解这一问题，但粒度依然偏大。

而无打包式构建，在启动过程中根本只是启动服务（当然不同的 Bundleless 计划可能还会做些其余的工作），而不必对业务代码进行依赖剖析、打包，ESM 会帮忙咱们在浏览器中实现依赖的剖析。当文件产生变更时，本地开发服务只是提供了文件的映射，只须要从新转译对应的文件，并从新替换即可。

论断

以上，咱们能够晓得：

• 打包过程的必要性已升高
• 拥抱 ESM 是将来趋势

社区在畛域内的工作

概览

前端构建并不只是构建工具的问题。事实上，「构建」和「散发」独特组成了前端工程的构建，只不过通常状况下，咱们是通过 npm install 将三方包下载下来，并打包到构建后果中实现的。

构建能够分为两种类型。

一种是 基于服务的构建形式 ，通常服务于理论生产。咱们能够再细分成 本地服务构建 和远端服务构建 。 本地服务构建 就是咱们惯例的操作，目前根本曾经被 Webpack 统治，是 Bundle 计划的代表；Snowpack、Vite、Web Dev Server 则是目前十分火的 Bundleless 计划，近一年的工夫里势头迅猛。远端服务构建 则是依靠云能力的玩法，把构建过程放在服务端实现，从而把本地的开发流程搬到 Web 上，并给出于本地服务构建基本一致的体验。

另一种是 基于浏览器的构建形式 ，通常面向 Demo 的疾速搭建或预览计划。Codesandbox、StackBlitz、CodePen 和 Riddle 是业内较杰出的计划，整体是在浏览器端实现代码的编译、打包、构建和运行。当然，具体到各个计划的细节，通常对服务还是有肯定依赖。

目前来看，100% 在浏览器端进行打包、构建，现阶段并不是最现实的计划。随着 Bundleless 的倒退，浏览器 Bundleless 和包散发平台的联合 会失去进一步的倒退，并逐渐影响前端工程的架构。

????Snowpack

原理

这一部分在 Snowpack 的文档上有肯定的解说。整体来说，Snowpack 尽可能利用了现有前端生态的工具，对三方包打包来压缩依赖链，对业务代码走无构建路线，以此提供 Bundleless 体系下的开发体验。值得一提的是，Snowpack 的构建速度很快，这得益于内置打包工具 esbuild 的倒退。

Snowpack vs Webpack

咱们无妨将其与 Webpack 进行一个比照。

启动工夫，如上文所说，Webpack 会残缺打包整个我的项目，因而随着我的项目体积的增长，启动工夫也会越发漫长；而 Snowpack 次要是启动本地的服务，对于 Snowpack 来说，只管首次启动时会剖析三方依赖，并通过 Rollup 将其进行打包，然而打包后果会缓存在 node_modules/.cache/snowpack/development 目录下，后续就能够享受到飞一样的启动。

构建工夫，对于 Webpack 而言，构建时长会随着我的项目体积整体以线性形式增长；而 Snowpack 的模式则是 O(1) 的复杂度（当然这里也有点小噱头）。

缓存能力，能够说 Webpack 的缓存利用率尚有优化空间。只管咱们能够通过 Split Chunk，正当的划分打包形式，但如果咱们只是改了一句文案，那么用户侧依然会从新获取对应 Chunk 资源。Snowpack 的缓存利用率近乎完满。业务代码文件产生变更，间接代替产出资源，其余全副可返回缓存；三方依赖包，如 react.js，则间接更新该包，其余全副可用缓存。不过，只管生产环境优化能够做 Tree-shaking，然而业务代码自身，Snowpack 并不会做解决（只是以 ESM 来看待），即便应用 Snowpack 生态的 Webpack 插件来做生产环境的构建也是如此，所以是近乎完满，这是绝对于现实的 DCE（dead code elimination）而言的。Webpack 在生产环境会把没有应用到的代码 Tree-shaking 掉，不堪称不弱小。

至于调试体验，因为 Webpack 须要打包，因而在调试的时候咱们依赖 SourceMap 来帮忙咱们看到源码。但对于 Snowpack 而言（实际上 Bundleless 模式都是如此），咱们并不强依赖于 SourceMap，如果转译后的代码浏览无碍（ES6 其实还好嘛），就能够间接进行单文件调试。

不过即便 Snowpack 有千番好，整个 Bundleless 生态还不足以取代 Webpack。Webpack 究竟是一代神器，只是咱们明确 Bundleless 也的确代表了将来。

⚡️Vite

Vite 是尤大的力作，本篇便不再对其进行探讨。乏味的是，他和 Webpack 作者 Sean 在推上的探讨能够看出，大佬们也在 Bundleless 方向一直发力，Webpack 成为了大家发动挑战的指标。

总结

本文以 Bundleless 为切入点，联合前端构建的倒退过程，对当下无构建计划进行了探讨。将来咱们会更多的在此方面进行实际。

文章可随便转载，但请保留此原文链接。
十分欢送有激情的你退出 ES2049 Studio，简历请发送至 caijun.hcj@alibaba-inc.com。