Le rival de Vite en Rust est arrivé (ou presque)

OJ (OJ) de Lovable n'est pas juste une énième réécriture en Rust d'une chaîne d'outils JavaScript. Ce n'est pas un projet de week-end pour amateur ; c'est une refonte stratégique axée sur la performance du serveur de développement principal de Vite, de son observateur de fichiers et graphe de modules jusqu'au rechargement à chaud des modules et au React fast refresh. Lovable a conçu OJ en utilisant Rolldowndown et Oxc, des technologies également exploitées par Vite lui-même et maintenues par VoidZero, soulignant ainsi son sérieux.

Lovable, un fournisseur de services de prévisualisation de premier plan, fait face à un défi opérationnel monumental : lancer environ un million de sandboxes Vite chaque jour. À cette échelle inimaginable, la consommation de mémoire et les temps de démarrage à froid ne sont pas de simples commodités pour les développeurs ; ils deviennent des indicateurs commerciaux critiques. OJ répond présent sur ce front, affichant des démarrages à froid jusqu'à 1,7 fois plus rapides jusqu'à l'affichage de la page et utilisant un quart de la mémoire par rapport au Vite par défaut sur de grandes applications de 5 000 composants, offrant des prévisualisations instantanées et légères en ressources, essentielles pour leur plateforme.

Considérez les exigences uniques des agents IA, qui peuvent écrire une douzaine de fichiers en une rafale. Vite déclencherait normalement une mise à jour pour chaque sauvegarde individuelle. OJ, cependant, fusionne intelligemment ces changements rapides en une seule mise à jour atomique au sein de son observateur intégré, de son graphe de modules, de son compilateur et de son pipeline de mise à jour à chaud. Il dispose même d'une porte optionnelle, retenant les mises à jour jusqu'à ce qu'un agent publie explicitement vers un point de terminaison de vidage, garantissant que seuls les changements complets et finis se propagent à la prévisualisation. De telles optimisations sur mesure sont totalement hors de propos pour les développeurs individuels, mais elles permettent de manière critique l'infrastructure massive et pilotée par des agents de Lovable.

Les benchmarks phares de Lovable pour OJ sont indéniablement impressionnants. Sur une application massive de 5 000 composants, OJ atteint des démarrages à froid 1,7x plus rapides jusqu'à l'affichage de la page que le Vite par défaut, tout en consommant seulement un quart de la mémoire de Vite. Ces chiffres sont convaincants pour quiconque lutte à une échelle extrême.

Mais ne vous précipitez pas pour réécrire votre package.json tout de suite. Sur des applications typiques et plus petites, les gains de performance d'OJ sont minimes, avec une utilisation de la mémoire seulement légèrement meilleure que celle de Vite. Les avantages substantiels n'apparaissent que dans des conditions d'échelle immense et de lancements/arrêts fréquents, le cas d'utilisation principal de Lovable.

Le créateur de Vite, Evan You, souligne à juste titre des mises en garde critiques. Les benchmarks d'OJ excluent souvent le travail effectué par Vite, tel que la vérification de type via vite-plugin-checker, qu'OJ contourne simplement. Cela crée une comparaison imparfaite, bien qu'encore informative.

De plus, le bundled dev mode expérimental de Vite réduit considérablement l'écart de vitesse de démarrage à froid, dépassant parfois même OJ. Cependant, il ne résout pas la différence de consommation de mémoire, laissant à OJ un avantage clair sur ce front pour les déploiements à grande échelle. Les compromis sont réels.

Les benchmarks impressionnants d'OJ s'accompagnent d'un astérisque important. Cette vitesse n'est pas universelle ; c'est le produit d'une spécialisation extrême. Lovable a réécrit le serveur de développement principal de Vite principalement pour les applications React, le type même d'applications que Lovable génère, sacrifiant délibérément le large support des frameworks et des configurations qui fait de Vite un outil omniprésent.

Cette spécialisation introduit des problèmes de compatibilité. Les tests ont révélé un bug critique de React Fast Refresh : l'état était perdu dans une application TanStack, indiquant un rechargement complet au lieu d'une mise à jour à chaud. Bien qu'une application React standard fonctionne correctement, ce cas limite souligne le fossé de maturité, car un outil polyvalent comme Vite a depuis longtemps corrigé de telles incohérences.

Sur le plan architectural, OJ adopte une approche directe axée sur Rust. Il fonctionne comme un processus Rust pilotant d'autres outils Rust comme Rolldowndown et Oxc, avec un pont JavaScript uniquement pour la compatibilité avec les plugins Vite. Cela contraste fortement avec Vite, qui fonctionne comme un processus Node.js orchestrant des composants Rust. La flexibilité de Vite s'accompagne d'une surcharge ; le pipeline Rust direct d'OJ élimine cela, offrant une vitesse brute pour son cas d'utilisation ciblé. D'autres informations sur la motivation de Lovable sont disponibles ici : Faster previews, soon powered by OJ - Lovable.

OJ n'est pas un concurrent direct de Vite ; c'est ce qu'Evan You, le créateur de Vite, appelle astucieusement une 'tailored projection' (projection sur mesure). Lovable a réécrit des parties clés du serveur de développement de Vite, certes, mais ils l'ont optimisé pour leurs contraintes uniques : des millions d'applications React en bac à sable. Il ne s'agit pas de remplacer Vite, mais plutôt d'une réimplémentation stratégique sous des paramètres radicalement différents pour résoudre un problème spécifique et massif.

You considère cela comme plus qu'un incident isolé ; c'est le signe avant-coureur d'une tendance plus large, peut-être inévitable. À mesure que l'IA réduit le coût de la réimplémentation, les développeurs créeront de plus en plus ces 'slop forks' spécialisés. Au lieu que les mainteneurs open-source luttent contre des milliers de Pull Requests de niche, les entreprises maintiendront simplement leurs propres versions hautement optimisées, personnalisées selon leurs besoins exacts.

Cet avenir présente une arme à double tranchant fascinante, mais précaire. D'une part, cela libère véritablement les mainteneurs principaux du déluge de contributions très spécifiques qui ne correspondent souvent pas à la vision plus large du projet. D'autre part, cela risque de fragmenter l'écosystème, où des améliorations précieuses deviennent cloisonnées au sein de forks d'entreprise, sans jamais contribuer au projet central. Evan You lui-même admet ne pas savoir si cette dynamique est finalement bénéfique pour l'esprit de collaboration open-source. Seul le temps nous dira si cela mène à l'innovation ou à l'isolement.

Qu'est-ce qu'Orange Juice (OJ) ?

Orange Juice (OJ) est une réimplémentation du serveur de développement Vite en Rust, créée par l'entreprise Lovable. Il est conçu pour être une alternative haute performance et à faible consommation de mémoire pour leur cas d'utilisation spécifique consistant à exécuter des millions de bacs à sable de prévisualisation quotidiennement.

OJ est-il un remplacement complet de Vite ?

Non. OJ réécrit uniquement les composants du serveur de développement tels que le file watcher, le module graph et le HMR. Ce n'est pas une réécriture complète de Vite et il repose toujours sur l'écosystème de plugins de Vite. Il est également actuellement optimisé principalement pour les applications React.

OJ est-il nettement plus rapide que Vite ?

Sur les grandes applications (par exemple, plus de 5 000 composants), OJ montre des gains de performance significatifs, étant près de deux fois plus rapide lors des démarrages à froid et utilisant seulement un quart de la mémoire. Sur les petits projets, la différence est beaucoup moins perceptible.

Qu'a dit le créateur de Vite, Evan You, à propos d'OJ ?

Evan You a qualifié OJ de projet impressionnant qui résout bien le problème de Lovable. Il a également précisé qu'il ne s'agissait pas d'un remplacement complet de Vite et a souligné que sa vitesse provenait de son champ d'application étroit, contrairement à Vite qui doit prendre en charge un vaste écosystème. Il l'a mis en avant comme un exemple d'une tendance future de 'projections sur mesure' ou de 'slop forks' dans l'open source.