why vite
简洁版
vite在开发环境优势的根本原因：浏览器对es Modules的支持和esBuild的强大。
打包工具在开发环境下有两个缺点：1.启动慢，1.更新慢。
1.vite将项目分为依赖部分和源码部分，通过esBuild预打包依赖，源码在屏幕需要的时候再加载。
2.通过浏览器对原生esModules的支持，优化了HMR;使用HTTP头对源码使用协商缓存，对依赖使用清缓存。
vite之前，所面临的问题：
在es模块在浏览器中还不可用的时候，前端开发人员缺少模块化编写JavaScript的原生方式。但developer依然可以以模块化的方式编写JavaScript代码，因为有webpack，Rollup和Parcell这样的打包工具，它们极大提升了开发人员的开发体验。
打包工具的问题：慢：
启动慢： 大项目中，modules可能成千上万，打包起来甚至要几分钟的等待时间；
更新慢： 即使使用了“热更新”，代码的变化可能也要几秒中后才反映出来。
vite的解决办法
vite通过前端生态系统中的两项新进展来解决问题：ES modules在浏览器中的支持 和 新JavaScript工具的兴起。
对于启动慢：
原因： 冷启动开发服务器时，打包工具不得不打包好整个app；
解决办法： vite先把要打包的app划分为2个部分：依赖 和 源码
依赖部分
因为依赖是稳定的，基本不再变化的，依赖可能会很大，且使用不同的模块化规则。vite使用esBuild预打包依赖。esBuild的打包速度是其他打包工具的10到100倍。
源码部分
源码经常调整，并且不一定要一次性全部提供，可以按需加载；由于浏览器能够支持es modules，所以vite通过原生es modules提供源码；另外，vite只在需要的时候转译和提供源码，在当前屏幕需要的时候才会有条件的导入。
对于更新慢
修改app的部分模块后，再次打包整个应用明显是是很不划算的；于是一些打包工具有了HMR（hot modules replacement）,只将变化的部分更新，而不影响其他部分；在时间中，我们发现，HMR的速度也会因为app的体积变大而降低。
而vite中，HMR通过es modules实现，它精准得将变化的模块和HMR边界之间的“chain”失效，使更新速度与app大小无关。
vite还通过HTTP头提高了整个页面重新加载的速度：对于源码，使用协商缓存；对于依赖，使用强缓存（浏览器又承担了一些工作）
生产环境下依然要打包
生产模式下如果不打包，那么多模块，将会有大量的网络请求。所以依然需要打包工具的一些功能来提升性能：tree-shaking,lazy-loading,common chunk splitting(为了缓存)
为什么不用esBuild打包？
esBuild虽然发展迅速，打包库的能力非常强；但它在代码分割和css处理方面尚有不足；之所以用Rollup，是因为它在这方面更加成熟和灵活。 也就是说，未来不排除用esModules.
