本文转载自微信公众号“Tecvan”，作者范文杰。转载请联系Tecvan公众号。1、什么是Vite？2020年4月，有达发了这样一条推文：然后，2021年2月，Vite2.0来了，打出了一套组合拳：基于esbuild的极速开发体验。多框架支持兼容Rollup插件机制和APISSR支持老浏览器支持我一开始是拒绝的，从grunt，gulp，到Webpack，Rollup，Snowpack等几个知名的和不知名的构建框架，都在2021年了，还是来了？那就试试看，嗯，真香！2.Vite2.1的优点真的快Vite非常非常快，与Vue-cli（基于Webpack）相比：Dev启动时间Dev页面加载速度构建时间Vue-cli2568ms320ms5.14sVite232ms379ms2.39s示例代码：Vue3项目，10个组件测试。两者在运行dev命令上相差十倍。理论上，项目越大，性能差距越大。为什么？最大的原因是Vite在开发模式上没有做太多。多包操作！Webpack启动后会做很多事情。它将经历一个很长的编译和打包链。源码编译打包成低版本、高兼容的产品代码，充满了CPU和IO操作，Node运行起来性能肯定有问题。Vite在运行Dev命令后只做了两件事。一是启动一个托管资源服务的服务；另一种是使用esbuild预构建npm依赖包。之后一直躺在那里，直到浏览器通过http发送一个ESM规范的模块请求，Vite开始“按需编译”请求的模块。在这里，Vite默认的前提是：大多数现代浏览器都原生支持ESM规范，构建工具——尤其是在开发环境中，不需要为了低版本兼容而花费大量时间编译打包！在这个对比中，Webpack什么都做了，浏览器只需要运行编译好的低版本（es5）代码就可以了；vite只处理了一部分问题，剩下的由浏览器自己处理，所以速度必然TM快。除了跳过启动阶段的编译操作外，Vite还有很多值得一提的性能优化，整体总结一下：预编译：npm包等基本不会变化的模块，使用Esbuild打包整理在“pre-build”阶段减少http请求的数量按需编译：用户代码频繁更改类的模块直到使用时才会编译。客户端强缓存：请求的模块会被设置为强缓存，httpheadermax-age=31536000，不可变。如果模块发生变化，使用额外的版本查询使其失效产品优化：与Webpack相比，Vite直接锚定高版本浏览器，不需要在构建产品中插入过多的运行时和模板代码内置更好的分包实现方式：无需用户干预，默认开启一系列智能分包规则，最大限度减少模块重复打包。更好的静态资源处理：Vite尽量避免直接处理静态资源，而是选择遵循ESM方式提供服务，比如引入imagesimportimgfrom'xxx.png'语句，执行后img变量只是一个路径字符串。可见Vite的速度是全方位的，从Dev到Build，从npm包到项目源码，再到静态资源处理，各种优化措施都尽可能的在ESM的框架下实现规则，理论性能大大提高。2.2简单Vite的使用非常简单。执行初始化命令：yarncreate@vitejs/appmy-vue-app--templatevue会得到一个预设的开发环境，可以愉快的开始写demo了。Vite会给你一个Heap功能，包括css预处理器、html预处理器、hash命名、异步加载、分包、压缩、HMR等：这些功能是作者根据行业最佳实践预先设置的，通常不需要用户干预进行更改。Vite的性能很容易让人联想到vue-cli，但两者的区别还是挺大的：vue-cli的底层依赖于Webpack，而实际的构建工作通常是由各种Webpack加载器和插件来实现的，比如less=>css是通过less-loader实现的；图片加载是通过img-loader等实现的，这种设计非常灵活。你可以在Webpack体系下做任何你能想到的改动。你只需要学习一点Webpack的知识，包括几百个配置项，几千个插件，还有一些虚无缥缈的构造概念。Vite特别简洁，只暴露了极少量的配置项和插件接口，设计上无意让你做太多的自定义操作。..这是因为Vite一开始并没有打算再做一个Webpack，而是做了一套“可以显着提升前端开发体验的前端构建工具”，主打“开发体验”。同学们，Vite可以说是用心良苦。它很难，试图降低学习入门的成本，它不希望你为了使用工具而学习很多复杂而空灵的概念，希望这些东西在框架层面被挡住——虽然代价是损失的灵活性。简单来说，Vite的定位是一个傻瓜式但功能强大的构建工具。可以专心写业务代码，早点下班，再也不用为工具发愁了。2.3生态除了极致的运行性能和易用性，Vite与现有生态的兼容性也不容忽视，主要体现在两点：与Vue解耦，兼容React、Svelte、Preact、Vanilla等。这意味着Vite可以应用在大多数现代技术栈中，其插件接口与Rollup极其接近，这意味着Rollup生态中经过反复磨练的大部分工具都可以重复使用。说真的，这两件事摆在桌面上，再加上上面讨论的性能优势和超低的学习成本，我真的一时想不出拒绝的理由。..3.Vite的缺点Vite还是很新的。虽然它在理论和体验上提供了非常极致的开发体验，但仍然存在一些值得关注的问题。3.1兼容性默认情况下，dev和build都会直接输出ESM版本的代码包，这就需要客户端的浏览器版本比较新，在目前国情下还是有点难度的。不过，Vite也提供了一些补偿方式。使用build.polyfillDynamicImport配置项和@vitejs/plugin-legacy打包一个看起来更兼容的版本。我相信这会随着时间的推移而变得平缓。3.2缺少ShowCaseVite太新了，最近才发布2.0正式版。社区尚未对此作出反应。自然没有大规模复杂的商业实施案例。有多少陷阱谁也说不准。但好消息是，最近几个月社区对Vite的搜索量急剧增加：来自GoogleIndex的数据（https://trends.google.com/trends/explore?date=2021-01-01%202021-07-01&q=vite,webpack）相信很快就会有大量的布道者，毕竟这玩意儿真的很有竞争力。3.3不要忘记成本。工程本身的复杂性不会凭空消失。只有Vite背后的团队在帮助我们前进。对于Vite开发团队来说，维护这么多的构建规则是一个不小的负担。从用户的角度来看，更易于使用的工具通常意味着它们更难定制。另外，只是在Vite的预设框架里玩真的很简单，但是随着项目复杂度的增加，用户迟早还是会接触到底层的esbuild或者Rollup，以及高级工程师应该补充的知识迟早还是要补充的。回来吧，无处可逃。3、总结Vite给我最大的启示：Webpack不是标准答案，前端构建工具可以有一些新的玩法：“打包”不是目的，“运行”才是。2021年，浏览器能做什么就交给浏览器吧。灵活的框架对作者来说可能意味着逐渐失控的开发量；这可能意味着用户的学习成本很高，并且会反复争论空格好还是制表符好。好吧，一套内置了各种行业“最佳实践”且定制空间不大的工具，在某些情况下其实可以提高大家的效率。我个人对Vite的态度：短期保持观望，但长期非常乐观。相信现在开始学习Vite是一个不错的选择。这东西包装的很好，学习成本极低（吹的效果极好）。可以写一些demo或者直接在一些用户登陆可控的小新项目中。但是，建议不要直接对一些现有的大型项目进行彻底重构，也不要把自己埋在坑里。早点下班不是很好吗？
