Vite a réellement gagné non pas par son image de marque, mais en changeant le modèle de développement.
Les configurations lourdes de Webpack nécessitaient souvent un travail considérable en amont avant que l'application soit prête. Vite s'appuie sur l'ESM natif en développement, ce qui signifie que le serveur de développement peut effectuer beaucoup moins de regroupement enthousiaste et ne transformer que ce que le navigateur demande réellement.
Cette différence architecturale explique pourquoi le temps de démarrage et le HMR semblent souvent nettement meilleurs.
Ce qui a changé
Avec Vite :
- les dépendances sont pré-emballées rapidement
- les fichiers sources sont servis en tant que modules pendant le développement
- les modifications de fichiers invalident une plus petite partie du graphe
Cela conduit à une boucle de rétroaction beaucoup plus étroite :
pnpm create vite
pnpm dev
L'expérience est rapide parce que l'outil ne tente pas de reconstruire le monde entier à chaque petit changement.
Esbuild est important dans cette histoire car il a rendu le traitement des dépendances considérablement moins coûteux. L'expérience développeur de Vite n'est pas juste une idée astucieuse. C'est une bonne architecture reposant sur des outils de bas niveau très rapides.
Compromis
Webpack n'est pas mort. Les grandes organisations l'utilisent encore pour de bonnes raisons :
- écosystèmes de plugins matures
- chaînes de construction héritées
- fédérations ou configurations de bundling établies
Mais pour des travaux frontend en greenfield, Vite est souvent le choix par défaut le plus ergonomique car il s'adapte mieux au fonctionnement des navigateurs modernes et des outils de modules modernes.
Lectures complémentaires