全文 3000 字，欢送点赞关注转发

一、Vite 是什么

2020 年 4 月，尤大大发了这么一个推：

随后，2021 年 2 月，Vite 2.0 它来了，上来就是一套组合拳：

• 基于 esbuild 实现的极速开发体验
• 多框架反对
• 兼容 Rollup 的插件机制与 API
• SSR 反对
• 旧浏览器反对

一开始我是回绝的，从 grunt、gulp，到 Webpack、Rollup、Snowpack 以及若干出名不出名构建框架，都 2021 了，还来？而后试用了一下，嗯，是真的香！

二、Vite 的劣势

2.1 真 TM 快

Vite 十分十分快，比照 Vue-cli(基于 Webpack)：

示例代码：Vue3 我的项目，10 个组件

测试两者的 dev 命令运行耗时相差十倍，且实践上，我的项目越大性能差距越大，为什么呢？最大的起因是 Vite 在开发模式下并没有做太多打包操作！

Webpack 启动后会做一堆事件，经验一条很长的编译打包链条，从入口开始须要逐渐经验语法解析、依赖收集、代码转译、打包合并、代码优化，最终将高版本的、离散的源码编译打包成低版本、高兼容性的产物代码，这可满满都是 CPU、IO 操作啊，在 Node 运行时下性能必然是有问题。

而 Vite 运行 Dev 命令后只做了两件事件，一是启动了一个用于承载资源服务的 service；二是应用 esbuild 预构建 npm 依赖包。之后就始终躺着，直到浏览器以 http 形式发来 ESM 标准的模块申请时，Vite 才开始“按需编译”被申请的模块。

这里 Vite 预设的前提是：

• 古代浏览器大多数曾经原生反对 ESM 标准，构建工具 —— 特地是开发环境下曾经没有太大必要为了低版本兼容把大量的工夫花在编译打包上了！

这么一比照，Webpack 是啥都做了，浏览器只有运行编译好的低版本 (es5) 代码就行；而 Vite 只解决问题的一部分，剩下的事件交由浏览器自行处理，那速度必然贼 TM 快。

除了启动阶段跳过编译操作之外，Vite 还有很多值得一提的性能优化，整体梳理一下：

• 预编译：npm 包这类根本不会变动的模块，应用 Esbuild 在 预构建 阶段先打包整顿好，缩小 http 申请数
• 按需编译：用户代码这一类频繁变动的模块，直到被应用时才会执行编译操作
• 客户端强缓存：申请过的模块会被以 http 头 max-age=31536000,immutable 设置为强缓存，如果模块发生变化则用附加的版本 query 使其生效
• 产物优化：相比于 Webpack，Vite 间接锚定高版本浏览器，不须要在 build 产物中插入过多运行时与模板代码
• 内置更好的分包实现：不须要用户干涉，默认启用一系列智能分包规定，尽可能减少模块的反复打包
• 更好的动态资源解决：Vite 尽量避免间接解决动态资源，而是抉择遵循 ESM 形式提供服务，例如引入图片 import img from 'xxx.png' 语句，执行后 img 变量只是一个门路字符串。

能够看出，Vite 的快是全方位的，从 Dev 到 Build，从 npm 包到我的项目源码，再到动态资源解决都在 ESM 规定框架下尽可能地实现各种优化措施，实践性能急剧晋升。

2.2 简略

Vite 的用法很简略，执行初始化命令：

yarn create @vitejs/app my-vue-app --template vue

就失去了一个预设好的开发环境，能够开始欢快地写 demo 了，Vite 开箱就给你一堆性能，包含 css 预处理器、html 预处理器、hash 命名、异步加载、分包、压缩、HMR 等：

这些性能，作者都按行业最佳实际预设好了，通常不须要用户染指做变更。

Vite 的体现很容易让人联想到 vue-cli，不过两者区别还是挺大的：vue-cli 底层依赖 Webpack，理论的构建工作通常由各种 Webpack loader、plugin 实现，比方 less => css 由 less-loader 实现；图片加载由 img-loader 实现等。这套设计很灵便，你能够在 Webpack 体系下做任何你能想到的变更，只须要学习一点点 Webpack 的常识，包含百来个配置项、成千上万的插件、若干扑朔迷离的构建概念等。

而 Vite 显得特地简洁，它只是裸露了极少数的配置项与 plugin 接口，设计上就没打算让你做太多自定义操作。。。这是因为 Vite 从一开始就没打算做成另一个 Webpack，而是做成一套“可能显著晋升前端开发体验的前端构建工具”，重在 开发体验 啊同学们，Vite 堪称是用心良苦，想尽办法升高学习入门老本，它就不心愿你为了应用工具又学一大堆简单、缥缈的概念，心愿这些事件都在框架层面屏蔽了 —— 尽管代价是丢失灵活性。

简略说吧，Vite 定位就是傻瓜式但弱小的构建工具，你分心写好业务代码，早点上班，不必再为了工具劳神费劲了。

2.3 生态

除了极致的运行性能与繁难的应用办法外，Vite 对已有生态的兼容性也不容疏忽，次要体现在两个点：

• 与 Vue 解耦，兼容反对 React、Svelte、Preact、Vanilla 等，这意味着 Vite 能够被利用在大多数古代技术栈中
• 与 Rollup 极其靠近的插件接口，这意味着能够复用 Rollup 生态中大部分曾经被重复锻炼的工具

说真的，这两条摆上桌面，加上后面探讨的性能劣势和超低学习老本，一时半会真想不到回绝的理由了。。。

三、Vite 的劣势

Vite 还很新，尽管它从实践与体感上提供了十分极致的开发体验，还是有一些值得关注的问题。

3.1 兼容性

默认状况下，无论是 dev 还是 build 都会间接打出 ESM 版本的代码包，这就要求客户浏览器须要有一个比拟新的版本，这放在当初的国情下还是有点难度的。

不过 Vite 同时提供了一些补救的办法，应用 build.polyfillDynamicImport 配置项配合 [](https://github.com/vitejs/vit… \@vitejs/plugin-legacy 打包出一个看起来兼容性比拟好的版本，我置信这一点会随工夫缓缓被抹平。

3.2 短少 Show Case

Vite 太新了，直到最近才开释出正式 2.0 版本，社区还没太反馈过去，天然也就没什么大型、简单的商业落地案例，谁都说不准这外面可能有多少坑。

不过好消息是社区对 Vite 的搜寻热度在最近几个月急剧增长：

数据来自谷歌指数

置信很快就会呈现一大批布道者，毕竟这玩意儿是真的很有竞争力。

3.3 代价

不要遗记，工程化自身的复杂度不会凭空隐没，只 Vite 背地的团队在帮咱们负重前行，这对 Vite 开发团队而言，保护这么多构建规定是一个不小的累赘。而站在用户的角度，越容易上手的工具往往意味着越难被定制。

另外，如果只是在 Vite 预设好的边框外面玩的确很容易，但随着我的项目复杂度的进步，用户迟早还是会接触到底层的 esbuild 或 Rollup，高工们该补的常识还是迟早还是得补回来，逃不掉的。

三、总结

Vite 给我最大的启发：Webpack 并不是标准答案，前端构建工具能够有一些新的玩法：

• 打包 不是目标， 运行 才是，2021 年了，可能交给浏览器做的事件就交给浏览器吧
• 一个灵便的框架，对作者而言可能意味着逐渐失控的开发量；对用户而言可能象征高学习老本，以及一直反复的相似空格好还是 tab 好的争执。那么，一套内置好各种业界 最佳实际，没有太多定制空间的工具，某些状况下反而能晋升大家的效率

我集体对 Vite 的态度：短期放弃张望，长期十分看好。

我置信当初开始上手学习 Vite 是一个不错的抉择，这货色封装的太好了，学习老本极低(吹逼成果极好)，能够写点 Demo 或者就间接在一些用户范畴可控的小型新我的项目落地。然而，倡议不要激进地间接重构一些已有的大型项目，别本人给本人埋坑了，早点上班不香吗。