2-为什么选用Vite原创

在使用wait之前，你可能一直想问一个问题，为什么要使用weight？它比web派强在哪里呢？带着这个问题，我们先来看看wait是什么。Wait，法语的意思是快速的，发音是V，它是一种新型的前端构建工具，能够显著的提升我们前端开发者的体验。它主要有两部分组成，一个开发服务器，它基于原生的ES模块，提供了丰富的内建功能。如速度快到惊人的模块热更新HR，它提供一套构建指令，使用up打包你的代码，并且它是预构建的可输出用于生产环境的高度优化过的静态资源。VTE只在提供开箱即用的配置，但同时它也提供插件API和javascript API带来高度的可扩展性，并且有完整的类型支持。

那了解了什么是V？接下来我们就来回答为什么选择使用V。在浏览器支持ES模块之前，Javascript并没有提供原生的机制让我们开发者以模块化的方式进行开发，这也正是我们对打包这个概念熟悉的原因。打包的工作具体就是使用工具抓取处理，并将我们的源代码模块串联成可以在浏览器中运行的文件。时过境迁，我们已经见证了很多这样的打包工具，比如外PE roll up parcel等这样的工具，他们极大的改善了我们前端开发者的开发体验。然而，当我们开始构建越来越大型的应用的时候，需要处理的javascript代码量也呈指数级增长，包含数千个模块的大型项目相当的普遍。我们开始遇到了性能瓶颈，也就是使用javascript的开发工具通常需要很长时间甚至到几分钟才能启动我们的开发服务器。

即使我们使用了HR文件，修改后的效果也需要几秒钟以后在浏览器中才能反应出来。如此循环往复，迟钝的反馈极大的影响了我们开发者的开发效率和开发幸福感。那具体表现在缓慢的服务器启动以及缓慢的更新两个方面。我们先来分析一下传统的打包方式为什么服务器启动慢，当我们做冷启动开发服务器的时候，这里有一张官网给的示意图。它是基于打包器的方式来启动的，它必须优先抓取、构建我们的整个应用，才能提供服务。这个问题呢，主要体现在依赖和源码两个方面。依赖方面，大多数的依赖都是在开发的时候不变动的一些纯的javascript代码，并且一些较大的依赖处理代价也很高，例如有上百个模块组件库，那依赖也通常存在多种模块化的格式，比如ESM或者是common JS这样的格式等等。

从源码，我们的业务源码通常包含一些并不是纯的javascript文件，这些文件可能还需要转化时长呢，还要被编辑。比如GSXCSX或者是view re组件。同时，并不是所有的源码都需要同时的被加载，例如基于路由的拆分的代码模块。那传统的打包器需要构建整个应用，这种对依赖和源码的处理方式势必会导致服务器启动缓慢。那接下来我们再分析一下更新慢的原因，基于打包器启动时重建整个包的效率是很低的，原因也显而易见，因为这样更新速度会随着应用体积的增长而直线的下降。一些打包器的开发服务器将构建内容存入内存，比如外派就是这样处理的。这样呢，他们只需要在文件更改的时候使模块的一部分失活。

但它仍需要整个重新构建并重载页面，这样的代价是很高的，并且重新加载页面也会消除应用的当前状态。所以打包器支持了动态模块热重载，也就是我们熟知的HR，它允许一个模块热替换它自己，而不会影响页面的其余部分。这就大大的改进了开发体验，比如外派DV server就提供了HR这样的功能。然而在实践中我们发现，即使采用了HR这种模式，其热更新的速度也会随着应用规模的增长而显著的下降。那我们来看看V是如何实现快速的服务器启动以及快速的更新的。V是利用生态系统中的新进展来解决上述问题的，也就是浏览器开始原生的支持ES模块，并且越来越多的javascript工具使用编译型的语言来编写。关于快速的服务器启动，官网也给了一张示意图，Wait通过在一开始就将应用中的模块区分为依赖和源码两类，改进了开发服务器的启动时间。wait将会使用ES build来构建依赖ES6的使用构语言来编写，并且比javascript编写的打包器预构建的依赖快十到100倍。

另外，Waitte以原生的ESM方式提供源码，这实际上是让浏览器接管了打包程序的部分工作。waitte只需要在浏览器请求源码的时候进行转换，并按需提供源码，根据场景动态的导入代码，也就是只在当前屏幕上实际使用时才会被处理。在快速更新方面，VT的HMMR是在原生的ESM上执行的，当编辑一个文件的时候，VT只需精确的使以编辑的模块与其最近的HML边界之间的链失火。是的，无论应用大小如何，HML始终保持快速更新，因为大多数的时候只是模块本身被更新了而已。

Wait同时利用HTTP头来加速整个页面的重新加载。源码模块的请求会根据304来进行协商缓存，而依赖模块的请求会通过catch control来进行强缓存，因此一旦被缓存，他们将不需要再次请求，说白了就是再次让浏览器为我们做更多的事情。那一旦你体验到为的神速，你是否还愿意再忍受像曾经那样的打包器来开发项目呢？这就要打上了一个大大的问号了。以上我们介绍了在开发环境中，我们懂得了为啥要选择使用weight，那在生产环境下呢？我们还得回答两个问题。问题一，为什么生产环境仍需要打包呢？也就是说，生产环境能不能直接使用开发环境的玩法呢？

答案是不能。尽管原生的ESM现在得到了广泛的支持，但由于前套导入会导致额外的网络往返，在生产环境中发布未打包的ESM仍然效率低下，即使使用了HTTP2也是如此。为了在生产环境中获得最佳的加载性能，最好呢？还是将代码进行tra栏加载、创客分割等操作？其中创客分割的目的是获得更好的缓存，要确保开发服务器和生产环境构建之间的最优输出和行为一致并不容易，所以VT附带了一套构建优化的构建命令，开箱即用。

那接着你可能会问第二个问题，为何不使用ES build的打包呢？它的速度不是飞快吗？虽然ES build的快的惊人，并且已经是在一个构建库方面做的比较出色的工具了，但一些针对构建应用的重要功能仍然还在持续开发中，特别是代码分割和CSS处理方面。就目前来说，Roll up在应用打包方面更加成熟和灵活。尽管如此，官方也表示。当未来这些功能稳定以后，也不排除使用ES build作为生产构建器的可能。官网上也给了wait的竞品。其实与其说竞品，倒不如说站在巨人的肩膀上，他们为VAT的发展提供了大量的灵感。第一个snow pack snow pack也是一个与WAIT10分类似的非构建式原生的ESM开发服务器。除了不同的实现细节外，这两个项目在技术上比传统的工具有很多的共同优势。V的依赖构建也是受到了snow pack ve1现在是ES install的启发。这两个项目之间的一些主要区别有生产构建、依赖域构建、me的支持、CSS域处理支持、view第一优先级支持方面。详细的信息大家可以参阅官方的文档。

第二个WMMRP瑞团队的WMMR提供了类似的特征集，而V2.0对roll up插件接口的支持正是受到了他的启发。WMR主要是为p re react项目而设计，并为其提供了集成度更高的功能，比如预渲染。就使用范围而言，它更加贴合于P框架，与P本身一样的强调紧凑的大小。如果你正在使用P，那么WMMR可能会提供更好的体验。

第三个web deve server web de server以前叫ES de server，它是一个伟大的项目，基于KOA的V1.0的开发服务器就是受到了它的启发。web DV server使用范围不是很广，它并未提供官方的框架集成，并且需要为生产构建手动的设置up配置。到目前为止，我们基本上了解了为什么选用weight，那接下来我们就愉快的使用它吧。