❝ 全文 3000 字，热烈欢迎雅雷关注转贴
❞一、Vite 是什么
2020年4月，尤大幅发了这么两个推：
随即，2021年2月，Vite 2.0 它来了，上去就是两套杀手锏：
如前所述 esbuild实现的全速合作开发新体验多架构全力支持相容 Rollup 的应用程序监督机制与 APISSR 全力支持旧应用程序全力支持一已经开始我是婉拒的，从 grunt、gulp ，到 Webpack、Rollup、Snowpack 以及若干个著名不著名构筑框架，都2021了，还来？然后试玩了呵呵，嗯，是吗香！
二、Vite 的竞争优势
2.1 吗迅速
Vite 十分十分快，对照 Vue-cli(如前所述 Webpack)：
Dev 开启时数Dev 网页读取Build 时数Vue-cli2568ms320ms5.14sVite232ms379ms2.39s❝ 实例标识符：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 允诺数按需校对：用户标识符这一类频繁变动的模块，直至被使用TNUMBERV12V4会执行校对操作方式客户端强缓存：允诺过的模块会被以 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 的用法很简单， 执行初始化指示：
就得到了两个预设好的合作开发环境，可以已经开始愉快地写 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 配置项配合@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 或者就直接在一些用户范围可控的小型新工程项目落地。但是，建议不要激进地直接重构一些已有的大型工程项目，别自己给自己埋坑了，早点下班不香吗。
