最近基于 ES module 的 bundleless 构建工具很火，特别是尤大在到处推广 Vite ，号称 “下一代前端构建工具”，在前不久的 VueConf 2021 上，尤大可谓狠狠地宣传了一下。以至于一度有很多人认为，有了 Vite 之后就不再需要 Webpack 了。虽然 Vite 现在确实很火，也有很多人在尝鲜，但现实恰好与大家的观念相反，目前几乎没人把 Vite 用于实际的项目开发。
首先先要先明确一个问题，为什么 Webpack 需要打包？个人认为主要有两点原因：
- 第一，在过去由于 HTTP/1.1 受网络延迟和浏览器并行请求限制等原因，将资源合并压缩有助于减少 HTTP 请求从而提升页面加载性能。
- 第二，JS 本身并没有提供模块系统。虽然 Node.js 中提供了 Common.js 的模块化机制，但是浏览器环境并不支持。而且虽然 ES2015 标准中提供了语法层面的模块化规范，但是现在仍然是 implementation-defined 的状态，无论是 Node.js 还是浏览器均不支持（使用 babel 还是会编译为 Common.js）。直到 2017 年 Chrome 61 发布，浏览器才具有了对 JavaScript Module 的原生支持。因此，使用 Webpack 显然好处不只是一点点，不仅可以对静态资源打包压缩，还实现了一套模块系统，另外还有各种 loader、plugin ，可以对打包的代码进行 polyfill ，还可以编译转换 .less 、.vue 、.jsx 等在浏览器无法识别的文件格式，更重要的是提供了 HMR 机制，极大地提升了开发体验。
当然 Webpack 的痛点也不少，由于 Webpack 在打包时需要构建模块依赖图，因此需要递归遍历所有的模块，
- 第一，最明显的就是随着项目体积的增长，构建的时间也线性增长，启动时间也相应增加。
- 第二，当我们修改了其中的文件之后，Webpack 需要重新打包。
- 第三，由于 Webpack 在打包后会对源码进行编译和压缩，代码的可读性大大降低，因此在开发环境下，我们需要借助 SourceMap 进行调试，而开启 SourceMap 无疑也会降低打包速度。
- 第四，随着项目体积增加，打出来的包也越来越大，过大的包会延长页面首屏加载时间，对此 Webpack 也有解决方案，即使用 Tree Shaking、lazy-loading、CommonsChunkPlugin 等。
# 那么为什么现在开始尝试不打包了？
首先最主要的原因是 HTTP/2.0 实现了多路复用和首部压缩，解决了 HTTP/1.1 中队头阻塞的问题，因此通过资源合并压缩减少 HTTP 请求对页面加载性能不会有显著提升了。其次，随着 Chrome 61 发布，现在各大浏览器逐一支持 ESM ，直接浏览器便可解析 imports ，无需自己再实现模块化了。通过浏览器原生 ESM 最大的好处就是可以实现按需加载，不用打包了，构建时间复杂度 O (1)，启动很快，只需要启动 devServer 即可。
和 Snowpack 类似，Vite 也是利用浏览器原生的 ESM 去解析 imports ，然后向 devServer 请求模块，在服务器端使用 esbuild 对模块进行即时编译后返回（主要是转换 .jsx 、.tsx 、.vue 、.less 等浏览器无法处理的文件，而不是编译为 ES5 兼容老旧浏览器）。
# 那么为什么 Vite 使用 esbuild 进行编译？
一个字：快！我们可以看一组对比，Webpack5 打包需要 54.5s，而 esbuild 仅需 0.37s。这是因为 esbuild 是用 Golang 编写的，自然比用 JS 编写的构建工具快很多。同时，esbuild 中的算法经过精心设计，大量使用了并行操作，可以充分利用 CPU 资源。另外，esbuild 没有使用第三方依赖，和内存的高效利用，也是打包快的原因。
尽管 esbuild 优势十分明显，但是它仍然无法取代 Webpack ，主要有两点原因：
- 第一，esbuild 虽然有 loader ，但是没有插件机制；
- 第二，esbuild 没有热更新。
那么 Vite 在 esbuild 的基础上解决了热更新的问题，是不是就可以干掉 Webpack 了。
# 现在回到开头那个问题，为什么现在几乎没人把 Vite 用于实际项目的开发？
首先一个就是，虽然 Vite 在开发环境使用原生 ESM，但是在生产环境仍然需要使用 Rollup 打包。因为嵌套 import 会导致发送大量网络请求，即使使用 HTTP/2.0 ，直接使用未打包的 ESM 仍然效率低下。所以为了在生产环境中获得最佳的加载性能，最好将代码 bundle 一遍（结合 Tree Shaking，lazy-loading 和 common chunk splitting 等技术手段）。
所以现在看来，Vite 更像是一个开发工具，而不是用于生产环境的构建工具。另外，开发环境使用浏览器 ESM 解析模块，而生产环境使用 Rollup 打包，这就导致本地和线上环境跑的代码不一致，线上环境出了 bug，本地很难排查。那有的同学会问，为什么 Vite 不用 esbuild 打包？esbuild 速度非常快，已经是一个非常强大的 Bundler，但一些构建应用所需的重要特性仍在开发中 —— 特别是 代码分割 和 CSS 处理 。目前，Rollup 在这些方面更加成熟和灵活。也就是说，当 esbuild 在将来稳定这些特性时，不排除在生产版本中使用 esbuild 的可能性。
综上，Vite 其实和 Vue-cli 一样，可以说是 Vue 官方给个人开发者和中小企业提供的脚手架工具，毕竟不用自己造轮子了。正如 Vue-cli 就是对 Webpack 的封装一样，Vite 其实就是对 esbuild 的封装，因此 “Vite 能干掉 Webpack” 这句话本身就是不对等的，充其量作为下一代脚手架工具还差不多。
而且 Vite 现在还只能在开发环境用 ESM ，生产环境还是需要打包，基本上只有浏览器支持完全和基于 QUIC 协议的 HTTP/3 普及之后才可能大规模使用 ESM 。更何况 Webpack 发展至今 loader 和 plugin 生态已经十分丰富，而 bundleless 构建工具的生态还在起步阶段。长远来看 ESM 确实极具发展潜力，不排除以后 bundleless 构建工具可能会超过 Webpack ，但是 Webpack 在现在的前端工程化中仍然扮演着非常重要的角色。
