Pourquoi Vite ? #

Les problèmes #

Avant que les modules ES ne soient disponibles dans les navigateurs, les développeurs ne disposaient d'aucun mécanisme natif pour créer du JavaScript de manière modulaire. C'est pourquoi nous sommes tous familiers avec le concept de "bundling" : l'utilisation d'outils qui rampent, traitent et concatènent nos modules sources dans des fichiers qui peuvent être exécutés dans le navigateur.

Au fil du temps, nous avons vu apparaître des outils tels que webpack, Rollup et Parcel, qui ont grandement amélioré l'expérience de développement des développeurs frontaux.

Cependant, à mesure que nous construisons des applications de plus en plus ambitieuses, la quantité de JavaScript que nous manipulons augmente également de façon spectaculaire. Il n'est pas rare que les projets à grande échelle contiennent des milliers de modules. Nous commençons à nous heurter à un goulot d'étranglement en matière de performances pour les outils basés sur JavaScript : il faut souvent attendre un temps déraisonnable (parfois jusqu'à plusieurs minutes !) pour faire tourner un serveur de développement, et même avec le remplacement à chaud des modules (HMR), les modifications de fichiers peuvent prendre quelques secondes avant d'être reflétées dans le navigateur. La lenteur de la boucle de rétroaction peut grandement affecter la productivité et le bonheur des développeurs.

Vite vise à résoudre ces problèmes en tirant parti des nouvelles avancées de l'écosystème : la disponibilité de modules ES natifs dans le navigateur et l'essor des outils JavaScript écrits dans des langages de compilation natifs.

Démarrage lent du serveur #

Lors du démarrage à froid du serveur de développement, une configuration de construction basée sur un bundler doit parcourir et construire toute votre application avant qu'elle puisse être servie.

Vite améliore le temps de démarrage du serveur de développement en divisant d'abord les modules d'une application en deux catégories : les dépendances et le code source.

• Les dépendances sont principalement du simple JavaScript qui ne change pas souvent pendant le développement. Certaines dépendances importantes (par exemple, des bibliothèques de composants comprenant des centaines de modules) sont également assez coûteuses à traiter. Les dépendances peuvent également être livrées dans différents formats de modules (par exemple ESM ou CommonJS).

  Vite pre-bundles dependencies en utilisant esbuild. esbuild est écrit en Go et pré-bundle les dépendances 10-100x plus rapidement que les bundlers basés sur JavaScript.

• Le code source contient souvent du JavaScript non-plain qui doit être transformé (par exemple, JSX, CSS ou composants Vue/Svelte), et sera édité très souvent. De plus, tout le code source n'a pas besoin d'être chargé en même temps (par exemple, avec le fractionnement du code basé sur les routes).

  Vite sert le code source sur [ESM natif] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules). Il s'agit essentiellement de laisser le navigateur prendre en charge une partie du travail d'un bundler : Vite n'a besoin que de transformer et de servir le code source à la demande, lorsque le navigateur le demande. Le code derrière les importations dynamiques conditionnelles n'est traité que s'il est effectivement utilisé sur l'écran actuel.

Mises à jour lentes #

Lorsqu'un fichier est modifié dans une configuration de construction basée sur un bundler, il est inefficace de reconstruire l'ensemble du bundle pour des raisons évidentes : la vitesse de mise à jour se dégrade linéairement avec la taille de l'application.

Dans certains bundlers, le serveur de développement exécute le bundle en mémoire de sorte qu'il n'a besoin d'invalider qu'une partie de son graphe de modules lorsqu'un fichier est modifié, mais il doit quand même reconstruire le bundle entier et recharger la page Web. La reconstruction du paquet peut être coûteuse, et le rechargement de la page fait disparaître l'état actuel de l'application. C'est pourquoi certains bundlers prennent en charge le remplacement à chaud des modules (HMR) : un module peut se remplacer à chaud sans affecter le reste de la page. Cela améliore grandement le DX - cependant, dans la pratique, nous avons constaté que même la vitesse de mise à jour de HMR se détériore de manière significative à mesure que la taille de l'application augmente.

Dans Vite, le HMR est effectué sur l'ESM natif. Lorsqu'un fichier est édité, Vite n'a besoin que d'invalider précisément la chaîne entre le module édité et sa limite HMR la plus proche (la plupart du temps seulement le module lui-même), ce qui rend les mises à jour HMR toujours rapides, quelle que soit la taille de votre application.

Vite exploite également les en-têtes HTTP pour accélérer les rechargements de pages complètes (encore une fois, laissons le navigateur faire plus de travail pour nous) : les requêtes de modules de code source sont rendues conditionnelles via 304 Not Modified, et les requêtes de modules de dépendance sont fortement mises en cache via Cache-Control : max-age=31536000,immutable afin qu'elles ne frappent pas à nouveau le serveur une fois mises en cache.

Une fois que vous aurez expérimenté la rapidité de Vite, nous doutons fortement que vous soyez prêt à supporter à nouveau un développement groupé.

Pourquoi regrouper pour la production #

Même si la gestion des contenus électroniques natifs est désormais largement prise en charge, l'expédition de la gestion des contenus électroniques non groupés en production reste inefficace (même avec HTTP/2) en raison des allers-retours supplémentaires sur le réseau causés par les importations imbriquées. Pour obtenir des performances de chargement optimales en production, il est toujours préférable de regrouper votre code avec des fonctions de tree-shaking, de lazy-loading et de common chunk splitting (pour une meilleure mise en cache).

Il n'est pas facile d'assurer une sortie optimale et une cohérence comportementale entre le serveur de développement et la version de production. C'est pourquoi Vite est livré avec une [commande de construction] (./build) préconfigurée qui intègre de nombreuses [optimisations de performances] (./features#build-optimizations) dès le départ.

Pourquoi ne pas utiliser esbuild ? #

Alors que esbuild est extrêmement rapide et est déjà un bundler très performant pour les librairies, certaines des fonctionnalités importantes nécessaires au bundling des applications sont encore en cours de développement - en particulier la division du code et la gestion des CSS. Pour l'instant, Rollup est plus mature et plus flexible à cet égard. Cela dit, nous n'excluons pas la possibilité d'utiliser esbuild pour les builds de production lorsqu'il stabilisera ces fonctionnalités dans le futur.

En quoi Vite est-il différent de X ? #

Vous pouvez consulter la section Comparaisons pour plus de détails sur la façon dont Vite diffère d'autres outils similaires.