关于vue.js:Vue-Conf关于Vite的分享给我带来的启发

Vite在去年就曾经进去了，但我真正的去理解它却是在最近 Vue Conf 上李奎对于 Vite: 下一代 web 工具 的分享。其中他提到的几点吸引到了我。分享的开始，他简要阐明了本次分享的关键点：

其中的 ESM 和esbuild会在下文具体阐明

接下来他提到了 Bundle-Based Dev Server。也就是咱们始终在用的webpack 的解决形式：

这里援用官网的一段话：

当咱们开始构建越来越大型的利用时，须要解决的 JavaScript 代码量也呈指数级增长。大型项目蕴含数千个模块的状况并不少见。咱们开始遇到性能瓶颈 —— 应用 JavaScript 开发的工具通常须要很长时间（甚至是几分钟！）能力启动开发服务器，即便应用 HMR，文件批改后的成果也须要几秒钟能力在浏览器中反映进去。如此周而复始，机灵的反馈会极大地影响开发者的开发效率和幸福感。

简略总结下就是，如果利用比较复杂，应用 Webpack 的开发过程绝对没有那么丝滑：

• Webpack Dev Server冷启动工夫会比拟长
• Webpack HMR热更新的反应速度比较慢

这就是 Vite 呈现的起因，你能够把它简略了解为：No-Bundler构建计划。其实正是利用了浏览器原生 ESM 的能力。

但首次提出利用浏览器原生 ESM 能力的工具并非是 Vite，而是一个叫做Snowpack 的工具。当然本文不会开展去比照 Vite 与它的区别，想理解的可戳 Vite 与 X 的区别是？

到这里，我不禁开始去想一个问题：为什么 Vite 这个工具能够呈现，他又是基于哪些前提条件呢？

带着这个问题，联合分享和 Vite 的源码以及社区的一些文章，我发现了如下几个与 Vite 能够呈现密不可分的模块：

• ES Modules
• HTTP2
• ESBuild

这几块其实本人都听过，然而具体的细节也都没有深刻去理解。明天正好去深刻分析一下。

ES Modules

在古代前端工程体系中，咱们其实始终在应用ES Modules：

import a from 'xxx'
import b from 'xxx'
import c from 'xxx'

可能是过于平时化，大家早已司空见惯。但如果没有很深刻的理解ES Modules，那么可能对于咱们了解现有的一些轮子（比方本文的Vite），会有一些妨碍。

ES Modules是浏览器原生反对的模块零碎。而在之前，罕用的是 CommonJS 和基于 AMD 的其余模块零碎 如 RequireJS。

来看下目前浏览器对其的反对：

支流的浏览器（IE11 除外）均曾经反对，其最大的特点是在浏览器端应用 export、import的形式导入和导出模块，在 script 标签里设置 type="module"，而后应用模块内容。

下面说了这么多，毕竟也只是 ES Modules 的自我介绍 。始终以来，他就像 黑盒 一样，咱们并不分明外部的执行机制。上面就让咱们来一窥到底。

咱们先来看一下模块零碎的作用：传统 script 标签的代码加载容易导致全局作用域净化，而且要维系一系列 script 的书写程序，我的项目一大，保护起来越来越艰难。模块零碎通过申明式的裸露和援用模块使得各个模块之间的依赖变得显著。

当你在应用模块进行开发时，其实是在构建一张 依赖关系图。不同模块之间的连线就代表了代码中的导入语句。

正是这些导入语句通知浏览器或者 Node 该去加载哪些代码。

咱们要做的是为依赖关系图指定一个入口文件。从这个入口文件开始，浏览器或者 Node 就会顺着导入语句找出所依赖的其余代码文件。

对于 ES 模块来说，这次要有三个步骤：

• 结构。查找、下载并解析所有文件到模块记录中。
• 实例化。在内存中寻找一块区域来存储所有导出的变量（但还没有填充值）。而后让 export 和 import 都指向这些内存块。这个过程叫做链接（linking）。
• 求值。运行代码，在内存块中填入变量的理论值。

结构阶段（Construction）

在结构阶段，每个模块都会经验三件事件：

• Find：找出从哪里下载蕴含该模块的文件（也称为模块解析）
• Download：获取文件（从 URL 下载或从文件系统加载）
• Parse：将文件解析为模块记录

Find 查找

通常咱们会有一个主文件 main.js 作为所有的开始：

<script src="main.js" type="module"></script>

而后通过 import 语句去引入其余模块所导出的内容：

import 语句中的一部分称为 Module Specifier。它通知 Loader 在哪里能够找到引入的模块。

对于模块标识符有一点须要留神：它们有时须要在浏览器和 Node 之间进行不同的解决。每个宿主都有本人的解释模块标识符字符串的形式。

目前在浏览器中只能应用 URL 作为 Module Specifier，也就是应用 URL 去加载模块。

Download 下载

而有个问题也随之而来，浏览器在解析文件前并不知道文件依赖哪些模块，当然获取文件之前更无奈解析文件。

这将导致整个解析依赖关系的流程是阻塞的。

像这样阻塞主线程会让采纳了模块的应用程序速度太慢而无奈应用。这是 ES 模块标准将算法分为多个阶段的起因之一。将结构过程独自分离出来，使得浏览器在执行同步的初始化过程前能够自行下载文件并建设本人对于模块图的了解。

对于 ES 模块，在进行任何求值之前，你须要当时构建整个模块图。这意味着你的模块标识符中不能有变量，因为这些变量还没有值。

但有时候在模块门路应用变量的确十分有用。例如，你可能须要依据代码的运行状况或运行环境来切换加载某个模块。

为了让 ES 模块反对这个，有一个名为 动静导入 的提案。有了它，你能够像 import(${path} /foo.js 这样应用 import 语句。

它的原理是，任何通过 import() 加载的的文件都会被作为一个独立的依赖图的入口。动静导入的模块开启一个新的依赖图，并独自解决。

Parse 解析

实际上解析文件是有助于浏览器理解模块内的形成，而咱们把它解析进去的模块形成表 称为 Module Record 模块记录。

模块记录蕴含了以后模块的 AST，援用了哪些模块的变量，以前一些特定属性和办法。

一旦模块记录被创立，它会被记录在模块映射 Module Ma 中。被记录后，如果再有对雷同 URL 的申请，Loader 将间接采纳 Module Map 中 URL 对应的Module Record。

解析中有一个细节可能看起来微不足道，但实际上有很大的影响。所有的模块都被当作在顶部应用了 "use strict" 来解析。还有一些其余细微差别。例如，关键字 await 保留在模块的顶层代码中，this 的值是 undefined。

这种不同的解析形式被称为 解析指标。如果你应用不同的指标解析雷同的文件，你会失去不同的后果。所以在开始解析前你要晓得正在解析的文件的类型：它是否是一个模块？

在浏览器中这很容易。你只需在 script 标记中设置 type="module"。这通知浏览器此文件应该被解析为一个模块。

但在 Node 中，是没有 HTML 标签的，所以须要其余的形式来分别，社区目前的支流解决形式是批改文件的后缀为 .mjs，来通知 Node 这将是一个模块。不过还没有标准化，而且还存在很多兼容问题。

到这里，在加载过程完结时，从一般的主入口文件变成了一堆模块记录 Module Record。

下一步是实例化此模块并将所有实例链接在一起。

实例化阶段

为了实例化 Module Record，引擎将采纳 Depth First Post-order Traversal(深度优先后序)进行遍历，JS引擎将会为每一个 Module Record 创立一个 Module Environment Record 模块环境记录，它将治理 Module Record 对应的变量，并为所有 export 分配内存空间。

ES Modules 的这种连贯形式被称为 Live Bindings（动静绑定）。

之所以 ES Modules 采纳 Live Bindings，是因为这将有助于做动态剖析以及躲避一些问题，如循环依赖。

而 CommonJS 导出的是 copy 后的 export 对象，这意味着如果导出模块稍后更改该值，则导入模块并不会看到该更改。

这也就是通常所见到的论断：CommonJS 模块导出是值的拷贝，而 ES Modules 是值的援用。

求值阶段（evaluate）

最初一步是在内存中填值。还记得咱们通过内存连贯好了所有 export 和 import吗，但内存还尚未有值。

JS 引擎通过执行顶层代码（函数之外的代码），来向这些内存区添值。

至此 ES Modules 的黑盒我就大抵剖析完了。

当然这部分我是参考了 es-modules-a-cartoon-deep-dive，而后联合本人的了解得出的剖析，想更深刻理解其背地实现，可狠狠戳下面的链接。

ES Modules在 Vite 中的体现咱们能够关上一个运行中的 Vite 我的项目：

从上图能够看到：

import {createApp} from "/node_modules/.vite/vue.js?v=2122042e";

与以往的 import {createApp} from "vue" 不同，这里对引入的模块门路进行了重写：

Vite利用古代浏览器原生反对 ESM 个性，省略了对模块的打包。(这也是开发环境下我的项目启动和热更新比拟快的很重要的起因)

HTTP2

来看 HTTP2 前，咱们先来理解一下 HTTP 的发展史。

咱们晓得 HTTP 是浏览器中最重要且应用最多的协定，是浏览器和服务器之间的通信语言。随着浏览器的倒退，HTTP为了能适应新的模式也在继续进化。

最开始呈现的 HTTP/0.9 实现绝对较为简单：采纳了基于申请响应的模式，从客户端发出请求，服务器返回数据。

从图中能够看出其只有一个申请行且服务器也没有返回头信息。

万维网的高速倒退带来了很多新的需要，而 HTTP/0.9 曾经不能实用新兴网络的倒退，所以这时就须要一个新的协定来撑持新兴网络，这就是 HTTP/1.0 诞生的起因。

并且在浏览器中展现的不单是 HTML 文件了，还包含了 JavaScript、CSS、图片、音频、视频等不同类型的文件。因而反对多种类型的文件下载是 HTTP/1.0 的一个外围诉求。

为了让客户端和服务器能更深刻地交换，HTTP/1.0 引入了申请头和响应头，它们都是以 Key-Value 模式保留的，在 HTTP 发送申请时，会带上申请头信息，服务器返回数据时，会先返回响应头信息。HTTP/1.0 具体的申请流程能够参考下图：

HTTP/1.0 每进行一次 HTTP 通信，都须要经验建设 TCP 连贯、传输 HTTP 数据和断开 TCP 连贯三个阶段。在过后，因为通信的文件比拟小，而且每个页面的援用也不多，所以这种传输模式没什么大问题。然而随着浏览器遍及，单个页面中的图片文件越来越多，有时候一个页面可能蕴含了几百个内部援用的资源文件，如果在下载每个文件的时候，都须要经验建设 TCP 连贯 、 传输数据 和断开连接 这样的步骤，无疑会减少大量无谓的开销。

为了解决这个问题，HTTP/1.1 中减少了 长久连贯 的办法，它的特点是在一个 TCP 连贯上能够传输多个 HTTP 申请，只有浏览器或者服务器没有明确断开连接，那么该 TCP 连贯会始终放弃。并且浏览器中对于同一个域名，默认容许同时建设 6 个 TCP 长久连贯。

通过这些形式在某种程度上大幅度提高了页面的下载速度。

之前咱们应用 Webpack 打包利用代码，使之成为一个 bundle.js，有一个很重要的起因是：零散的模块文件会产生大量的HTTP 申请。而大量的 HTTP 申请在浏览器端就会产生并发申请资源的问题：

如上图所示，红色圈起来的局部的申请就是并发申请，然而前面的申请就因为域名连接数已超过限度，而被挂起期待了一段时间。

在 HTTP1.1 的规范下，每次申请都须要独自建设 TCP 连贯，通过残缺的通信过程，十分耗时。之所以会呈现这个问题，次要是由以下三个起因导致的：

• TCP的慢启动
• TCP连贯之间相互竞争带宽
• 队头阻塞

前两个问题是因为 TCP 自身的机制导致的，而队头阻塞是因为 HTTP/1.1 的机制导致的。

为了解决这些已知问题，HTTP/2的思路就是 一个域名只应用一个 TCP 长连贯来传输数据，这样整个页面资源的下载过程只须要一次慢启动，同时也防止了多个 TCP 连贯竞争带宽所带来的问题。

也就是常说的 多路复用，它能实现资源的并行传输。

上文中也提到了 Vite 应用 ESM 在浏览器里应用模块，就是应用 HTTP 申请拿到模块。这样就会产生大量的 HTTP 申请，但因为HTTP/2 的多路复用 机制的呈现，很好的解决了传输耗时久的问题。

ESBuild

esbuild官网的介绍：它是一个 JavaScript Bundler 打包和压缩工具，它能够将JavaScript 和TypeScript代码打包散发在网页上运行。

esbuild底层应用的 golang 进行编写的，在比照传统 web 构建工具的打包速度上，具备显著的劣势。编译 Typescript 的速度远超官网的tsc。

对于 JSX、或者TS 等须要编译的文件，Vite 是用 esbuild 来进行编译的，不同于 Webpack 的整体编译，Vite是在浏览器申请时，才对文件进行编译，而后提供给浏览器。因为 esbuild 编译够快，这种每次页面加载都进行编译的其实是不会影响减速速度的。

Vite 实现原理

联合下面的剖析和源码，能够用一句话来简述 Vite 的原理：Static Server + Compile + HMR：

• 将以后我的项目目录作为动态文件服务器的根目录

• 拦挡局部文件申请

  • 解决代码中 import node_modules 中的模块
  • 解决 vue 单文件组件 (SFC) 的编译
• 通过 WebSocket 实现HMR

当然对于相似 手写 Vite 实现 的文章社区曾经有很多了，这里就不赘述了，大抵原理都是一样的。

总结

本文写完带给我更多的是一些思考。从一次分享去挖掘其背地宏大的生态体系以及那些咱们始终在用却并未深刻理解的 技术黑盒。

更多的是，感叹大佬们的想法，站在技术的制高点，领有较高的深度和广度，开发一些对于进步生产力极其有用的轮子。

所以，文章写完了，学习的步调任在后退～

参考

• https://hacks.mozilla.org/201…
• https://github.com/evanw/esbuild
• 极客工夫 / 罗剑锋 / 透视 HTTP 协定