一、前语前端工程领域最近一年出了不少新的工具，这些新工具都运用了一些新技术或者跨领域技术，在性能上实现了一些突破，为开发者带来更快更好用的开发体验。 二、背景在浏览器支持原生 ES 模块之前，JavaScript 并没有提供的原生机制让开发者以模块化的方式进行开发。于是Webpack、Rollup等构建式打包工具应运而生，它们极大地改善了前端开发者的开发效率。 但随着我们的应用不断迭代，我们需要处理的 JavaScript 代码量也呈指数级增长，包含数千个模块的大型项目相当普遍。 随着应用的迭代，我们开始遇到性能瓶颈 —— 使用 JavaScript 开发的工具通常需要等80s+甚至更长时间才能启动开发服务器。 启动开发服务器后即使使用了 HMR(Hot Module Replacement)，文件修改后的效果也需要等待几秒钟才能在浏览器中反映出来。 如此循环往复，迟钝的反馈会极大地影响开发者的开发效率以及体验。 三、关于viteVite[1]是一种全新的前端构建工具。你可以把它理解为一个开箱即用的开发服务器 + 打包工具的组合，但是更轻更快。Vite 利用浏览器原生支持的 ES 模块和用编译到原生的语言开发的工具(esbuild)[2]来提供一个快速且现代的开发体验。 Vite主要具有以下特点:
四、vite相较于webpcak的优缺点
Webpack 等传统的构建式打包工具，在冷启动开发服务器时，首先都会将我们的整个代码库中的源代码和node_modules进行转换、编译(Babel、PostCSS...)和打包，最终将打包好的文件推送到我们的浏览器。 vite、snowpack这类非构建式打包工具，在冷启动开发服务器时，无需分析模块依赖，也不需要编译，通过ES Module 自动向依赖的资源发出请求，因此启动速度非常快。当浏览器请求某个模块时，再根据需要对模块内容进行编译。这种按需动态编译的方式，极大的缩减了编译时间，项目越复杂、模块越多，非构建式打包工具的优势越明显。 
在 Webpack 中，当代码某个依赖发生了改变，webpcak 会检查当前的依赖关系并重新打包，当我们的依赖关系复杂时，就算只修改一个文件，热更新的速度也会越来越慢。在实践中我们发现，即使是 HMR ，更新速度会随着应用规模的增长而显著下降。 在 Vite 中，HMR 是在原生 ESM 上执行的。当编辑一个文件时，Vite 只需要精确地使已编辑的模块与其最近的 HMR 边界之间的链失效（大多数时候只需要模块本身），使 HMR 更新始终快速，无论应用的大小。同时 Vite 利用 HTTP 来加速整个页面的重新加载，对于源码模块的请求会根据 304 状态码进行协商缓存，而外部依赖模块的请求则会设置为强缓存，因此一旦被缓存它们将不需要再次请求。  
video link (twitter)
生态这一块，Webpack 相较于 Vite 优势明显，Webpcak 的社区中有非常丰富的loader和plugin，Vite这边插件社区起步较晚，插件数量会比较少； 好在，Vite 插件开发起来非常简单。Vite 在插件设计上扩展了 Rollup 的插件接口，开发者通过阅读 Rollup 的插件文档，很快就能开发出标准的 Vite 插件了。
在构建这块，Vite 在开发服务器与产品最终构建结果没有 Webpack 一致性强。 主要原因是我们为了在生产环境获得最佳的加载性能和兼容性，还是需要将代码进行tree-shaking、懒加载和 chunk 分割（以获得更好的缓存），所以 Vite 选择了 Rollup[3] 进行产品最终构建打包。 五、vite在vue中的使用姿势
六、标注
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
