Quelle est la différence entre vite et webpack

Différences : 1. La vitesse de démarrage du serveur webpack est plus lente que celle de vite ; car vite n'a pas besoin d'être empaqueté au démarrage, il n'est pas nécessaire d'analyser les dépendances du module et de compiler, donc la vitesse de démarrage est très rapide. 2. La mise à jour à chaud de Vite est plus rapide que le webpack ; en termes de HRM de Vite, lorsque le contenu d'un certain module change, laissez simplement le navigateur demander à nouveau le module. 3. Vite utilise esbuild pour pré-construire les dépendances, tandis que webpack est basé sur le nœud. 4. L'écologie de Vite n'est pas aussi bonne que celle du webpack, et les chargeurs et plug-ins ne sont pas assez riches.

L'environnement d'exploitation de ce tutoriel : système windows7, version vue3, ordinateur DELL G3.

Écrit au début

• Le récent vite est très populaire et a publié la version 2.0. L'auteur de vue le recommande également fortementvite比较火，而且发布了2.0版本，vue的作者也是在极力推荐

• 在之前的文章里面我提到过，vite的缺点在于目前的生态不够webpack成熟，但是只要能弥补这个缺点，便有很大概率能替代目前webpack的大部分市场

全方位对比vite和webpack

webpack打包过程

• 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(\'th
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 时

如：

 <script type="module" src="/src/main.js"></script>

• 浏览器就会像服务器发起一个GET

http://localhost:3000/src/main.js请求main.js文件：

// /src/main.js:
import { createApp } from 'vue'
import App from './App.vue'
createApp(App).mount('#app')

• 浏览器请求到了main.js文件，检测到内部含有import引入的包，又会对其内部的 import 引用发起 HTTP 请求获取模块的内容文件

• 如：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改进

• Vite 将会使用 esbuild 预构建依赖。Esbuild 使用 Go 编写，并且比以 Node.js

🎜Dans mon article précédent. Comme mentionné précédemment, le défaut de vite est que l'écologie actuelle n'est pas assez mature pour webpack, mais tant que ce défaut peut être compensé, il y a un grand probabilité qu'il puisse remplacer le webpackcode> actuel La plupart des marchés🎜

🎜🎜🎜améliorations de Vite🎜
🎜🎜🎜🎜Vite utilisera esbuild pour pré-construire les dépendances. Esbuild est écrit en Go et est 10 à 100 fois plus rapide que les dépendances de pré-construction avec des packagers écrits en Node.js. 🎜

Inconvénient fatal du Webpack 3. La mise à jour à chaud est inefficace

• Lorsqu'il est démarré en fonction du packager, le fichier lui-même sera reconstruit après l'édition du fichier. Évidemment, nous ne devrions pas reconstruire l'intégralité du package, car la vitesse de mise à jour chuterait à mesure que la taille de l'application augmenterait.

• Les serveurs de développement de certains packagers gardent la build en mémoire afin qu'ils n'aient besoin de désactiver qu'une partie du graphe du module lorsque les fichiers changent [1], mais cela nécessite également une reconstruction complète et un rechargement de la page. Cela coûte cher, et le rechargement de la page efface l'état actuel de l'application, donc le packager prend en charge le rechargement à chaud de module dynamique (HMR) : permettant à un module de se « remplacer à chaud » sans impact sur le reste de la page. Cela améliore considérablement l'expérience de développement. Cependant, dans la pratique, nous avons constaté que même la vitesse de mise à jour HMR diminuait considérablement à mesure que la taille de l'application augmentait.

améliorations d'vite

• Dans Vite, HMR est effectué sur ESM natif. Lors de l'édition d'un fichier, Vite 只需要精确地使已编辑的模块与其最近的 HMR 边界之间的链失效（大多数时候只需要模块本身），使 HMR 更新始终快速，无论应用的大小.

• Vite utilise également des en-têtes HTTP pour accélérer le rechargement de la page entière (en laissant encore une fois le navigateur faire plus pour nous) : les requêtes du module source seront négociées et mises en cache selon 304 Not Modified, tandis que les requêtes du module dépendant passeront par Cache -Control : max-age=31536000, immuable effectue une mise en cache forte, donc une fois mis en cache, ils n'auront plus besoin d'être demandés.

Inconvénients de Vite 1. L'écologie, l'écologie, l'écologie n'est pas aussi bonne que webpack

• La grande chose à propos de wepback est que le chargeur et le plugin sont très riches, mais je pense que l'écologie n'est qu'une question du temps, et maintenant Vite ressemble plus Le Mac à puce M1 venait de sortir à ce moment-là. J'étais très optimiste quant au Mac M1 et je l'ai acheté sans hésitation. Maintenant, il n'y a aucun problème

Inconvénients de Vite 2. La construction de l'environnement de production, utilise actuellement Rollup

• La raison est qu'esbuild n'est pas très convivial avec CSS et le fractionnement de code

vite Inconvénient 3. Il n'a pas été utilisé à grande échelle, et de nombreux problèmes ou demandes n'ont pas été vraiment exposés

• Le jour où Vite apparaîtra vraiment, cela a quelque chose à voir avec vue3. Lorsque vue3 commencera à être largement utilisé dans les environnements de production, Vite sera très probablement lentement accepté par. tout le monde

Résumé

• Le serveur webpack démarre plus vite que vite Slow

  Étant donné que Vite n'a pas besoin d'être empaqueté au démarrage, il n'est pas nécessaire d'analyser les dépendances du module et de compiler, donc le la vitesse de démarrage est très rapide. Lorsque le navigateur demande le module requis, il compile le module. Ce mode de compilation dynamique à la demande réduit considérablement le temps de compilation. Lorsque le projet est plus volumineux et les fichiers plus nombreux, les avantages de développement de Vite deviennent plus évidents

• vite une mise à jour à chaud. est plus rapide que webpack

  vite en termes de GRH, lorsque le contenu d'un module change, laissez simplement le navigateur redemander le module, au lieu de recompiler toutes les dépendances du module comme webpack

• vite utilise esbuild ( écrit en Go) pour pré-construire les dépendances, tandis que webpack est basé sur nodejs, qui est 10 à 100 fois plus rapide que node

• l'écologie de vite n'est pas aussi bonne que webpack, et les chargeurs et plug-ins ne sont pas assez riches

[Recommandations associées : Tutoriel vidéo vuejs, développement web front-end】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!