Vite和Webpack的核心差异 - 网站源码_资源分享

写在结尾前段时间的vite较为火，所以正式发布了2.0版，vue的译者也是在力荐在以后的该文里头我提及过，vite的优点是现期的自然生态不如webpack成形，但如果能填补那个优点，便有非常大机率能代替目前webpack的绝大部分消费市场多方位对照vite和webpackwebpack装箱操作过程

1.辨识出口处文档

2.透过逐次辨识组件倚赖。（Commonjs、amd或是es6的import，webpack单厢对其

3.webpack做的是预测标识符。切换标识符，校对标识符，输入标识符

4.最后逐步形成装箱后的标识符

webpack装箱基本原理

1.先逐次递回辨识倚赖，构筑倚赖图表

2.将标识符切换成AST抽象化句法树

3.在AST期中去处置标识符

4.把AST抽象化句法树变为应用程序能辨识的标识符，接着输入

重点项目:这儿须要递回辨识倚赖，构筑倚赖图表。图表第一类是类似于上面此种

{ ./app.js

{ dependencies: {./test1.js: ./test1.js

code:

“use strict”;\n\nvar _test = _interopRequireDefault(require(“./test1.js”));\n\nfunction _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { “default”: obj }; }\n\nconsole.log(test

1);

./test1.js

{ dependencies: { ./test2.js: ./test2.js

code:

“use strict”;\n\nvar _test = _interopRequireDefault(require(“./test2.js”));\n\nfunction _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { “default”: obj }; }\n\nconsole.log(\

is is test1.js \, _test[“default”]);

./test2.js

{ dependencies: {},

code:

“use strict”;\n\nObject.defineProperty(exports, “__esModule”, {\n value: true\n});\nexports[“default”] = void 0;\n\nfunction test2() {\n console.log(\this is test2 \

);\n}\n\nvar _default = tes

t2;\nexports[“default”] = _default;

} }

vite基本原理当声明一个 script 标签类型为 module 时

如：

应用程序就会像服务器发起一个GEThttp://localhost:3000/src/main.js请求main.js文档：

// /src/main.js:

import { createApp } from vueimport App from ./App.vuecreateApp(App).mount(#app

)

如：GET http://localhost:3000/@modules/vue.js

如：GET http://localhost:3000/src/App.vue

Vite 的主要功能是透过劫持应用程序的这些请求，并在后端进行相应的处置将项目中使用的文档透过简单的分解与整合，接着再返回给应用程序，vite整个操作过程中没有对文档进行装箱校对，所以其运行速度比原始的webpack开发校对速度快出许多！

webpack优点一。缓慢的服务器启动当冷启动开发服务器时，基于装箱器的方式是在提供服务前去急切地抓取和构筑你的整个应用。vite改进

Vite 透过在一开始将应用中的组件区分为倚赖和源码两类，改进了开发服务器启动时间。

倚赖大多为纯 JavaScript 并在开发时不会变动。一些较大的倚赖（例如有上百个组件的组件库）处置的代价也很高。倚赖也通常会以某些方式（例如 ESM 或是 CommonJS）被拆分到大量小模块中。

Vite 将会使用 esbuild 预构筑倚赖。Esbuild 使用 Go 编写，并且比以 JavaScript 编写的装箱器预构筑倚赖快 10-100 倍。

源码通常包含一些并非直接是 JavaScript 的文档，须要切换（例如 JSX，CSS 或是 Vue/Svelte 组件），时常会被编辑。同时，并不是所有的源码都须要同时被加载。（例如基于路由拆分的标识符组件）。

Vite 以原生 ESM 方式服务源码。这实际上是让应用程序接管了装箱程序的部分工作：Vite 只须要在应用程序请求源码时进行切换并按需提供源码。根据情景动态导入的标识符，即只在当前屏幕上实际使用时才会被处置。

webpack缺点2.使用的是node.js去实现

Vite和Webpack的核心差异

vite改进

Vite 将会使用 esbuild 预构筑倚赖。Esbuild 使用 Go 编写，并且比以 Node.js 编写的装箱器预构筑倚赖快 10-100 倍。webpack致命优点3.热更新效率低下

当基于装箱器启动时，编辑文档后将重新构筑文档本身。显然我们不应该重新构筑整个包，因为这样更新速度会随着应用体积增长而直线下降。

一些装箱器的开发服务器将构筑内容存入内存，这样它们只须要在文档更改时使组件图的一部分失活[1]，但它也仍须要整个重新构筑并重载页面。这样代价很高，并且重新加载页面会消除应用的当前状态，所以装箱器支持了动态组件热重载（HMR）：允许一个模块 “热替换” 它自己，而对页面其余部分没有影响。这大大改进了开发体验 – 然而，在实践中我们发现，即使是 HMR 更新速度也会随着应用规模的增长而显著下降。

vite改进

在 Vite 中，HMR 是在原生 ESM 上执行的。当编辑一个文档时，Vite 只须要精确地使已编辑的组件与其前段时间的 HMR 边界之间的链失效（大多数时候只须要组件本身），使 HMR 更新始终快速，无论应用的大小。

Vite 同时利用 HTTP 头来加速整个页面的重新加载（再次让应用程序为我们做更多事情）：源码组件的请求会根据 304 Not Modified 进行协商缓存，而倚赖组件请求则会透过 Cache-Control: max-age=31536000,immutable 进行强缓存，因此一旦被缓存它们将不须要再次请求。

vite优点1.自然生态，自然生态，自然生态不如webpackwepback牛逼之处是loader和plugin非常丰富,不过我认为自然生态只是时间问题，现在的vite,更像是当时刚出来的M1芯片Mac，我当时非常看好M1的Mac，毫不犹豫买了，现在也没什么问题vite优点2.prod环境的构筑，现期用的Rollup原因是esbuild对于css和标识符分割不是很友好vite优点3.还没有被大规模使用,很多问题或是诉求没有真正暴露出来vite真正崛起那一天，是跟vue3有关系的,当vue3广泛开始使用在生产环境的时候，vite也就大机率意味着被大家慢慢开始接受了总结

Vite，就像刚出来的M1芯片Mac,都说好，但一开始买的人不多，担心自然生态问题，后面都说真香

相信vue3译者的大力支持下，vite即将大放异彩！

我已经在我自己项目的生产环境中，开始使用vite!

写在最后