Vite2 与Webpack

为什么是Vite2

在Vite2官网文档中，有这么一段话：

然而，当我们开始构建越来越大型的应用时，需要处理的 JavaScript 代码量也呈指数级增长。大型项目包含数千个模块的情况并不少见。我们开始遇到性能瓶颈 —— 使用 JavaScript 开发的工具通常需要很长时间（甚至是几分钟！）才能启动开发服务器，即使使用 HMR，文件修改后的效果也需要几秒钟才能在浏览器中反映出来。如此循环往复，迟钝的反馈会极大地影响开发者的开发效率和幸福感。

这就是为什么是Vite2的原因。

与webpack 比较

Webpack的HMR

第一次冷启动慢的原因：
在之前的浏览器中没有模块化的设计，所以期望把所有源代码编译进一个 js 文件中提供给浏览器使用，所以在开发中当我们运行启动命令的时候，webpack 总是需要从入口文件去索引整个项目的文件，编译成一个或多个单独的 js 文件，即使采用了代码拆分，也需要一次生成所有路由下的编译后文件（这也是为什么代码拆分对开发模式性能没有帮助）。这也导致了服务启动时间随着项目复杂度而指数增长。

webpack-dev-server的热更新：

1. 与本地服务器建立「socket」连接，注册 hash 和 ok 两个事件，发生文件修改时，给客户端推送 hash 事件。客户端根据 hash 事件中返回的参数来拉取更新后的文件。

2. HotModuleReplacementPlugin 会在文件修改后，生成两个文件，用于被客户端拉取使用。

在热更新上反映的就是部分代码变更， 整个模块的代码都需要重新编译，然后在推送更新。

Vite2的HMR

Vite 是基于 native ES module —— 浏览器厂商的不懈努力，现代浏览器基本已经全部支持了import/export 语法了。

在Vite中，启动服务器时，是不需要提交编译文件，而是在浏览器请求对应URL时，再提供文件，实施了真正的路由懒加载，这个比起Webpack就要节省了不少时间。

而在工程中不是所有的引用模块都是ES写法，可能是CommonJS 和 UMD 、AMD 等等，
这个时候Vite 会进行预构建，将其转换为ESM模块，以支持Vite。

并且将有许多内部模块的ESM依赖转换为单个模块，以提高后续页面加载性能。

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

esbuild

1. 使用 Go 编写，并且编译成了机器码
2. 大量使用并行算法
3. esbuild 的所有内容都是从零编写的,避免了不要的数据转换
4. 更有效利用内存

参考

Vite 官方中文文档

从零到一，带你彻底搞懂 vite 中的 HMR 原理（源码分析）

Vite2.0 正式发布，凭什么吊打 webpack ？