Vite与webapck 比较

一、对比分析

webpack会先打包，然后启动开发服务器，请求服务器 时直接给予打包结果。而vite是直接启动开发服务器， 请求哪个模块再对该模块进行实时编译。
由于现代浏览器本身就支持ES Module,会自动向依赖 的Module发出请求。vite充分利用这一点，将开发环境 下的模块文件，就作为浏览器要执行的文件，而不是像 webpack那样进行打包合并。
由于vite在启动的时候不需要打包，也就意味着不需要 分析模块的依赖、不需要编译，因此启动速度非常快。 当浏览器请求某个模块时，再根据需要对模块内容进行 编译。这种按需动态编译的方式，极大的缩减了编译时 间，项目越复杂、模块越多，vite的优势越明显。
在HMR （熟更新）方面，当改动了一个模块后，仅需 让浏览器重新请求该模块即可，不像webpack那样需要 把该模块的相关依赖模块全部编译一次，效率更高。
当需要打包到生产环境时，vite使用传统的rollup （也可 以自己手动安装webpack来）进行打包。因此，vite的 主要优势在开发阶段。另外，由于vite很利用的是ES Module,因此在代码中（除了 vite.config.js里面，这里 是node的执行环境）不可以使用CommonJS。

二、Webpack 与 vite 的思考

基于ES module的bundleless构建工具很火，比如 Vite,号称”下一代前端构建工具”。甚至一度有很多人认 为，有了 Vite之后就不再需要Webpack 了。虽然Vite 现在确实很火，也有很多人尝鲜，但现实恰好与大家的 观念相反，目前几乎没人把VM用于实际项目的开发。
2.1需要明确的问题：为什么Webpack需要打包？
其实主要有两点原因：
第一，在过去由于HTTP.L1受网络延迟和浏览器并行 请求限制等原因，将资源合并压缩有助于减少HTTP请 求从而提升页面性能。
第二，JavaScript本身并没有提供模块系统。曷然 Node.js中提供了 Commonjs的模块化机制，但是浏览器 环境并不支持。而且虽然ES2015标准中提供了语法层 面的模块化规范，但是现在仍然是implementation-defined 的状态，无论是Node.js还是浏览器均不支持（使 用babel还是会编译为Commonjs）。直到2017年 Chrome 61发布，浏览器才具有了对JavaScript Module 的原生支持。因此，使用Webpack显然好处不只是一点 点，不仅可以对静态资源打包压缩，还实现了一套模块 系统，另外还有各种loader、plugin,可以对打包的代码进行了 polyfill,还可以编译转换.less, . vue, . jsx等 在浏览器无法识别的文件格式，更重要的是提供了 HMR机制，极大的提升了开发体验。
2.2 另外，Webpack的痛点也需要知道
第一，由于Webpack在打包时需要构建模块依赖图，因此需要 递归遍历所有的模块，最明显的就是随着项目体积的增 长，构建时间也线性增长，启动时间也相应增加。
第二，当我们修改了其中的文件后，Webpack需要重新 打包。
第三，由于Webpack在打包后会对源码进行编译和压 缩，代码的可读性大大降低，因此在开发环境下，我们 需要借助SourceMap进行调试，而开始SourceMap无疑 会大大降｛氐打包速度。
第四，随着项目体积的增加，打包出来的包也越来越 大，过大的包会延长页面首屏加载时间，对此Webpack 也有解决方案，即使用Tree Shaking、 Lazy-loading、 ConimonsChunkPlugin 等。
2.3 现在为什么开始尝试不打包了？
首先最主要的原因是HTTP/2.0实现了多路复用和首部 压缩，解决了 HTTP11中队头阻塞的问题，因此通过 资源合并压缩减少了 HTTP请求对页面加载性能不会有 显著提升了。
其次，随着Chrome 61发布，现在各大浏览器逐一支持 ESM：直接浏览器便可解析imports,无需自己再实现模 块化优化了。通过浏览器原生ESM最大的好处就是可 以实现按需加载，不用打包了，构建时间复杂度为 0(1),启动很快，只需要启动devServer即可。
和Snowpack类似，Vite也是利用浏览器原生的ESM去 解析imports,然后向devServer请求模块，在服务器端 使用esbuild对模块进行即时编译后返回(主要是转 换.jsx, .tsx, .vue, .less等浏览器无法处理的文 件，而不是编译为ES5兼容老旧浏览器)。
2.4 Vite为什么使用esbuild进行编译
一个字：快！经过测试对比，同一个项目，Webpack5打 包需要54.5秒，而esbuild仅需0.37秒。这是因为 esbuild是用Golang编写的,自然比用JavaScript编写的 构建工具快很多。同时esbuild中的算法经过精心设计， 大量使用了并行操作，可以充分利用CPU资源。另外， esbuild没有使用第三方依赖，和内存高效利用，也是打包快的原因。
尽管esbuild优势十分明显，但是它仍然无法取代 Webpack ,主要有两点原因：第一，esbuild虽然有 loader ,但是没有插件机制；第二，esbuild没有热更 新。
2.5 Vite在esbuild的基础上解决了热更新的问题，是不是 就可以干掉Webpack 了?
前边提到过，现在把Vite用于实际项目开发的比较少。
首先第一个就是，虽然Vite在开发环境使用原生ESM, 但是在生产环境仍然需要使用Rollup打包。因为嵌套 import会导致发送大量网络请求，即使使用HTTP20 , 直接使用未打包的ESM仍然效率低下。所以为了在生 产环境中获得最佳的加载性能，最好将代码bundle 一遍
 （结合 Tree Shaking , lazy-loading 和 common chunk splitting等技术手段）。
所以现在看来，\'比更像是一个开发工具，而不是用于 生产环境的构建工具。另外，开发环境使用浏览器ESM 解析模块，而生产环境使用Rollup打包，这就导致本地 和线上环境跑的代码不一致，线上环境出了 bug,本地 很难排查。

综上，Vite其实和Vue-cli一样，可以说是Vue官方给个 人开发者和中小企业提供的脚手架工具，毕竟不用自己 造轮子了。正如Vue-ch就是对Webpack的封装一样， Vite其实就是对esbuild的封装，因此“Vite能干掉 Webpack”这句话本身就是不对等的，充其量作为下一代 脚手架工具还差不多。而且Vite现在还只能在开发环境 用ESM,生产环境还是需要打包，基本上只有浏览器 支持完全和基于QUIC协议的HTTP/3普及之后才可能 大规模使用ESM。更何况Webpack发展至今loader和 plugin生态已经十分丰富，而bundleless构建工具的生 态还在起步阶段。长远来看ESM确实极具发展潜力， 不排除以后bundleless构建工具可能会超过Webpack , 但是Webpack在现在的前端工程化中仍然扮演着非常重 要的角色。