前言
hello world欢迎来到前端的新世界
😜当前文章系列专栏：前端工程化
🐱👓博主在前端领域还有很多知识和技术需要掌握，正在不断努力填补技术短板。(如果出现错误，感谢大家指出)🌹
💖感谢大家支持！您的观看就是作者创作的动力
前端工程化
首先这就涉及到我们程序员编写代码的思路和方式了
我们都喜欢多模块，SASS/LESS预编译器，前沿语法，前言API，命名友好，资源分组，有注释的方式
而浏览器喜欢的是少量文件，CSS，兼容语法，兼容API，单字节命名，资源集中，无注释的方式。
所以我们前端工程化的意义和作用就来了。使用webpack和vite来帮助我们把我们写的代码转换成浏览器能够读写的模式。让我们可以随意的编写我们喜欢的格式的代码
webpack的构建流程
- 初始化参数： 从配置文件和shell语句中读取合并参数，得出最终的配置参数。
- 开始编译： 从上一步得到的参数初始化compiler对象，加载所有配置插件，执行对象的run方法开始编译
- 确定入口： 通过entry找出入口文件
- 编译模块： 从入口文件出发，调用所有配置的
loader对模块进行翻译，再找出该模块依赖的模块，这个步骤是递归执行的，直至所有入口依赖的模块文件都经过本步骤的处理。 - 完成模块编译： 经过第 4 步使用 loader 翻译完所有模块后，得到了每个模块被翻译后的最终内容以及它们之间的依赖关系。
- 输出资源： 根据入口和模块之间的依赖关系，组装成一个个包含多个模块的
chunk，再把每个chunk转换成一个单独的文件加入到输出列表，这一步是可以修改输出内容的最后机会。 - 输出完成： 在确定好输出内容后，根据配置确定输出的路径和文件名，把文件内容写入到文件系统。
vite的构建流程
Vite 的构建流程与传统的打包工具（如Webpack）有所不同，主要体现在开发阶段和生产环境阶段。以下是 Vite 的构建流程：
开发阶段：
- 启动开发服务器： 当你启动 Vite 时，它会启动一个开发服务器来为你提供服务。这个开发服务器利用现代浏览器对 ES 模块的本地支持，实现了快速的冷启动和热模块替换（HMR）。
- 解析并提供文件： 当浏览器请求某个文件时，Vite 会解析这个文件，并根据需要进行转换。例如，对于 Vue 单文件组件（SFC），Vite 会将其实时编译成 JavaScript，然后返回给浏览器。
- 处理依赖关系： 当浏览器中的代码引入其他模块时，Vite 会分析这些依赖关系，并通过浏览器原生的 ES 模块加载功能来动态地获取这些模块。
生产环境阶段：
- 预构建： 在生产环境中，Vite 会预先构建你的应用程序，以便在部署时能够提供尽可能高效的代码。
- 优化和压缩： Vite 会对代码进行优化和压缩，以提高应用程序的性能，并生成适合生产环境部署的静态资源。
- 输出： 完成构建后，Vite 会将最终的生产代码输出到指定的目录，准备用于部署到生产环境。
webpack和vite的对比
服务器启动区别
- wepack: 当冷启动开发服务器时，基于打包器的方式是在提供服务前去急切地抓取和构建你的整个应用。
而 Vite 是通过在一开始将应用中的模块区分为 依赖 和 源码 两类，改进了开发服务器启动时间。
依赖 大多为纯 JavaScript 并在开发时不会变动。一些较大的依赖（例如有上百个模块的组件库）处理的代价也很高。依赖也通常会以某些方式（例如 ESM 或者 CommonJS）被拆分到大量小模块中。
Vite 将会使用 esbuild 预构建依赖。Esbuild 使用 Go 编写，并且比以 JavaScript 编写的打包器预构建依赖快 10-100 倍。
源码 通常包含一些并非直接是 JavaScript 的文件，需要转换（例如 JSX，CSS 或者 Vue/Svelte 组件），时常会被编辑。同时，并不是所有的源码都需要同时被加载。（例如基于路由拆分的代码模块）。
Vite 以 原生 ESM 方式服务源码。这实际上是让浏览器接管了打包程序的部分工作：Vite 只需要在浏览器请求源码时进行转换并按需提供源码。根据情景动态导入的代码，即只在当前屏幕上实际使用时才会被处理。
热更新的区别
webpack
全局刷新： Webpack 的 HMR 通常会在代码发生变化时替换整个模块，然后通过 HMR runtime 来触发页面级别的刷新或重新渲染，这可能导致部分页面状态的丢失。
较慢的冷启动： Webpack 的开发模式下，由于整个应用程序需要被打包和构建，因此冷启动时间相对较长，尤其是随着项目规模的增大，冷启动时间会进一步延长。
配置复杂： 在使用 Webpack 进行 HMR 时，需要进行一定的配置，包括设置 HMR 插件、编写 HMR 相关的代码等，相对来说略显复杂。
vite
- 局部更新： Vite 的 HMR 实现了更细粒度的模块更新，可以实现局部模块的更新而无需刷新整个页面，从而减少页面状态的丢失。
- 快速冷启动： Vite 利用现代浏览器的原生 ES 模块加载能力，实现了快速的冷启动时间，因为它不需要将整个应用程序打包成一个或多个文件。
- 无需额外配置： 在 Vite 中，HMR 是开箱即用的，无需额外配置。Vite 会自动处理模块的更新和热替换，让开发者专注于业务逻辑的开发。
底层代码实现的区别？
webpack是用的node.js来实现的，node.js支持的生态库更多，前后端的一致性比较高，对于异步编程有着很好的支持，node.js的跨平台性比较好，在window，Mac,和linux等不同操作系统上都可以运行
vite是使用的 esbuild，esbuild 是用 Go 语言编写的，专注于快速的构建和打包，它的底层实现经过了高度优化，能够充分利用多核处理器和其他硬件资源，以及高效的算法和数据结构，从而实现了极快的构建速度。
总结
webpack服务器启动速度比vite慢：由于vite启动的时候不需要打包，也就无需分析模块依赖、编译，所以启动速度非常快。当浏览器请求需要的模块时，再对模块进行编译，这种按需动态编译的模式，极大缩短了编译时间，当项目越大，文件越多时，vite的开发时优势越明显
vite热更新比webpack快:vite在HRM方面，当某个模块内容改变时，让浏览器去重新请求该模块即可，而不是像webpack重新将该模块的所有依赖重新编译；
vite使用esbuild(Go 编写) 预构建依赖，而webpack基于nodejs, esbuild比node快 10-100 倍
vite生态不及webpack，加载器、插件不够丰富
vite的缺点是什么？
- 生态，生态，生态不如webpack
wepback厉害之处在于loader和plugin非常丰富,不过我认为生态只是时间问题，现在的vite,更像是当时刚出来的M1芯片Mac，作者当时非常喜欢M1的Mac，毫不犹豫买了，现在也没什么问题，相信vite后续更新会更好
- prod环境的构建，目前用的Rollup
原因在于esbuild对于css和代码分割不是很友好
- 还没有被大规模使用,很多问题或者诉求没有真正暴露出来
vite真正崛起那一天，是跟vue3有关系的,当vue3广泛开始使用在生产环境的时候，vite也就大概率意味着被大家慢慢开始接受了
vite一定比webpack快吗?
不能说vite一定比webpack快，相对于不同的场景，webpack和vite有不同的速度优势吧。
vite相对于webpack在开发环境下有着更快的启动速度，因为vite底层是用的esbuild,这种设计使得 Vite 能够以非常低的延迟启动开发服务器，并且在修改文件时能够实现近乎即时的重新加载。
然而，在生产环境中，Vite 和 Webpack 的性能差异可能会变得不那么明显。Webpack 通过使用高度优化的构建算法和各种插件来提供出色的打包性能，尤其适用于复杂的项目和大规模的应用程序。
因此，是否可以说 Vite 一定比 Webpack 快，取决于具体的使用场景和项目需求。对于简单的小型项目，特别是新项目，Vite 通常会具有更快的启动和开发速度。而对于复杂的项目或需要更多自定义配置和功能的情况，Webpack 可能会更适合，因为它提供了更多的灵活性和扩展性。
后言
创作不易，要是本文章对广大读者有那么一点点帮助 不妨三连支持一下，您的鼓励就是博主创作的动力
