Vite, Rust et l'avenir de l'outillage JavaScript | Better Stack Podcast Ép. 11

BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00La version publique finale de V+ ressemblera
00:00:03probablement à quelque chose d'amusant.
00:00:06- Voici Evan Yu.
00:00:07- Evan Yu.
00:00:09- Evan Yu.
00:00:10- Evan Yu !
00:00:10- J'ai créé Vue et Vite.
00:00:14Aujourd'hui, je dirige une société appelée Voice Zero.
00:00:16- Quelle est la différence entre Vite et Vite+ ?
00:00:19- Votre expérience de développement sera identique
00:00:21à celle de Vite aujourd'hui.
00:00:22Mais si vous voulez aller plus loin,
00:00:24l'outil vous accompagnera tout au long du processus.
00:00:26- Comment l'équipe et vous-même utilisez-vous l'IA ?
00:00:28- Nous avons lancé des expériences un peu folles,
00:00:30comme porter le compilateur Angular vers Rust.
00:00:32- Que pensez-vous des React Server Components ?
00:00:34- Je suis sceptique depuis le premier jour.
00:00:36- D'habitude, quand je lance un podcast,
00:00:39je demande aux invités de se présenter.
00:00:40Mais si quelqu'un regarde ceci
00:00:42sans savoir qui vous êtes, je serais très surpris.
00:00:44Je pense que vous êtes vraiment très connu.
00:00:46Tout le monde devrait savoir,
00:00:48ou du moins la plupart des gens savent qui vous êtes.
00:00:49- Ils ont au moins entendu parler de Vite ou de Vue, c'est certain.
00:00:53- Oui, donc j'ai créé Vue et Vite.
00:00:57Maintenant, je dirige Voice Zero,
00:00:59où nous travaillons sur encore plus de projets open source.
00:01:03Il y a Rolldown, Vitest, OXC.
00:01:07Vue et Vite sont sans doute les plus populaires,
00:01:11mais ce sur quoi nous travaillons avec Voice Zero
00:01:14est aussi très intéressant.
00:01:15Rolldown est un bundler basé sur Rust.
00:01:18OXC est une chaîne d'outils complète en Rust qui va
00:01:22du parseur au résolveur, en passant par le transformeur,
00:01:25le minificateur, etc.
00:01:28Et au-dessus d'OXC, nous avons OXLint et OXFormat,
00:01:32qui sont respectivement un linter compatible ESLint
00:01:35et un formateur compatible Prettier.
00:01:37On travaille sur d'autres choses, mais voilà en gros.
00:01:41On va surtout parler d'open source pour l'instant.
00:01:45- Bien sûr.
00:01:45Comme vous travaillez sur énormément de choses,
00:01:47comment répartissez-vous votre temps ?
00:01:50- Eh bien, je n'écris plus personnellement de code
00:01:52pour tous ces projets.
00:01:53En fait, j'en écris beaucoup moins aujourd'hui
00:01:56depuis que j'ai fondé l'entreprise.
00:01:58Nous avons de nombreux ingénieurs
00:02:01bien meilleurs que moi en Rust,
00:02:03et ils sont tous passés à l'IA.
00:02:05C'est donc moitié eux, moitié Claude ou Cursor
00:02:10qui font tourner tout ce code Rust.
00:02:12Mon rôle est de trancher sur
00:02:17les choix d'expérience développeur (DX)
00:02:22et de décider de nos prochaines priorités.
00:02:25Et évidemment, il y a la partie produit :
00:02:28comment transformer cela en un produit
00:02:31qui génère des revenus,
00:02:32ce sur quoi nous travaillons encore.
00:02:34C'est tout ce qu'il faut faire
00:02:39pour gérer une entreprise de nos jours.
00:02:41- D'où viennent les idées
00:02:43pour ces nouveaux projets open source ?
00:02:45Est-ce surtout des besoins internes
00:02:48dont vous réalisez qu'ils pourraient
00:02:49résoudre les problèmes d'autres personnes ?
00:02:53- Tout part de Vite, en fait.
00:02:56Quand j'ai créé Vite, je bricolais juste dessus.
00:03:01C'était au départ un prototype,
00:03:03puis je me suis dit qu'il nous fallait un bundler.
00:03:07On a commencé avec ce serveur de dev
00:03:10basé sur l'ESM natif sans bundling.
00:03:13L'idée fonctionnait bien pour du code simple,
00:03:16mais quand on a commencé à importer de grosses dépendances,
00:03:18on a vu que ça ne passerait pas à l'échelle
00:03:21si on chargeait tout sans bundling.
00:03:24Par exemple, si vous chargez lodash-es,
00:03:26c'est environ 700 fichiers.
00:03:28On s'est dit : « D'accord,
00:03:30il nous faut un truc pour bundler les dépendances. »
00:03:34À l'époque, il y avait Rollup, esbuild et Webpack.
00:03:41Webpack ne sort pas d'ESM, donc c'était exclu.
00:03:47J'ai regardé Rollup, mais c'est assez lent.
00:03:50C'est très lent comparé à esbuild.
00:03:53C'est plus rapide que Webpack, mais lent face à esbuild.
00:03:56On a donc utilisé esbuild pour le pré-bundling,
00:03:59ce qui est ultra rapide.
00:04:00Ensuite, on servait le code source en ESM non bundlé
00:04:02et ça marchait super bien.
00:04:04Puis pour la production,
00:04:06au début on pensait :
00:04:08« Utilisons simplement esbuild pour tout bundler
00:04:10pour la prod. »
00:04:11Mais on a réalisé qu'esbuild est très limité sur
00:04:14le contrôle du découpage des fichiers (chunk splitting).
00:04:17C'est un besoin crucial pour les grosses applications
00:04:19car on veut pouvoir contrôler,
00:04:21par exemple, mettre les dépendances de bibliothèques
00:04:24dans un chunk “vendor” pour un meilleur cache.
00:04:26On veut que ce chunk ne change jamais,
00:04:28pour qu'il garde un hash constant.
00:04:32Même si je modifie mon code source,
00:04:33le hash de ce chunk doit rester le même.
00:04:35Ainsi, les utilisateurs l'ont toujours en cache
00:04:38lorsqu'ils reviennent sur le site.
00:04:39esbuild ne permet pas du tout
00:04:41ce genre d'optimisations.
00:04:44Il a un comportement par défaut pour le splitting,
00:04:47et c'est tout.
00:04:49Son système de plugins est aussi moins flexible.
00:04:53Si un plugin décide de
00:04:56traiter un fichier, c'est fini.
00:04:59Aucun autre plugin ne peut plus y toucher.
00:05:02Comme on utilisait beaucoup Rollup,
00:05:05on connaissait bien son système de plugins.
00:05:08On a fini par se dire :
00:05:10« On va utiliser Rollup pour le bundling de prod,
00:05:13et esbuild pour le pré-bundling de dev. »
00:05:15Chaque outil faisait simplement
00:05:20ce qu'il faisait de mieux dans ce combo.
00:05:23En fait, même aujourd'hui, Vite 6 repose encore
00:05:26sur cette combinaison.
00:05:27Et ça fonctionne plutôt bien pour beaucoup de gens.
00:05:31Mais il y a des soucis car esbuild
00:05:35est écrit en Go, et Rollup en JavaScript.
00:05:40Cela signifie que le build de production
00:05:41est encore assez lent comparé à,
00:05:43disons, des bundlers 100 % Rust comme RSPack.
00:05:47Pour le serveur de dev, comme esbuild
00:05:52et Rollup ont des systèmes de plugins différents,
00:05:55on ne peut pas appliquer les mêmes plugins
00:05:57aux dépendances en dev,
00:05:59alors qu'ils sont appliqués aux dépendances
00:06:01pendant le build de production.
00:06:03Et il y a des comportements d'interopérabilité subtils.
00:06:07Avec un graphe mixte ESM et CJS,
00:06:10esbuild et Rollup gèrent ça différemment.
00:06:13Il y a aussi des différences de tree-shaking.
00:06:15Même s'ils font tous deux du bon travail,
00:06:18on doit corriger toutes ces incohérences
00:06:22de comportement.
00:06:22On a réussi à faire marcher l'ensemble, mais au fond,
00:06:25on sait que ce sont deux choses différentes
00:06:29qu'on a bricolées ensemble.
00:06:31Pour accélérer le build de production
00:06:35et rendre le dev et la prod plus cohérents,
00:06:40le mieux est d'avoir un seul bundler
00:06:42qui fait les deux.
00:06:44Le problème, c'est qu'esbuild est rapide,
00:06:47mais pas très extensible.
00:06:50Le code source est entièrement en Go.
00:06:54Evan Wallace, l'auteur d'esbuild,
00:06:57est un savant fou, un génie.
00:06:59Il a rendu esbuild extrêmement rapide,
00:07:02mais ce n'est pas facile pour d'autres
00:07:05de l'étendre, d'en faire un fork
00:07:07ou de maintenir une surcouche.
00:07:10C'est très complexe.
00:07:12De plus, il est très difficile de convaincre Evan
00:07:15de faire des choses qu'il ne veut pas faire,
00:07:17car il n'a pas besoin d'argent et s'en moque.
00:07:21Alors on s'est demandé : « Et pour Rollup ? »
00:07:27Peut-on rendre Rollup plus rapide ?
00:07:28Il y a eu des tentatives,
00:07:30mais fondamentalement, Rollup est en JavaScript,
00:07:33ce qui signifie qu'il est monothread.
00:07:36On a testé les worker pools, les plugins dans des workers.
00:07:41Le mainteneur de Rollup a essayé d'intégrer
00:07:47le parseur Rust SWC dans Rollup.
00:07:50Cela n'a pas amélioré les performances de façon notable
00:07:54car dans un système mixte Rust et JS,” il y a
00:07:57toujours un coût de transfert de données.
00:07:59On s'échange d'énormes chaînes de caractères.
00:08:02S'il faut cloner la mémoire, c'est encore plus lent.
00:08:05Il s'avère que le gain brut de performance de Rust,
00:08:09quand on n'a que le parseur en Rust
00:08:12mais que tout le reste est en JavaScript,
00:08:13est annulé par le coût du passage de données.
00:08:16Au final, les performances étaient quasi identiques.
00:08:19On a conclu qu'accélérer drastiquement Rollup
00:08:23n'était pas techniquement possible.
00:08:26La seule option était de tout réécrire,
00:08:30de créer un bundler entièrement conçu
00:08:33pour Vite, et qui soit ultra rapide.
00:08:37C'est là qu'a commencé notre quête.
00:08:40On réfléchissait à la marche à suivre.
00:08:42On a décidé, au départ,
00:08:44de porter Rollup en Rust.
00:08:48Pas un fork, un portage.
00:08:49On voulait porter Rollup vers Rust.
00:08:51C'est pour ça que le projet s'appelle Rolldown.
00:08:53C'est le pendant de Rollup.
00:08:54Ça a commencé comme un portage direct,
00:08:58mais on a vite réalisé que du code JavaScript
00:09:02n'est pas facile à porter tel quel vers Rust
00:09:06car le JavaScript est très dynamique.
00:09:08C'est un langage dynamique.
00:09:11Même avec TypeScript,
00:09:13on peut toujours muter les objets comme on veut.
00:09:16Rust est très strict sur la mémoire,
00:09:19les cycles de vie, la propriété (ownership), etc.
00:09:23Il faut structurer les choses très différemment
00:09:25par rapport au JavaScript.
00:09:27Ce ne sera donc jamais simple
00:09:29de porter du code JavaScript existant
00:09:31vers un langage comme Rust.
00:09:33C'est pratiquement une réécriture.
00:09:35Au final,
00:09:37on voulait le meilleur des deux mondes.
00:09:42Le cœur de Rollup est assez minimaliste.
00:09:45Pour transformer Rollup
00:09:47en une solution prête pour la prod,
00:09:49c'est en fait assez complexe
00:09:51car il faut un plugin de résolution Node ;
00:09:54résoudre les modules Node n'est pas natif.
00:09:56Il faut l'ajouter via un plugin.
00:09:58Il faut un plugin CommonJS pour supporter ces modules
00:10:03car le cœur de Rollup est uniquement ESM.
00:10:06Ensuite, il faut ajouter plein de plugins comme
00:10:10define, inject, replace.
00:10:14Beaucoup de ces fonctions sont natives dans esbuild,
00:10:17mais nécessitent des plugins dans Rollup.
00:10:20Le pire, c'est que la plupart de ces plugins JS
00:10:25refont une analyse AST complète à chaque fois.
00:10:30Chaque plugin prend le code
00:10:33du plugin précédent,
00:10:36le parse à nouveau, le transforme,
00:10:38génère le code et les source maps.
00:10:41Et il faut ensuite fusionner toutes ces source maps.
00:10:43C'est pour ça que les systèmes de build JS ralentissent
00:10:46car chaque plugin répète ces étapes sans fin.
00:10:49On s'est dit qu'il fallait intégrer tout ça nativement.
00:10:53On a donc visé le périmètre d'esbuild,
00:10:56mais avec l'API de Rollup. C'est ça, Rolldown.
00:11:01Mais pour créer Rolldown,
00:11:03il nous fallait un parseur, des transformeurs...
00:11:07Un minificateur, un résolveur.
00:11:10Comment obtenir tout ça ?
00:11:12C'est là qu'OXC intervient.
00:11:14OXC est un ensemble d'outils bas niveau
00:11:17qui fournit tout cela.
00:11:20L'auteur d'OXC travaillait chez ByteDance à l'époque,
00:11:25et je surveillais le projet depuis longtemps.
00:11:28Boshen, l'auteur d'OXC,
00:11:30est maintenant notre VP Engineering chez Voice Zero.
00:11:33Il n'a pas rejoint la boîte dès sa création.
00:11:36J'essayais de le recruter, mais il hésitait...
00:11:38Je ne sais pas, genre...
00:11:39Mais on a commencé à bâtir Rolldown sur OXC quand même.
00:11:44On s'est dit : « C'est du solide. »
00:11:45J'y croyais vraiment,
00:11:47car j'avais étudié toutes les options.
00:11:51Je voulais quelque chose de composable.
00:11:54Je voulais que chaque partie de la chaîne
00:11:57soit utilisable individuellement sous forme de crates.
00:12:00Et je voulais une vitesse extrême.
00:12:03On a comparé OXC et SWC.
00:12:06Le parseur d'OXC est environ trois fois plus rapide
00:12:09que celui de SWC, alors qu'ils sont tous deux en Rust,
00:12:12à cause de choix de conception
00:12:15et de détails techniques bas niveau
00:12:18qui créent cette différence.
00:12:20Boshen a toujours été obsédé par
00:12:24la performance du parsing et du linking
00:12:27bien avant de nous rejoindre.
00:12:30Par exemple,
00:12:32OXC utilise un “arena allocator”
00:12:34qui place toute l'allocation mémoire de l'AST
00:12:39dans un bloc de mémoire contigu.
00:12:41Il alloue un gros bloc
00:12:43et y place directement l'AST.
00:12:45On libère donc la mémoire beaucoup plus vite.
00:12:50Cela permet aussi des choses intéressantes
00:12:53pour les plugins JS rapides dans OXLint,
00:12:57car cette mémoire contiguë permet
00:12:59de passer tout le bloc au JavaScript
00:13:01sans clonage, puis de le désérialiser côté JS.
00:13:05Il y a énormément d'avantages.
00:13:06À l'époque, j'étais très impressionné
00:13:10par le projet.
00:13:10On a décidé de baser Rolldown dessus
00:13:13et on a fini par convaincre Boshen de venir.
00:13:16Désormais, le périmètre de la société est le suivant :
00:13:21nous avons cette pile Rust verticale
00:13:24qui commence dès le parseur.
00:13:26Elle couvre tout, du bundling jusqu'à Vite,
00:13:29avec le linter, le formateur, le lanceur de tests...
00:13:33C'est une chaîne d'outils complète.
00:13:34Ce qu'on fait maintenant,
00:13:37et on y travaille depuis un moment,
00:13:40c'est de réunir tout ça dans un pack cohérent
00:13:43pour ne pas avoir à installer cinq outils séparés
00:13:47juste pour lancer une application de base.
00:13:50Vous n'aurez plus besoin
00:13:51de six ou sept fichiers de configuration différents.
00:13:55On centralise tout dans un seul fichier,
00:13:57avec la garantie que tout fonctionne ensemble
00:13:59car tout repose sur le même parseur,
00:14:02le même pipeline et le même résolveur.
00:14:05Il n'y aura plus de mauvaises surprises.
00:14:07Par exemple, avec Webpack et Jest,
00:14:10il faut configurer leur logique de résolution séparément
00:14:14car ils n'utilisent pas la même chose.
00:14:16Notre vision est de
00:14:19bâtir une pile verticale
00:14:22qui fonctionne de manière cohérente partout.
00:14:25Rendre l'expérience de dev la plus simple
00:14:29et rapide possible.
00:14:30La performance est primordiale.
00:14:32Ça me semble évident,
00:14:34mais vous avez dû voir passer des tweets disant que
00:14:39Rolldown est 20 fois plus rapide que Rollup.
00:14:43OXLint est 50 à 100 fois plus rapide qu'ESLint.
00:14:47OXFormat est 30 à 40 fois plus rapide que Prettier.
00:14:51Notre but est d'assurer la compatibilité
00:14:57pour que vous puissiez migrer sans tout refactoriser,
00:15:00tout en profitant de ces gains de performance énormes.
00:15:04Vos tests, votre linting
00:15:08et tout le reste seront bien plus fluides.
00:15:12Cela permettra aux gens
00:15:15de créer plus d'applications, plus rapidement.
00:15:17- J'adore la façon dont ça s'est accéléré,
00:15:20passant de « on a besoin d'un outil pour Vue » à
00:15:22« tiens, je veux améliorer cette pièce-là aussi ».
00:15:24Puis une autre, et encore une autre.
00:15:25Et comme vous dites, vous maîtrisez maintenant
00:15:27toute la pile verticale.
00:15:29C'est impressionnant et c'est allé très vite.
00:15:32Je disais aux gars avant de commencer
00:15:33que dans l'un de mes anciens jobs,
00:15:35on bossait sur un projet hérité
00:15:37qui utilisait Webpack et mettait 50 minutes à compiler.
00:15:40Je ne comprenais pas ce qui se passait,
00:15:42mais la première chose que j'ai dite a été :
00:15:43« On doit passer à Vite immédiatement. »
00:15:46Parce que modifier du CSS
00:15:47prenait genre deux minutes
00:15:49à chaque recompilation.
00:15:49Je me suis dit : « Ce n'est pas possible. »
00:15:52Il nous fallait le Hot Module Replacement.
00:15:54Quand j'enregistre, la modif doit apparaître.
00:15:57Vite a vraiment aidé pour ça.
00:15:59L'ascension et la vitesse
00:16:02à laquelle Vite a décollé sont incroyables.
00:16:05J'ai vu qu'il y avait 200 millions de téléchargements NPM
00:16:07par mois, ou un chiffre fou comme ça.
00:16:09C'est...
00:16:10- Oui, on a passé les 50 millions par semaine récemment.
00:16:13- C'est hallucinant.
00:16:15- Je pensais justement à ces 50 millions.
00:16:19Il y a sans doute un peu d'inflation
00:16:21due aux applis générées par IA.
00:16:23Beaucoup de projets jetables.
00:16:26Mais ça montre quand même que beaucoup de gens,
00:16:29ou probablement d'agents IA, l'utilisent.
00:16:33- L'équipe d'ingénierie
00:16:34de chez BetterStack adore Vite.
00:16:36Ils font du Rails en backend et du Vue en frontend.
00:16:40Ils ont des questions que je poserai
00:16:42au fil du podcast selon la discussion.
00:16:46Mais vous parliez de bundling,
00:16:48et l'une de leurs questions était :
00:16:49puisqu'ils utilisent les import maps dans Rails,
00:16:52quel est selon vous l'avenir du bundling ?
00:16:54On n'a plus besoin de beaucoup bundler
00:16:56si on utilise les import maps.
00:16:57Comment voyez-vous les choses évoluer ?
00:17:00- J'ai justement une page dédiée
00:17:02dans la documentation de Rolldown,
00:17:04dont le titre est :
00:17:07« Pourquoi avons-nous encore besoin de bundlers ? »
00:17:10- On vous pose souvent la question, j'imagine ?
00:17:13- Oui, et puis DHH est très présent sur le sujet
00:17:16du « no bundle, no build ».
00:17:18On est bien obligé d'y prêter attention.
00:17:20Les import maps fonctionnent jusqu'à un certain point,
00:17:24mais le concept du « sans bundling »
00:17:29ne marche que jusqu'à une certaine échelle.
00:17:35Si votre appli fait moins de mille modules,
00:17:39tout votre graphe de modules se chargera
00:17:41en quelques centaines de millisecondes,
00:17:43ce qui est tout à fait acceptable.
00:17:45Et si vous restez dans ces limites,
00:17:48c'est même génial.
00:17:50C'est chargé à la demande par défaut,
00:17:53donc sur une grosse appli
00:17:56où chaque page est isolée,
00:17:58avec son propre sous-graphe,
00:18:00ça tourne plutôt bien.
00:18:01C'est d'ailleurs pour ça que Vite est efficace en dev.
00:18:05Mais ce n'est pas une solution miracle
00:18:07car on l'a remarqué avec Vite lui-même,
00:18:09et c'est pourquoi on travaille sur
00:18:12un mode « full bundle » dans Rolldown :
00:18:15le mode sans bundling a ses limites,
00:18:18et le goulot d'étranglement est le nombre de modules.
00:18:21Il y a énormément d'applications
00:18:25qui chargent des milliers et des milliers de modules
00:18:29pendant le développement.
00:18:32On peut monter à 3 000 modules,
00:18:33et là, le navigateur sature.
00:18:36Le blocage se situe au niveau réseau
00:18:38car avec l'ESM natif,
00:18:40on envoie une requête HTTP pour chaque module.
00:18:44Si le graphe d'importation est profond,
00:18:46le navigateur doit attendre le premier module
00:18:49pour voir qu'il en faut d'autres,
00:18:52et les demander ensuite.
00:18:53Puis rebelote,
00:18:54il faut parcourir tout le graphe
00:18:57avant même d'évaluer le premier module.
00:19:00Sur une mauvaise connexion,
00:19:04cela fait de multiples allers-retours réseau
00:19:06avant de pouvoir afficher quoi que ce soit.
00:19:09Et avec des milliers de modules,
00:19:13le problème est amplifié par la latence.
00:19:17Même en local avec le serveur de dev de Vite,
00:19:20au-delà de 3 000 modules,
00:19:23le chargement peut prendre une ou deux secondes.
00:19:27Alors imaginez ce que ça donnerait en production
00:19:29sur internet.
00:19:31C'est risqué, car en bundlant le tout,
00:19:35cela prendrait peut-être 100 millisecondes.
00:19:38C'est une optimisation gratuite
00:19:40qu'il faut savoir saisir
00:19:41dès qu'on franchit un certain seuil.
00:19:45L'argument principal contre le bundling
00:19:47et les outils de build, c'est que les gens en ont marre
00:19:52de configurer ces outils.
00:19:55Ils ont eu des bugs,
00:19:56des soucis de config insolubles.
00:20:01Comme Webpack a rendu tout ça complexe,
00:20:04beaucoup de gens,
00:20:06quand on leur parle de configurer un bundler,
00:20:08se disent : « C'est pas pour moi, j'en veux pas. »
00:20:11Il y a un vrai ressentiment.
00:20:14Dès qu'ils entendent « étape de build »,
00:20:16ils veulent l'éviter à tout prix.
00:20:19Ce qu'on veut faire avec nos outils,
00:20:22c'est
00:20:24rendre ces concepts limpides.
00:20:28Ce ne sera jamais simple
00:20:32pour les grosses applis complexes.
00:20:34Mais on veut que ce soit assez simple pour un nouveau projet
00:20:37pour ne pas avoir à trop y réfléchir
00:20:41si l'appli n'est pas trop tordue.
00:20:45On doit pouvoir dire : « Je lance ce projet,
00:20:48il utilise Vite et je sais que tout va bien se passer. »
00:20:50D'ailleurs, il y a un projet communautaire
00:20:55appelé vite-rails ou ruby-vite
00:20:59qui permet d'utiliser Vite très facilement dans Rails.
00:21:05Le setup sans build a ses atouts.
00:21:12C'est rassurant car on sait qu'on
00:21:14évite plein de dépendances
00:21:17et d'incertitudes qui pourraient tout casser.
00:21:20Certains ont aussi perdu confiance
00:21:23dans les systèmes de build en se disant :
00:21:26« Il y aura toujours un truc qui cloche. »
00:21:29« Le build va casser quand je mettrai à jour une lib. »
00:21:33Éviter tout ça est tentant.
00:21:36Mais au bout du compte,
00:21:37si la technologie est assez bonne et stable,
00:21:41on veut toujours la meilleure UX pour l'utilisateur,
00:21:45et le 100 % non bundlé oblige à rester dans
00:21:48des contraintes de taille très strictes.
00:21:52Il faut aussi se soucier de l'optimisation,
00:21:54car on doit faire attention :
00:21:57« Est-ce que j'importe trop de trucs »
00:22:01sur telle ou telle page ?
00:22:03Comment gérer le cache des modules intelligemment ?
00:22:06Même avec Rails sans bundling,
00:22:08il faut une sorte de pré-processus
00:22:11pour signer les modules et qu'ils soient bien mis en cache.
00:22:15On finit inévitablement par devoir
00:22:18s'occuper de l'optimisation pour que ça marche.
00:22:21C'est une option qui fonctionne pour
00:22:24pas mal de cas d'usage, mais ce n'est pas
00:22:29une solution universelle.
00:22:31Certains créent des applications énormes,
00:22:35avec des tonnes de fonctionnalités.
00:22:37On ne peut pas leur imposer le non-bundling
00:22:39et les enfermer dans une
00:22:42impasse de performance inoptimisable.
00:22:45- Pour ceux qui ne connaissent pas bien,
00:22:49en quoi Vite est différent de Vite+ ?
00:22:54Et qu'est-ce que les gens y gagnent ?
00:22:57- Pour Vite+, nous effectuons un
00:23:02léger pivot sur ce que cela doit être exactement.
00:23:06L'idée, c'est que si vous débutez
00:23:11complètement en développement JavaScript,
00:23:14si vous êtes novice,
00:23:17et que vous avez une machine toute neuve.
00:23:21Comment passer de zéro à une appli fonctionnelle
00:23:25avec HMR, les meilleures pratiques,
00:23:28le linting, le formatage, les tests déjà configurés ?
00:23:33Aujourd'hui, c'est beaucoup de choses à apprendre.
00:23:36La première chose, c'est :
00:23:38« Qu'est-ce que Node.js ? »
00:23:39« Comment je l'installe ? »
00:23:40« C'est quoi un gestionnaire de versions Node ? »
00:23:42« Quel gestionnaire de paquets choisir ? »
00:23:44« Quel outil de build ? »
00:23:45« Quel linter ? »
00:23:47Il faut répondre à tout ça.
00:23:49On veut supprimer toutes ces questions.
00:23:50On vous donne un point de départ d'opinion
00:23:52et c'est prêt à l'emploi.
00:23:54Vous n'avez même pas besoin d'installer Node.js.
00:23:57On expérimente une nouvelle façon
00:23:59d'utiliser Vite+ avec un simple curl :
00:24:03curl -sS [https://vplus.dev/install](https://www.google.com/search?q=https://vplus.dev/install) | bash.
00:24:08Puis vous faites 'vp new' pour un nouveau projet,
00:24:15puis 'vp dev' et voilà,
00:24:17toute la suite est configurée pour vous.
00:24:21Vous avez le linter, le formateur,
00:24:25le testeur, le bundler... vous pouvez même
00:24:28scaffolder un monorepo.
00:24:31Il gère le bundling de bibliothèques.
00:24:32On prévoit d'intégrer des outils comme lint-staged,
00:24:39ou la gestion des journaux de modifications (changelogs).
00:24:41C'est utile pour les gros monorepos de libs.
00:24:44Il y a aussi une commande 'vp run'
00:24:49qui est un exécuteur, un peu comme 'pnpm run',
00:24:52mais en plus sophistiqué,
00:24:57façon Nx, capable de déterminer
00:24:59l'ordre optimal d'exécution des tâches
00:25:03et de les mettre en cache intelligemment.
00:25:04C'est à la carte (opt-in).
00:25:07Si vous n'avez pas besoin
00:25:11de ces fonctions avancées,
00:25:13vous pouvez l'utiliser comme le Vite de base.
00:25:17Votre expérience de dev sera exactement la même
00:25:18que sur Vite aujourd'hui.
00:25:20Mais si vous voulez aller plus loin,
00:25:24passer à l'échelle d'un monorepo
00:25:27prêt pour la prod, l'outil vous suit.
00:25:31Et comme c'est bâti sur
00:25:33toutes ces technologies éprouvées
00:25:35déjà utilisées par des experts.
00:25:39C'est ce qu'on veut apporter.
00:25:44On convertit beaucoup d'utilisateurs actuels
00:25:47à nos solutions open source,
00:25:48des gens migrent de Webpack vers Vite,
00:25:52ou d'ESLint vers OXLint.
00:25:54Ce qu'on espère avec Vite+,
00:25:57c'est répondre à la question :
00:26:00« Je débute en JavaScript, je fais quoi ? »
00:26:02C'est la voie la plus rapide et la plus simple.
00:26:05On veut répondre à ça
00:26:07et aussi assurer une intégration parfaite avec l'IA.
00:26:11- Est-ce le but de l'entreprise, alors ?
00:26:14Beaucoup de gens s'inquiètent de voir
00:26:15une société derrière des projets open source,
00:26:17craignant que certaines fonctions deviennent payantes.
00:26:20Mais est-ce plutôt que,
00:26:23on pourrait toujours faire ce que Vite+ propose soi-même,
00:26:25au prix de beaucoup de configuration,
00:26:26et que Vite+ est juste un pack pratique
00:26:29qui réunit tout, comme vous l'avez dit ?
00:26:31Vous ne mettriez donc jamais de fonction derrière un paywall.
00:26:34- Oui, on a un peu évoqué l'idée
00:26:37du modèle de licence de Vite+.
00:26:39On disait : « Si votre entreprise
00:26:41dépasse un certain seuil, il faut payer. »
00:26:44Notre réflexion a évolué
00:26:46car on a discuté avec beaucoup d'entreprises intéressées
00:26:50pour trouver le bon équilibre
00:26:53entre une large diffusion de l'outil
00:26:56et notre capacité à capturer de la valeur
00:27:00pour être pérennes.
00:27:02On va probablement relever ce seuil très haut.
00:27:07Seule une infime catégorie d'entreprises
00:27:11devrait payer.
00:27:14La majorité des utilisateurs en profitera
00:27:17gratuitement, et aussi parce que
00:27:20nous travaillons sur des idées de services
00:27:25plutôt que sur la vente de fonctionnalités.
00:27:27Un service couplé à Vite+
00:27:31qui améliorerait la qualité du code,
00:27:35la surveillerait
00:27:37et vous donnerait des conseils ou des astuces.
00:27:39Il y a énormément de connaissances métier
00:27:41qu'on peut maintenant rendre accessibles
00:27:44via des agents IA. C'est la voie qu'on explore.
00:27:48- D'accord. Je me demandais aussi,
00:27:51si Vite+ rend tout plus pratique,
00:27:53pensez-vous que l'IA peut le faire avec les solutions actuelles ?
00:27:56Ou avez-vous déjà essayé
00:28:00de simplement demander à l'IA d'assembler
00:28:02le linter, le build et le reste ?
00:28:05Est-ce qu'elle ne risque pas de s'appuyer sur de vieilles technos
00:28:07à cause de ses données d'entraînement et de créer un bazar ?
00:28:09- On voit beaucoup d'applis générées par IA
00:28:13qui utilisent encore Vite 5, par exemple.
00:28:17Car quand on sort une nouvelle version
00:28:20ou de nouvelles fonctions, il faut du temps pour
00:28:26que les modèles soient entraînés dessus.
00:28:29Les modèles sont toujours un peu en retard sur l'actu
00:28:31technologique. C'est aussi là qu'on veut intervenir.
00:28:34Si on sort une nouvelle version de Vite+,
00:28:37elle proposera...
00:28:41Déjà, elle viendra avec ses propres fichiers .md d'agents.
00:28:44Quand vous mettrez à jour Vite+,
00:28:47ça mettra à jour la partie correspondante dans le .md de l'agent
00:28:50et pointera vers les nouvelles compétences
00:28:54de votre paquet NPM.
00:28:58On pourrait aussi
00:29:00vous donner un prompt expliquant que
00:29:05pour passer de telle version à telle autre,
00:29:08ce prompt aidera votre agent à le faire proprement.
00:29:10C'est aux auteurs des outils
00:29:13de fournir ces aides.
00:29:17On a remarqué une chose :
00:29:19OXLint, OXFormat et Vitest
00:29:22sont utilisés dans OpenClaw.
00:29:26OpenClaw est un projet de code un peu fou.
00:29:29C'est 54 000 lignes de JavaScript
00:29:31qui bougent à une vitesse dingue.
00:29:34L'auteur valide des changements sans même les lire.
00:29:36Il y a beaucoup de choses
00:29:40qui n'ont aucun sens là-dedans.
00:29:43On a regardé des PR qui mettaient à jour OXLint,
00:29:45ou qui tentaient de l'adopter.
00:29:46L'IA hallucinait des options qui n'existent pas.
00:29:51On se disait : « Attendez, on n'a pas cette option. »
00:29:54Et quand le type checking échouait,
00:29:57elle le « réparait » juste en désactivant la règle.
00:29:59« Ok, je coupe ça pour que le type passe. »
00:30:00L'IA prend des raccourcis
00:30:04si on ne lui donne pas de garde-fous.
00:30:06Peter, l'auteur d'OpenClaw,
00:30:07n'est pas un développeur TypeScript.
00:30:09Il a juste choisi TypeScript pour son projet.
00:30:12Ce n'est pas un expert en outillage.
00:30:15Il n'a pas d'expérience dans ce domaine.
00:30:18L'IA l'a aidé à le faire.
00:30:20Mais en tant qu'auteurs des outils utilisés par l'IA,
00:30:22nous voyons bien où elle pèche.
00:30:25Si on ne souligne pas ces erreurs,
00:30:26votre code va s'effondrer dans trois mois.
00:30:29C'est là la valeur ajoutée
00:30:30qu'on peut apporter à l'ère de l'IA :
00:30:35comment s'assurer de livrer vite
00:30:38sans tout casser ?
00:30:41Comment continuer à ajouter des fonctions avec l'IA ?
00:30:44La vélocité de production de code
00:30:46augmente massivement grâce aux agents.
00:30:50On livre bien plus vite qu'avant.
00:30:54Mais ces fonctions sont-elles bien relues ?
00:30:58Quand on valide 20 PR par jour,
00:30:59est-ce que le projet reste
00:31:03bien maintenu ?
00:31:06La santé du code devient très instable.
00:31:11Il faut donc, de temps en temps,
00:31:14faire comme avec les développeurs humains :
00:31:19après une phase de livraisons intensives,
00:31:22on s'arrête et on réfléchit.
00:31:25« Ok, il faut nettoyer tout ça. »
00:31:26« Il faut payer la dette technique accumulée. »
00:31:30Avec les agents IA, on livre plus vite,
00:31:33donc on accumule de la dette plus vite.
00:31:36Il faut donc utiliser l'IA pour rembourser cette dette.
00:31:37C'est un aspect que beaucoup oublient
00:31:38et qui nécessite une solution dès maintenant.
00:31:40- Oui, j'ai jeté un œil au code d'OpenClaw,
00:31:42et comme vous dites, c'est un peu chaotique.
00:31:45C'est un excellent exemple de ce qui arrive
00:31:49quand on lâche l'IA sans laisse,
00:31:53en la laissant faire ce qu'elle veut
00:31:56sans aucune surveillance.
00:31:57C'était assez fascinant de voir ce projet
00:32:00faire le buzz ces dernières semaines.
00:32:03Sur le rôle de l'IA justement,
00:32:05est-ce que vous changez votre façon de créer
00:32:07un formateur ou un linter pour que les agents les utilisent mieux ?
00:32:09Est-ce que ça influe sur le futur,
00:32:11ou est-ce que le fait de les avoir conçus
00:32:13pour être rapides aide juste naturellement à l'ère de l'IA ?
00:32:16Leur rapidité doit forcément aider les agents.
00:32:19- C'est une excellente piste de réflexion,
00:32:22car on commence justement à se pencher sur le problème.
00:32:26Le périmètre initial de ces linters
00:32:29et formateurs est colossal,
00:32:31car on cherche la compatibilité
00:32:34avec des piliers comme ESLint et Prettier,
00:32:38qui sont là depuis une décennie.
00:32:40Les gens ont des règles sur mesure,
00:32:45des cas d'usage hérités,
00:32:48et on veut être compatible à 100 %.
00:32:50C'est un travail de titan, mais on y est enfin
00:32:53car on vient d'atteindre la compatibilité totale
00:32:54avec les plugins ESLint.
00:32:56On passe tous les tests de plugins ESLint,
00:33:00et on a aussi atteint une conformité totale
00:33:03avec Prettier pour notre formateur.
00:33:06Ces deux étapes franchies signifient que
00:33:09nous pouvons sereinement recommander nos outils.
00:33:13Maintenant, quelle est la suite ?
00:33:17Comment le linting et le formatage
00:33:21doivent-ils s'adapter aux agents ?
00:33:23On y travaille activement.
00:33:25- En gros, on attend la réponse.
00:33:28C'est encore en évolution, oui.
00:33:31L'IA change tellement de choses
00:33:34dans le monde du code, c'est passionnant.
00:33:38Pour revenir sur Vite+,
00:33:40vous en avez fait la démo à la ViteConf 2025
00:33:44et vous avez montré une commande 'vp install'.
00:33:49Est-ce que c'est toujours d'actualité ?
00:33:53Et quel sera le degré de chevauchement entre Vite+
00:33:54et quelque chose comme Bun ?
00:33:57- Bonne question.
00:33:59Les choses ont un peu bougé depuis la ViteConf.
00:34:01Je dirais que la version finale
00:34:04de Vite+ ressemblera un peu à Bun, dans un sens.
00:34:06L'expérience de démarrage, comme je disais,
00:34:10si vous avez une machine vierge,
00:34:14et que vous voulez créer une appli web
00:34:17le plus vite possible.
00:34:19Il suffira d'un curl sur le script
00:34:21pour obtenir un binaire global nommé 'vp'.
00:34:23Une fois dans un projet,
00:34:27si vous avez un fichier .node-version
00:34:30et un champ 'packageManager' dans le package.json,
00:34:33ce sont les standards pour spécifier
00:34:38votre environnement de travail JS.
00:34:41Vite+, quand vous ferez 'vp run build',
00:34:43ou n'importe quelle commande
00:34:45impliquant du JavaScript,
00:34:46choisira automatiquement la bonne version de Node
00:34:51et le bon gestionnaire de paquets.
00:34:56Même si vous n'utilisez pas
00:35:02Vite+ spécifiquement dans ce projet,
00:35:04tant que vous utilisez
00:35:06ces fichiers de config classiques,
00:35:11Vite+ peut remplacer nvm.
00:35:15Il peut remplacer Corepack.
00:35:20Vous n'aurez plus à vous soucier des versions.
00:35:22L'idée est que pour lancer votre workflow,
00:35:26vous n'utilisez plus 'npm run'.
00:35:28Vous utilisez 'vp run'.
00:35:31Et 'vp run' s'assurera
00:35:36d'utiliser le bon Node,
00:35:40le bon gestionnaire de paquets,
00:35:44et de faire ce qu'il faut.
00:35:45Pour la commande 'install', cela signifie que...
00:35:48On n'a pas notre propre gestionnaire de paquets pour l'instant.
00:35:52C'est plutôt un équivalent de Corepack,
00:35:55je ne sais pas si vous connaissez 'ni',
00:35:59le paquet d'Anthony Fu.
00:36:02Avec 'ni', quand vous lancez la commande,
00:36:05il devine quel gestionnaire utiliser,
00:36:06que ce soit pour installer, désinstaller,
00:36:10ou lancer un script.
00:36:14'vp install' fait la même chose,
00:36:16avec la gestion du gestionnaire lui-même.
00:36:19C'est le rôle de Corepack.
00:36:24Même sans rien d'installé,
00:36:27si votre package.json indique
00:36:30que vous utilisez pnpm
00:36:34à une certaine version.
00:36:36'vp install' vérifiera
00:36:41si cette version de pnpm est là.
00:36:45Sinon, il l'installera
00:36:48et lancera 'pnpm install'.
00:36:49On veut résoudre plus
00:36:51que le simple linting ou formatage.
00:36:56C'est tout le workflow JavaScript quotidien.
00:36:58On veut éliminer ces points de friction
00:37:01pour qu'un débutant n'ait même pas à y penser.
00:37:03Dès le premier scaffold de projet,
00:37:07on utilisera la dernière LTS de Node et on conseillera pnpm.
00:37:08Ces infos seront écrites dans votre projet.
00:37:12Ainsi, quand vous y reviendrez,
00:37:14tout sera déjà configuré correctement.
00:37:16- Pourquoi recommandez-vous pnpm ?
00:37:20- Il offre le bon équilibre entre fonctionnalités,
00:37:25fiabilité, occupation disque et vitesse.
00:37:31Et il gère bien les workspaces, avec les catalogues...
00:37:34Quand on a
00:37:36comparé les fonctions de workspace,
00:37:40pnpm nous a semblé le plus équilibré.
00:37:43Bun est incroyablement rapide,
00:37:45mais pnpm suffit déjà à beaucoup d'entre nous.
00:37:50On n'exclut pas non plus
00:37:53de supporter Bun dans notre runtime
00:37:55et notre gestionnaire de versions.
00:37:59Vous pourrez dire : « Je veux utiliser Bun »
00:38:02et on lancera tout avec Bun.
00:38:06- Pour Vite 6, vous aviez dit qu'il sortirait
00:38:10après le Nouvel An lunaire ?
00:38:15- Oui.
00:38:19- Sur quels points de la bêta
00:38:21vous concentrez-vous avant la sortie ?
00:38:25- Surtout la stabilité.
00:38:29Le CI de l'écosystème,
00:38:33nous avons un système de CI massif
00:38:35où l'on teste Vite 6 sur tous les projets dépendants.
00:38:37Récemment, on a validé
00:38:40tous les tests de SvelteKit sur Vite 6.
00:38:42C'est une étape majeure
00:38:44car la stabilité est notre priorité absolue.
00:38:49N'oubliez pas qu'on
00:38:52remplace deux bundlers éprouvés
00:38:54par un nouveau créé de toutes pièces.
00:38:58C'est comme changer les moteurs d'un avion en plein vol
00:39:00en espérant que tout continue de planer.
00:39:04On ne peut pas être trop prudents.
00:39:06- Je voulais demander, pourquoi le choix de Rust ?
00:39:10Est-ce parce que votre équipe
00:39:15connaissait déjà ce langage ?
00:39:17Je vois beaucoup de gens dans le monde TypeScript
00:39:21préférer le Go car la transition est plus proche.
00:39:24Même l'équipe TypeScript passerait au Go
00:39:27pour leur compilateur.
00:39:28- Oui, le choix du Go par
00:39:30l'équipe TypeScript s'explique car,
00:39:33comme je l'ai dit, il est plus facile d'y porter du TypeScript.
00:39:36Le modèle mental est très similaire.
00:39:40Un des freins pour nous a été que
00:39:43le support de WebAssembly par Go est médiocre.
00:39:46Il produit des binaires Wasm énormes
00:39:48et les performances Wasm
00:39:49ne sont pas terribles comparées à Rust.
00:39:51Avec Rust,
00:39:55cela dépendait beaucoup des talents disponibles,
00:39:57des gens déjà passionnés
00:39:58et investis dans cet écosystème.
00:40:02Par exemple, quand on a cherché
00:40:04des fondations sur lesquelles bâtir,
00:40:09aucun parseur ou chaîne d'outils
00:40:13n'était aussi bien implémenté ou composable.
00:40:17OXC est vraiment fait pour servir de base.
00:40:21On n'a pas vu d'équivalent dans le monde Go.
00:40:26esbuild a son propre parseur,
00:40:29mais c'est un gros système monolithique.
00:40:32On ne peut pas juste en extraire le parseur.
00:40:35Aussi, toutes les fonctions d'esbuild,
00:40:39comme les transforms ou la minification,
00:40:41sont implémentées,
00:40:44pour la performance, en seulement trois passes d'AST.
00:40:46Cela signifie que dans une même passe,
00:40:48on mélange plusieurs préoccupations :
00:40:54transformation,
00:40:59injection,
00:41:04modification...
00:41:08Ce n'est pas idéal pour un système extensible
00:41:11où l'on voudrait,
00:41:14par exemple, permettre aux gens
00:41:18d'activer ou désactiver des transformations,
00:41:23ou d'écrire les leurs.
00:41:25On veut un système de couches propres,
00:41:30pour que plusieurs personnes puissent y travailler en même temps.
00:41:33On a donc fait avec ce qu'on avait.
00:41:36Rust est aussi extrêmement performant.
00:41:37C'est vrai qu'il est délicat d'écrire des transformeurs en Rust.
00:41:39On a passé beaucoup de temps
00:41:41à concevoir une bonne architecture
00:41:42pour les visiteurs et le pipeline,
00:41:45à cause des problèmes de propriété mémoire.
00:41:51Modifier un parent quand on est
00:41:54tout en bas de l'arbre est très complexe.
00:41:57Mais on a trouvé une solution.
00:42:01C'est plus simple en Go, mais comme on veut
00:42:03que nos outils puissent compiler
00:42:07vers WebAssembly et tourner dans le navigateur...
00:42:09Rolldown peut tourner dans le navigateur,
00:42:13et il y est très rapide.
00:42:16esbuild aussi, mais
00:42:22Rust gère mieux WebAssembly.
00:42:26- Puisque l'équipe code en Rust,
00:42:28comment utilisez-vous l'IA ?
00:42:31Vous disiez tout à l'heure que beaucoup
00:42:34dans l'équipe y ont recours.
00:42:37Est-ce qu'elle s'en sort bien sur vos tâches ?
00:42:39Pour le développement web classique,
00:42:42il y a tellement d'exemples sur GitHub
00:42:44que l'IA est très bien entraînée.
00:42:45Mais votre travail est d'un niveau
00:42:49technique bien plus bas niveau.
00:42:51Est-ce qu'elle aide vraiment,
00:42:53ou codez-vous encore
00:42:57essentiellement à la main ?
00:42:59- Elle est vraiment utile.
00:43:01Le domaine change à une vitesse folle.
00:43:05L'an dernier, j'étais sceptique.
00:43:07Je me disais : « J'ai essayé, ça ne marche pas pour moi »
00:43:09car mon travail est trop bas niveau.
00:43:12Puis Boshen, qui dirige OXC,
00:43:14est devenu le plus grand adepte de l'IA
00:43:16dans l'entreprise.
00:43:19Il s'est lancé dans des expériences folles.
00:43:21Le mois dernier, en une semaine,
00:43:23il a livré 60 PR avec l'IA,
00:43:25en faisant tourner des agents en parallèle.
00:43:28On a tenté des trucs dingues,
00:43:30comme porter le compilateur Angular vers Rust,
00:43:32juste pour voir si l'IA y arrivait.
00:43:34Et contre toute attente, ça marche.
00:43:38On aura peut-être quelque chose là-dessus plus tard.
00:43:41Notre perception des
00:43:45capacités de l'IA
00:43:49est remise à jour tous les quelques mois
00:43:52avec les nouveaux modèles,
00:43:59les meilleurs environnements de test,
00:44:03et des astuces comme le mode plan
00:44:04ou l'écriture de fichiers .md pour les agents.
00:44:07En appliquant ces petites choses, on réalise
00:44:11qu'elle s'améliore vraiment.
00:44:13L'adoption varie selon les personnes.
00:44:16On encourage tout le monde dans la boîte
00:44:19à l'utiliser là où ça leur semble pertinent.
00:44:24On leur donne un crédit mensuel
00:44:27pour qu'ils puissent utiliser Claude s'ils veulent.
00:44:29Certains sont ravis et
00:44:33très loquaces sur le sujet.
00:44:39Et ils livrent de très bonnes PR.
00:44:43Tout dépend de la façon dont on s'en sert.
00:44:46Il y a la capacité brute du modèle,
00:44:48mais aussi l'environnement qu'on utilise.
00:44:51Cette surcouche logicielle
00:44:55ressemble aux frameworks JS d'autrefois.
00:45:00Chacun fait sa propre version,
00:45:03et au fond, ils font tous plus ou moins la même chose.
00:45:06Certains ont quelques astuces de plus,
00:45:08mais trois mois plus tard, tout le monde les a.
00:45:13C'est un domaine hyper concurrentiel.
00:45:18Idem pour les modèles :
00:45:22Sonnet 3.5 vient de sortir,
00:45:24DeepSeek va sortir un nouveau modèle.
00:45:27Ça ne va cesser de s'améliorer.
00:45:33Il est clair que l'IA est extrêmement capable
00:45:36si on sait la guider,
00:45:40mais ce guidage reste crucial.
00:45:45On ne peut pas demander à quelqu'un qui ne connaît pas Rust
00:45:49de travailler sur OXC, même avec l'IA.
00:45:52Il ne saurait même pas quoi demander.
00:45:54Mais un ingénieur Rust déjà compétent sur OXC
00:45:57devient bien plus productif
00:46:00et peut livrer plus de fonctions, plus vite.
00:46:03C'est mon point de vue.
00:46:08Personnellement,
00:46:11je produis très peu de code avec l'IA
00:46:13par rapport aux autres ingénieurs de la boîte.
00:46:17Je m'en sers surtout pour de la recherche ou comme partenaire de réflexion.
00:46:18- C'est un monde étrange,
00:46:21le code prend une drôle de direction.
00:46:23J'ai du mal à suivre
00:46:26combien de sous-agents il faut utiliser,
00:46:32les agents parallèles, quel fichier markdown ajouter
00:46:34à son repo...
00:46:37Ça change tout le temps.
00:46:41On verra bien où tout cela nous mènera
00:46:45dans le futur.
00:46:50Revenons à Vite un instant.
00:46:54Dans Vite 6, vous avez ajouté le support des React Server Components.
00:46:58À mon avis, les RSC
00:47:00n'ont pas été le succès immédiat attendu par l'équipe.
00:47:03Il y a des frameworks qui les rejettent,
00:47:08comme TanStack.
00:47:13Et Remix a même pris une direction totalement différente.
00:47:16Que pensez-vous des RSC,
00:47:20et pourquoi ça n'a pas pris autant que prévu ?
00:47:25- J'ai toujours été très réservé à ce sujet,
00:47:27voire sceptique depuis le début.
00:47:29C'est pour ça qu'on n'a jamais envisagé
00:47:32d'implémenter un équivalent dans Vue.
00:47:34La question fondamentale est :
00:47:37quel problème essaie-t-on de résoudre ?
00:47:38Je pense qu'il y a eu un gros forcing marketing.
00:47:40Pour hyper les gens,
00:47:43on l'a présenté comme la solution miracle.
00:47:43Le truc qui allait révolutionner le web
00:47:47et accélérer tous les sites.
00:47:52À l'arrivée, on réalise que
00:47:54ce n'est pas adapté à tous les cas.
00:47:57Ça n'apporte un bénéfice
00:48:00que dans des situations bien précises.
00:48:01Ailleurs, c'est juste un tas de compromis.
00:48:04Puisque tout se passe sur le serveur,
00:48:07chaque interaction nécessite maintenant
00:48:10un aller-retour réseau.
00:48:14C'est assez
00:48:17catastrophique pour l'expérience hors-ligne.
00:48:20Et on n'échappe pas vraiment
00:48:23au coût de l'hydratation.
00:48:28On déplace juste le coût de l'hydratation client
00:48:30vers le serveur.
00:48:35On paie le prix à chaque requête
00:48:38en faisant plus de travail côté serveur.
00:48:40Il y a des théories du complot disant que
00:48:42Vercel pousse ça pour vendre plus de temps de calcul.
00:48:44Je ne pense pas que ce soit le but,
00:48:48mais il est vrai qu'utiliser les RSC
00:48:51augmente la charge serveur.
00:48:54On fait tourner plus de choses là-haut,
00:48:56on consomme plus de minutes.
00:48:59Certes, il y a des avantages comme
00:49:04réduire la taille du bundle client.
00:49:06Mais il y a d'autres façons de régler ça
00:49:08sans forcément devoir
00:49:10faire tourner un serveur Node.js.
00:49:14C'est mon avis personnel.
00:49:20En frontend, on aime se demander :
00:49:21« Quelle architecture choisir ? »
00:49:26« Une SPA ? Du SSR ? »
00:49:29Les RSC, c'est encore plus pointu.
00:49:31Se demander si on a besoin des RSC
00:49:33est une question complexe.
00:49:38Et si on choisit d'y aller,
00:49:44il faut être conscient du prix à payer,
00:49:47car si ça n'a pas été bien adopté, c'est d'abord parce que
00:49:51c'est extrêmement complexe.
00:49:52Le concept est dur à expliquer.
00:49:54Le fonctionnement est dur à comprendre.
00:49:56On a dû creuser le sujet car
00:49:59cela demande une orchestration de l'outil de build
00:50:01pour que tout le système tienne debout.
00:50:02Très peu de gens comprennent
00:50:06comment fonctionnent les RSC bruts.
00:50:07La plupart les connaissent via
00:50:10Next.js, car un utilisateur moyen
00:50:14ne saurait pas les configurer seul.
00:50:17Il faut vraiment maîtriser l'ensemble
00:50:19pour monter un setup de zéro
00:50:21avec React et Vite ou Webpack.
00:50:24Ce n'est pas fait pour être configuré à la main.
00:50:27Il faut passer par un framework.
00:50:31C'est leur raison d'être.
00:50:33Mais pour intégrer les RSC,
00:50:35le framework doit faire des choix :
00:50:37comment présenter les RSC
00:50:39pour garder une bonne expérience développeur ?
00:50:43Next.js n'a pas tout à fait réussi selon moi.
00:50:46La confusion entre 'use server' et 'use client',
00:50:48le graphe mixte où, dès qu'on met 'use server',
00:50:50certaines choses cessent de fonctionner.
00:50:52On se retrouve limité à certains outils,
00:50:56puis on importe une dépendance
00:50:58qui ne supporte pas 'use server'.
00:51:02Et hop, on repasse en 'use client'.
00:51:04Tous ces petits
00:51:07désagréments de DX font qu'on se demande :
00:51:11« Pour obtenir les gains promis,
00:51:14est-ce que je veux vraiment supporter ces agacements
00:51:17au quotidien et pour toujours ? »
00:51:20« Est-ce que ça en vaut la peine ? »
00:51:23Il est normal que les gens hésitent.
00:51:27Et même pour les auteurs de frameworks,
00:51:29Vercel a une relation très étroite avec l'équipe React
00:51:30pour collaborer et itérer rapidement.
00:51:33Mais pour les tiers...
00:51:36Techniquement, Vercel est un tiers aussi,
00:51:39mais pour Remix ou TanStack,
00:51:42ce n'est pas simple de
00:51:47travailler sur le sujet car beaucoup d'itérations d'API
00:51:51de l'équipe React privilégient Next.js.
00:51:55Je ne les critique pas vraiment pour ça
00:51:58car Vercel est leur partenaire de conception.
00:52:01Ils veulent s'associer à eux
00:52:03pour peaufiner et livrer cette fonction,
00:52:06ce qui est logique.
00:52:08Mais du coup,
00:52:10Next.js a longtemps été la seule vraie façon
00:52:12d'utiliser les RSC.
00:52:15Et comme l'expérience n'était pas géniale,
00:52:20ça n'a pas décollé comme prévu.
00:52:24Et même dans un monde idéal
00:52:27où les RSC auraient une DX parfaite,
00:52:28je ne pense pas que ce soit la solution unique
00:52:35pour tous les cas.
00:52:37Il faut bien comprendre
00:52:40quand ça fait sens et quand ça ne le fait pas.
00:52:42Trop de compromis.
00:52:45- J'imagine qu'il n'y a pas eu de pression
00:52:49pour faire pareil avec Vue,
00:52:52vu les liens avec Vercel.
00:52:57Ils ont racheté NuxtLabs,
00:53:02le méta-framework au-dessus de Vue
00:53:06qui assemble tout l'ensemble.
00:53:08Comment se passe la relation Nuxt et Vue
00:53:13maintenant qu'ils appartiennent à Vercel ?
00:53:15- Honnêtement, ça n'a pas changé grand-chose.
00:53:17Vercel est resté très discret depuis le rachat,
00:53:19donc l'équipe Nuxt est ravie
00:53:21de continuer son travail.
00:53:25Il y a sans doute des efforts pour
00:53:29optimiser Nuxt sur Vercel,
00:53:31en faire un citoyen de première classe.
00:53:33Mais Vercel est consciente
00:53:38de son image dans la communauté
00:53:41et ils font très attention à ne pas l'écorner davantage.
00:53:46Après le rachat de Nuxt,
00:53:49la dernière chose qu'ils voudraient
00:53:50est de forcer Nuxt à faire des trucs que les gens détestent.
00:53:52- Malheureusement, Evan a dû nous quitter plus tôt
00:53:54pour un appel important,
00:53:57mais nous le remercions pour son temps
00:53:59et ses avis passionnants sur toutes nos questions.
00:54:01Si vous avez des invités que vous aimeriez voir,
00:54:03dites-le nous en commentaires.
00:54:05Et si vous avez des retours,
00:54:08n'hésitez pas non plus.
00:54:09Ça nous intéresse.
00:54:13Retrouvez-nous partout où vous écoutez vos podcasts,
00:54:14comme Spotify ou Apple Podcasts.
00:54:18À la prochaine, c'était un plaisir.
00:54:21- Salut tout le monde.
00:54:24- Salut tout le monde.
00:54:25- Un plaisir, merci à tous.
00:54:30- Merci beaucoup de nous avoir rejoints.
00:54:32make a first-class citizen.
00:54:34But I think the thing is Vercel is aware
00:54:38that some of the images it has in the community
00:54:43and they would be really careful not to damage it further.
00:54:47And so after acquiring Nuxt, right,
00:54:50the last thing they'd want to do
00:54:52is to force Nuxt to do things people don't like.
00:54:54- Unfortunately, Evan had to leave early
00:54:56to take an important call,
00:54:58but we really appreciate his time
00:55:00and all his insightful opinions on all the questions we asked.
00:55:04If you have any future guests you'd love on the podcast,
00:55:06please let us know in the comments.
00:55:08And if you have any feedback in general,
00:55:10also let us know too.
00:55:11We'd love to hear it.
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.

Key Takeaway

Evan Yu détaille comment son entreprise, VoidZero, reconstruit l'outillage JavaScript en Rust pour offrir une performance extrême et une expérience développeur unifiée à l'ère de l'intelligence artificielle.

Highlights

L'évolution de Vite vers une pile technologique verticale complète incluant Rolldown et OXC.

L'utilisation intensive de Rust pour surpasser les limites de performance du JavaScript et du Go.

La vision derrière Vite+ : simplifier radicalement le workflow de démarrage des développeurs.

Les limites techniques du concept "no-bundle" pour les applications à grande échelle.

L'intégration stratégique de l'IA pour accélérer le développement tout en gérant la dette technique.

Le scepticisme d'Evan Yu concernant l'adoption et la complexité des React Server Components (RSC).

Timeline

Introduction et présentation de VoidZero

Evan Yu, le créateur de Vue et Vite, présente sa nouvelle entreprise nommée VoidZero qui se consacre au développement d'outils open source haute performance. Il énumère les projets majeurs de la suite tels que Rolldown, Vitest et la chaîne d'outils OXC. Ces outils visent à couvrir l'intégralité du cycle de développement, du parsing à la minification. L'objectif est de créer un écosystème cohérent où chaque pièce s'emboîte parfaitement. Cette introduction pose les bases de la vision d'Evan pour l'avenir de l'outillage web.

L'organisation du travail et l'impact de l'IA

Evan explique comment son rôle a évolué depuis la fondation de l'entreprise, passant de l'écriture de code à la prise de décisions stratégiques sur l'expérience développeur (DX). Il souligne que son équipe utilise massivement des outils d'IA comme Claude et Cursor pour générer du code Rust complexe. Les ingénieurs se concentrent désormais sur la validation et l'architecture plutôt que sur la syntaxe brute. Il mentionne également le défi de transformer ces outils open source en un produit commercialement viable. Cette section illustre la transition d'un développeur solo vers un leader de produit technologique.

Genèse de Rolldown et limites d'esbuild

La discussion porte sur les raisons techniques ayant mené à la création de Rolldown, un nouveau bundler basé sur Rust. Evan analyse les compromis actuels de Vite qui utilise esbuild pour le développement et Rollup pour la production. Il explique que bien qu'esbuild soit ultra-rapide, son manque de flexibilité dans le découpage des fichiers (chunk splitting) et son système de plugins limité empêchent une optimisation poussée. L'incohérence entre les environnements de dev et de prod crée des bugs subtils d'interopérabilité. Rolldown est donc né du besoin d'unifier ces deux étapes avec une performance maximale et une compatibilité Rollup.

La supériorité technique d'OXC et de Rust

Evan détaille l'architecture d'OXC, une suite d'outils bas niveau dont le parseur est trois fois plus rapide que celui de SWC. Il explique l'utilisation stratégique des "arena allocators" en Rust qui optimisent la gestion de la mémoire pour l'AST. Cette approche permet de réduire drastiquement les coûts de transfert de données entre Rust et JavaScript. Le gain de performance est massif : OXLint est 50 à 100 fois plus rapide qu'ESLint. L'objectif final est de centraliser toute la configuration dans un seul fichier pour éliminer la complexité des outils actuels comme Webpack.

Le débat sur le bundling et l'avenir des import maps

Interrogé sur la tendance "no-bundle" poussée par des frameworks comme Rails, Evan expose une vision nuancée. Il admet que les import maps sont excellentes pour les petits projets, mais qu'elles atteignent leurs limites au-delà de 3000 modules en raison de la latence réseau. Le navigateur sature lorsqu'il doit effectuer des milliers de requêtes HTTP en cascade pour résoudre un graphe d'importation profond. Le bundling reste selon lui une optimisation nécessaire pour garantir la meilleure expérience utilisateur sur des connexions instables. Il insiste sur le fait que l'outillage doit simplifier cette étape sans imposer de configuration complexe.

Vite+ : Simplification et modèle économique

L'invité définit Vite+ comme une solution clé en main pour les développeurs, éliminant le besoin d'installer manuellement Node.js ou de configurer des linters. Il décrit un workflow simplifié via une commande unique 'vp' qui gère automatiquement les versions et les dépendances. Concernant la monétisation, Evan envisage un modèle où seules les très grandes entreprises paieraient, tandis que les services liés à l'IA apporteraient de la valeur ajoutée. L'IA est présentée comme un outil capable de générer du code mais nécessitant des garde-fous pour éviter l'accumulation de dette technique. Cette vision place Vite+ comme un orchestrateur intelligent pour le développement moderne.

Comparaison avec Bun et workflow quotidien

Evan compare l'approche de Vite+ à celle de Bun, précisant que son outil vise à être un gestionnaire de workflow agnostique capable de supporter différents runtimes. Il recommande l'usage de pnpm pour sa fiabilité et sa gestion efficace des monorepos, tout en restant ouvert au support de Bun. Le choix de Rust est justifié par sa capacité à compiler vers WebAssembly de manière performante, permettant aux outils de tourner directement dans le navigateur. Il explique que la structure modulaire d'OXC permet une extensibilité que le modèle monolithique d'esbuild n'offre pas. Cette section souligne l'importance de la portabilité des outils de build.

Développement assisté par IA et expériences Angular

L'équipe de VoidZero repousse les limites de l'IA en tentant des expériences audacieuses comme le portage du compilateur Angular vers Rust en une semaine. Evan note que l'efficacité de l'IA dépend énormément du guidage humain et de la connaissance approfondie du domaine par l'ingénieur. Il observe que les modèles s'améliorent tous les trois mois, rendant possibles des tâches autrefois jugées irréalisables. Malgré cette vélocité, il préfère utiliser l'IA comme partenaire de réflexion plutôt que comme simple générateur de code. L'avenir du développement semble résider dans cette symbiose entre expertise humaine et puissance de calcul.

Avis sur les React Server Components et Conclusion

Dans la dernière partie, Evan exprime son scepticisme historique vis-à-vis des React Server Components (RSC), critiquant leur complexité et le marketing excessif. Il souligne que les RSC augmentent la charge serveur et compliquent la gestion de l'état client sans offrir de bénéfices universels. La distinction floue entre 'use client' et 'use server' nuit à l'expérience développeur selon lui. Il conclut sur la relation entre Vue, Nuxt et Vercel, affirmant que l'autonomie de Nuxt reste préservée. Le podcast s'achève sur une note positive concernant l'avenir de l'écosystème malgré les défis techniques persistants.

Community Posts

View all posts