Lovable a réécrit Vite en Rust... (en quelque sorte)
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Vous pouvez en ajouter un au compteur car il y a eu une autre réécriture en Rust, cette fois du serveur
00:00:03de dev Vite réécrit en Rust par l'équipe de Lovable, permettant soi-disant de diviser par quatre l'utilisation
00:00:07de la mémoire et de doubler la vitesse des démarrages à froid. Examinons donc cette affirmation car elle est
00:00:12peut-être un peu trompeuse, puis voyons si vous devriez y passer à l'avenir,
00:00:15et aussi ce que le créateur de Vite en pense pour l'avenir de l'open source.
00:00:24Le projet dont je parle s'appelle OJ, alias Orange Juice, et l'idée est que c'est un
00:00:29binaire Rust qu'on peut pointer sur un projet Vite existant et qui l'exécute directement. Il lit ma config
00:00:33Vite, il lance mes plugins Vite existants, mais le serveur de dev sous-jacent, donc le watcher de
00:00:38fichiers, le graphe de modules, le HMR et le fast refresh de React, a été entièrement réécrit en Rust.
00:00:44Curieusement, cela a été fait en utilisant Rolldown et Oxc, que Vite utilise lui-même et que VoidZero
00:00:49maintient. Pour essayer cela moi-même, j'ai créé une application TanStack pour voir s'il y a des différences
00:00:53entre l'exécuter avec Vite dev ou OJ dev. En surface, ils semblent fonctionner de manière quasi identique,
00:00:58et tout fonctionne, comme le rendu côté serveur, l'hydratation, les fonctions serveur, le fast refresh,
00:01:03les routes de fichiers dynamiques, les routes serveur, Tailwind et l'import de ressources, mais en creusant un peu,
00:01:07j'ai remarqué quelques différences mineures. La première concernait le fast refresh ici. Si je modifie un fichier,
00:01:13le compteur sous Vite conserve son état, mais sous OJ, le compteur se réinitialise à zéro,
00:01:17ce qui indique qu'OJ fait un rechargement complet au lieu de recharger seulement le composant modifié. J'ai donc décidé
00:01:22de tester ce même comportement dans une application React classique sans TanStack Start,
00:01:26et fait intéressant, cela a semblé fonctionner ici. La même modification conserve le compteur,
00:01:30et la page entière n'est pas mise à jour, donc il semble faire une vraie mise à jour à chaud. Je ne sais donc pas
00:01:35pourquoi il y a cette différence entre TanStack Start et une app React classique, c'est peut-être juste un
00:01:39cas particulier qu'ils n'ont pas encore pris en compte. La deuxième différence que j'ai remarquée concerne
00:01:42la fonction serveur. Cette fonction mesure la mémoire de tout l'arbre de processus du serveur de dev depuis
00:01:46l'application, et sur cette app sous Vite, on est à environ 380 Mo sur deux processus, alors que sous OJ,
00:01:53on est à environ 320 Mo, également sur deux processus. Donc sur une petite application comme celle-ci, il semble que
00:01:59l'utilisation de la mémoire soit à peu près la même, OJ étant juste très légèrement devant. Cela veut-il dire que ce projet est
00:02:04totalement inutile ? Eh bien non, car ce n'est pas vraiment pour ça qu'OJ a été conçu. En fait, OJ fonctionne
00:02:09mieux sur de très grandes applications. Quand j'ai testé ça sur une app React de 5 000 composants, avec un script qui
00:02:14lance chaque serveur de dev, ouvre la page dans un vrai navigateur Chrome, arrête le chrono quand le
00:02:19composant le plus profond est dans le DOM, puis mesure la mémoire de tout l'arbre de processus, le mode normal
00:02:24d'OJ est environ 1,7 fois plus rapide pour afficher la page que Vite par défaut, et consomme environ quatre fois moins
00:02:29de mémoire. Pour être juste envers Vite, Vite 8.1 a intégré une fonctionnalité expérimentale appelée bundled dev mode,
00:02:34et si vous l'activez, Vite descend à 1,18 seconde, donc un peu plus rapide que le mode normal
00:02:40d'OJ, mais cela n'économise pas de mémoire. Et OJ a aussi un mode bundle qui, lorsqu'il est utilisé,
00:02:45le rend encore plus rapide, à environ 0,89 seconde, tout en maintenant la mémoire au quart de celle de Vite.
00:02:51OJ semble donc apporter de vrais gains de mémoire, et c'est un peu la raison principale pour laquelle Lovable
00:02:55a créé ce projet. Les aperçus de Lovable exécutent un vrai serveur de dev Vite, et Lovable dit en exécuter environ un
00:03:00million par jour dans des bacs à sable, et à une telle échelle, la consommation
00:03:04de ressources devient cruciale. Lovable a donc conçu OJ pour obtenir des aperçus qui démarrent instantanément et restent légers,
00:03:09sans devoir renoncer à l'écosystème qui fait fonctionner l'application à la base.
00:03:13Ils ont aussi pris une décision de conception assez intéressante autour de ce cas d'usage, à savoir les agents. Lors de l'édition,
00:03:17une personne sauvegarde généralement un fichier à la fois, mais un agent peut en écrire une dizaine d'un coup,
00:03:22et Vite traiterait chacune de ces sauvegardes comme une mise à jour, alors que dans OJ, le watcher,
00:03:26le graphe de modules, le compilateur et les mises à jour à chaud forment un seul pipeline, donc une rafale est regroupée en une seule mise à jour.
00:03:32Il y a aussi un verrou qu'on peut activer pour retenir les mises à jour jusqu'à ce que l'agent lui-même
00:03:35envoie une requête à un point de terminaison de purge, ainsi l'aperçu n'applique que la modification terminée. On voit que c'est
00:03:40un projet très spécifique conçu pour répondre aux besoins propres de Lovable, et c'est ce que le créateur de Vite, Evan You,
00:03:45a également reconnu. Son premier point dans ce tweet est que c'est un projet très impressionnant qui résout
00:03:49bien le problème de Lovable, mais que ce n'est pas une réécriture complète de Vite. C'est uniquement le serveur de dev,
00:03:54et il repose aussi sur Rolldown et Oxc, que VoidZero maintient, donc cela ne les remplace pas vraiment.
00:04:00Le parseur, le transformateur et le bundler de production dans OJ viennent tous de VoidZero,
00:04:04Lovable a juste écrit le serveur autour. On peut essentiellement voir ça comme : Vite est un processus Node
00:04:08qui pilote du Rust, alors qu'OJ est un processus Rust qui pilote du Rust, avec une couche intermédiaire
00:04:13en JavaScript pour pouvoir continuer à communiquer avec l'API de plugins de Vite. Evan souligne ensuite
00:04:17qu'OJ parvient à être rapide car il ne prend en charge qu'un seul type d'application. OJ ne fonctionne en fait qu'avec
00:04:22les applications React, à savoir celles que Lovable génère. Vite, en revanche, doit
00:04:27prendre en charge chaque framework, chaque config bizarre, chaque outil construit autour, et laisse délibérément
00:04:31des éléments comme esbuild ou le plugin React sous forme de packages séparés, afin de les ajouter soi-même en cas de
00:04:36besoin. Après cela, il souligne également les faiblesses du benchmark. Le démarrage à froid de Vite dans l'article de blog
00:04:40inclut vite-plugin-checker, qui exécute TypeScript dans un worker en arrière-plan, mais OJ ne prend pas
00:04:45en charge ce plugin, ce qui lui évite totalement ce travail. Il fait aussi remarquer qu'avec le bundled dev
00:04:50mode dans Vite, on se rapproche du démarrage à froid d'OJ, ce qui correspond exactement à ce qu'on a vu dans nos chiffres, mais il
00:04:55reconnaît qu'OJ utilise nettement moins de mémoire, et que Vite devrait probablement chercher à s'améliorer sur ce point.
00:04:59Le dernier point d'Evan dans ce tweet est celui que je trouve le plus intéressant. La dynamique de l'open source
00:05:03est en train de changer, le coût pour réimplémenter quelque chose s'est effondré à cause de l'IA, nous allons donc voir davantage
00:05:08de ce qu'il appelle des projections sur mesure d'outils open source, c'est-à-dire la même dépendance, réécrite selon les
00:05:13contraintes d'un composant pour répondre à un seul cas d'usage. Il donne en autre exemple le Redact de TanStack. Un avenir
00:05:19possible serait qu'au lieu de voir les mainteneurs submergés par des milliers de PR inutiles, chacun
00:05:23maintienne simplement son propre fork spécialisé. Il avoue honnêtement ne pas savoir si c'est une bonne chose, mais il
00:05:28pense très probable que c'est ce qui arrivera dans quelques années. D'un côté, les forks spécialisés sont préférables
00:05:33pour les mainteneurs à une masse de PRs, mais on risque une fragmentation de l'écosystème. Je suppose
00:05:39que seul le temps nous dira comment cela va évoluer, et ce que sera l'avenir de l'open source.
00:05:43Dans l'ensemble, ce n'est pas vraiment un outil que quelqu'un d'autre que Lovable utilisera, à moins
00:05:47de faire face exactement au même problème de millions de serveurs de dev Vite dans des bacs à sable, et honnêtement,
00:05:52avez-vous déjà remarqué que Vite était lent sur votre propre ordinateur portable ou utilisait trop de mémoire ? Pour ma part,
00:05:57non, mais cela reste un projet très intéressant, et c'est super qu'ils l'aient fait,
00:06:01dites-moi en commentaire ce que vous en pensez. Au passage, abonnez-vous, et comme toujours,
00:06:04à la prochaine.
00:06:09À la prochaine.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video