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.