00:00:00(musique entraînante) - Bonjour à tous.
00:00:06Je m'appelle Lydia.
00:00:07Mon titre est actuellement Directrice de Propagande chez BUN.
00:00:11Et si vous me connaissez un peu,
00:00:13vous savez que j'adore parler des runtimes JavaScript et de la performance.
00:00:17En fait,
00:00:17avant de rejoindre BUN,
00:00:18j'étais chez Vercel pendant quelques années pour enseigner aux développeurs Next comment construire des applications plus vite.
00:00:24Je suis donc très enthousiaste d'être ici aujourd'hui pour vous montrer combien mieux on peut faire en combinant la performance du Framework Next avec la performance du runtime BUN.
00:00:35Mais avant de vous parler de BUN lui-même,
00:00:38je veux revenir un peu en arrière et vous montrer ce qui rend les frameworks comme Next.js si spéciaux.
00:00:45Parce qu'ils ont vraiment redéfini notre façon de voir la performance sur le web.
00:00:49Cela n'a pas seulement rendu les sites plus rapides.
00:00:52Cela a rationalisé chaque étape du processus.
00:00:55Nous avons eu un bundling plus intelligent avec Webpack et maintenant avec Turbo Pack.
00:00:59Nous avons l'optimisation intégrée des images et des polices.
00:01:02Nous avons le rendu côté serveur efficace,
00:01:04le rendu côté statique et maintenant nous avons l'ISR et maintenant j'imagine que le RSC pour apporter la récupération de données directement dans le composant.
00:01:12Et toutes ces améliorations ont en quelque sorte poussé ce que le framework peut optimiser,
00:01:18mais vraiment seulement jusqu'à un certain point.
00:01:21Il y a toujours eu cette une couche fondamentale que Next.js n'a pas pu optimiser jusqu'à présent.
00:01:26Et ce n'est pas par manque d'efforts d'ingénierie ou de capacité,
00:01:30mais c'est simplement hors du domaine de Next.
00:01:34Et c'est le runtime lui-même.
00:01:37Normalement,
00:01:37quand vous exécutez Next dev ou que vous déployez sur Vercel,
00:01:40votre application Next s'exécute sur Node.
00:01:42Cela signifie que le runtime de Node exécute votre JavaScript.
00:01:45Il gère la boucle d'événements,
00:01:47les entrées/sorties de fichiers,
00:01:48tout.
00:01:49Et il fait le lien entre votre code JavaScript et le système d'exploitation.
00:01:53Et cela a du sens car Node a été le runtime par défaut pendant environ les 15 dernières années.
00:01:59C'est éprouvé,
00:02:00c'est fiable,
00:02:01mais en 2025,
00:02:02c'est devenu un peu un goulot d'étranglement.
00:02:06Ne me comprenez pas mal, Node est fantastique.
00:02:09Il a rendu possible l'exécution de JavaScript sur le serveur.
00:02:13Avant cela,
00:02:14comme avant que Node soit introduit en 2009,
00:02:17JavaScript était vraiment juste pour le navigateur.
00:02:20Node a changé cela en nous donnant un runtime avec un moteur JavaScript,
00:02:23une boucle d'événements,
00:02:24des entrées/sorties asynchrones et des API pour faire toutes les choses que les navigateurs ne peuvent pas faire.
00:02:29Comme lire des fichiers depuis le disque,
00:02:31la mémoire,
00:02:32tout ce truc.
00:02:33Maintenant,
00:02:34sous le capot,
00:02:35Node utilise le moteur JavaScript V8.
00:02:37C'est le moteur rapide Chrome de Google,
00:02:39ce qui est excellent pour les tâches de longue durée,
00:02:42comme un onglet dans votre navigateur Chrome.
00:02:44Mais bien sûr, V8 n'est juste qu'un moteur.
00:02:46Il sait seulement exécuter du JavaScript.
00:02:49Il ne peut pas ouvrir des fichiers,
00:02:51établir des connexions TCP,
00:02:53et tout ce genre de choses.
00:02:54C'est là que les API intégrées de Node entrent en jeu.
00:02:57Comme FS, HTTP, NET, et ainsi de suite.
00:03:01Donc ces API sont en quelque sorte le pont entre notre code JavaScript et le système d'exploitation.
00:03:07Et ces API elles-mêmes s'appuient sur une bibliothèque C appelée libuv.
00:03:13Ce n'est pas construit pour JavaScript lui-même.
00:03:16C'est plutôt comme une abstraction générique que Node utilise pour pouvoir faire des choses comme les entrées/sorties de fichiers,
00:03:23le réseau,
00:03:24et des trucs sur tous ces différents systèmes d'exploitation.
00:03:27Donc,
00:03:28quand nous appelons quelque chose comme fs.readFile dans notre code JavaScript,
00:03:32nous demandons vraiment juste à l'ordinateur,
00:03:34je veux lire ce fichier depuis le disque.
00:03:36Mais avant de pouvoir y arriver,
00:03:38il doit d'abord passer par V8,
00:03:40ou comme du code JavaScript à V8.
00:03:42Ensuite, il le transmet à la liaison C++ de Node.
00:03:46Ceci appelle ensuite libuv,
00:03:47et ce n'est même pas mentionner le travail des threads et tout ce genre de surcharge.
00:03:52Et ce n'est qu'alors que libuv effectue réellement l'appel système à notre kernel pour obtenir réellement ce fichier depuis le disque.
00:03:58Et pendant que tout cela se passe,
00:04:00nous avons la boucle d'événements que libuv utilise pour que le reste de notre code JavaScript puisse toujours s'exécuter et ainsi de suite.
00:04:06Et ce modèle fonctionne bien.
00:04:08Nous utilisons toujours Node, mais ce n'est pas optimal.
00:04:13Donc,
00:04:13en 2009,
00:04:14à nouveau quand Node a été introduit,
00:04:16notre matériel ressemblait très différemment.
00:04:19Les serveurs avaient peut-être environ quatre cœurs,
00:04:22une mémoire limitée,
00:04:23et le stockage était assez lent.
00:04:25Les threads étaient aussi chers,
00:04:27donc créer un nouveau thread pour chaque connexion n'était vraiment pas bien mis à l'échelle.
00:04:32Donc le modèle de Node était excellent pour cette époque car nous pouvions utiliser un thread pour gérer environ des milliers de connexions vraiment efficacement.
00:04:40Mais en 2025, notre matériel ressemble très différemment.
00:04:44Nous avons maintenant des centaines de cœurs de CPU,
00:04:47des téraoctets de mémoire,
00:04:48et le stockage est environ 50 fois plus rapide.
00:04:51Mais nous utilisons toujours le modèle de Node basé sur 2009.
00:04:55Cela pousse toujours tout à travers cette même boucle d'événements.
00:04:59Et encore, c'est bien.
00:05:00Comme l'architecture de Node est bien quand les serveurs fonctionnaient pendant des jours.
00:05:04Mais à l'époque moderne,
00:05:05nous avons souvent comme des fonctions serverless ou nous avons des serveurs de développement.
00:05:09Tous ces scripts plus courts comme des rafales qui doivent démarrer rapidement et s'exécuter pendant une période beaucoup plus courte.
00:05:16Donc dans ces environnements,
00:05:18chaque milliseconde de démarrage et chaque couche de données compte ici car elles ajoutent toutes à la latence.
00:05:24Maintenant,
00:05:25encore une fois,
00:05:27quand vous exécutez votre application next,
00:05:31vous l'exécutez sur Node.
00:05:34Cela signifie que tout ce que votre application fait,
00:05:36donc comme le rendu des pages,
00:05:37la diffusion des actifs,
00:05:38la diffusion en continu des réponses,
00:05:40ils passent tous par toutes ces couches que nous venons de voir.
00:05:43Donc du JavaScript à V8 à Node, tous ces trucs.
00:05:46Et Next a fait un travail incroyable en extrayant chaque bit de performance malgré le fait que le runtime Node bloque toujours certaines choses.
00:05:57Parce qu'au bout du compte,
00:05:58toutes ces améliorations s'exécutent toujours sur Node.
00:06:01Donc quand vous démarrez comme un serveur de développement ou reconstruisez des fichiers,
00:06:05le rechargement à chaud,
00:06:07vous heurtez toujours ces limites de runtime.
00:06:09Donc si nous voulons vraiment aller plus vite,
00:06:11nous devons regarder au-delà du framework.
00:06:13Nous devons aller plus profondément.
00:06:15Nous devons repenser le runtime lui-même.
00:06:18C'est là que BUN intervient.
00:06:20BUN n'est pas juste comme une autre couche construite au-dessus de Node.
00:06:24C'est un tout nouveau runtime construit de zéro pour le matériel que nous avons réellement en 2025.
00:06:33Donc au lieu d'être écrit en C++ au-dessus de LibUV comme vous l'avez vu avec Node,
00:06:38BUN est construit en Zig.
00:06:40Et c'est un langage moderne des systèmes qui s'exécute beaucoup plus près du métal.
00:06:45Donc pour le moteur JavaScript,
00:06:47BUN utilise le moteur JavaScript Core vraiment rapide d'Apple.
00:06:51Et cela démarre vraiment rapidement,
00:06:53principalement parce qu'il peut reporter certaines des optimisations d'initialisation que les moteurs comme V8 font.
00:06:59Et cela s'exécute aussi vraiment rapidement,
00:07:01ce qui,
00:07:02encore une fois,
00:07:02est parfait pour les tâches modernes que nous utilisons actuellement avec les serveurs de développement,
00:07:07les environnements serverless,
00:07:08et ces scripts de construction plus courts.
00:07:10Le runtime lui-même est écrit en Zig.
00:07:13Donc les API BUN et toutes les parties qui gèrent les E/S asynchrones.
00:07:17Donc où Node utilise LibUV pour toutes ces opérations asynchrones,
00:07:22donc comme lire des fichiers,
00:07:23les demandes réseau,
00:07:25et ainsi de suite,
00:07:26BUN peut implémenter celles-ci comme des appels système directs au système d'exploitation car elle est écrite en Zig.
00:07:33Maintenant,
00:07:34pour les demandes réseau,
00:07:35nous utilisons une useSockets,
00:07:36donc c'est un peu différent.
00:07:37Mais nous supprimons tellement de couches d'abstraction en utilisant Zig à la place de LibUV.
00:07:44Donc maintenant,
00:07:45si vous voulez lire un fichier avec le runtime BUN,
00:07:47il va bien sûr,
00:07:48de votre code JavaScript.
00:07:49Il va maintenant au moteur JSC vers Zig,
00:07:52qui peut alors faire l'appel système direct.
00:07:55Donc,
00:07:55encore une fois,
00:07:56moins de couches entre notre code JavaScript et le système d'exploitation réel.
00:08:01Et le résultat ici est que tout semble tellement plus rapide du démarrage à l'accès aux fichiers,
00:08:07aux serveurs HTTP,
00:08:08et ainsi de suite.
00:08:09Mais BUN ne se concentre pas seulement sur la performance.
00:08:12Nous visons également à être 100% compatible avec Node.
00:08:15Donc nous voulons nous assurer que toutes les API propres de Node fonctionnent.
00:08:19Mais ensuite,
00:08:19il livre également des tonnes d'API intégrées supplémentaires,
00:08:23comme S3,
00:08:23SQL,
00:08:24ou Squeel,
00:08:25peu importe comment vous voulez le dire.
00:08:27Redis, hachage, un shell, tellement de choses.
00:08:30Et si vous avez déjà utilisé d'autres langages de programmation,
00:08:33comme Go ou Python,
00:08:35cette approche fournie par des batteries est très familière pour vous.
00:08:39Mais en tant que développeurs JavaScript,
00:08:41nous nous sommes tellement habitués à installer des dépendances pour à peu près tout.
00:08:45Je utilise le hachage de mot de passe dans presque toutes mes applications.
00:08:48Mais je dois toujours installer une dépendance chaque fois que je l'utilise.
00:08:52Donc BUN change cela.
00:08:54Les trucs que vous utilisez à peu près tout le temps sont juste construits directement dans le runtime lui-même.
00:08:59C'est juste construit sur le global.
00:09:01Et encore,
00:09:01ce ne sont pas juste comme des wrappers de niveau surface au-dessus d'une dépendance NPM.
00:09:06Ils sont vraiment construits en Zig.
00:09:08Donc ils sont optimisés pour les performances pour le matériel moderne.
00:09:12Donc par exemple, BUN a un client SQL intégré.
00:09:16Vous pouvez donc vous connecter directement à Postgres,
00:09:20MySQL,
00:09:20et SQLite en utilisant une seule API.
00:09:23Vous n'avez pas à installer d'autres dépendances.
00:09:26Et encore, ce n'est pas juste appeler un paquet NPM.
00:09:30C'est vraiment tout BUN qui parle directement au système.
00:09:35Et ce n'est pas juste la commodité que nous avons ces constructions intégrées.
00:09:38Les options de BUN sont généralement aussi beaucoup plus rapides que les alternatives Node et NPM.
00:09:44Donc par exemple ici,
00:09:45BUN.SQL est jusqu'à 11 fois plus rapide que MySQL 2 sur Node,
00:09:50ce qui est vraiment bien.
00:09:51Ou vous pouvez utiliser comme le client S3 de BUN.
00:09:54Et cela fonctionne directement avec n'importe quel stockage compatible S3.
00:09:58Donc Amazon S3,
00:09:59Super Base Storage,
00:10:00Cloudflare R2,
00:10:01vous l'appelez.
00:10:03Et encore, aussi cette API est incroyablement rapide.
00:10:06Donc ici,
00:10:06nous pouvons voir que c'est jusqu'à 6 fois plus rapide que AWS S3 SDK sur Node.
00:10:12Bien sûr,
00:10:13vous pouvez toujours utiliser vos dépendances normales avec le runtime BUN également.
00:10:17Vous n'avez pas à utiliser ces API intégrées.
00:10:20Mais elles réduisent beaucoup votre taille de bundle,
00:10:23car nous n'ajoutons plus ces dépendances.
00:10:25Et cela aide aux vulnérabilités NPM que nous avons vues le mois dernier,
00:10:30car vous n'avez pas à les installer.
00:10:32Il y a des tonnes d'autres API.
00:10:33Je vous recommande fortement de consulter les documents également.
00:10:37Mais BUN ne livère pas seulement un runtime.
00:10:40Il livre également un gestionnaire de paquets vraiment rapide qui est jusqu'à 17 fois plus rapide que YARN,
00:10:47sept fois plus rapide que NPM,
00:10:49et quatre fois plus rapide que PNPM.
00:10:51Et la bonne chose,
00:10:52vous n'avez pas à utiliser le runtime BUN pour utiliser BUN install.
00:10:55Et c'est juste-- vous pouvez utiliser BUN install avec Node.
00:10:58Ça va juste marcher.
00:10:59Donc vous n'avez rien à changer dans votre projet.
00:11:03Il a également un bundler et un transpileur intégrés vraiment rapides.
00:11:06Donc vous pouvez servir et construire vos fichiers instantanément.
00:11:09Donc vous n'avez pas besoin de Webpack,
00:11:10ESBuild,
00:11:11pas de configuration supplémentaire.
00:11:12Et la bonne chose c'est qu'il supporte aussi TypeScript et JSX directement.
00:11:18Il a également un runner de test vraiment rapide qui est jusqu'à 14 fois plus rapide que vTest et 23 fois plus rapide que jest quand nous SSR'd comme 1 000 tests React.
00:11:26Donc encore une fois,
00:11:27vous obtenez des tests vraiment rapides.
00:11:29Vous n'avez rien à installer.
00:11:31Donc tout cela semble vraiment bien,
00:11:33mais comment pouvons-nous utiliser le runtime BUN?
00:11:35Et ensuite, honnêtement, c'est vraiment simple.
00:11:38Après avoir installé BUN,
00:11:39vous n'avez qu'à mettre à jour votre commande de démarrage ou votre commande dev et ajouter bun run --bun.
00:11:45C'est tout.
00:11:46Vous exécutez maintenant le runtime BUN.
00:11:48Maintenant,
00:11:48vous vous demandez peut-être,
00:11:50pourquoi ai-je besoin de ce --bun?
00:11:51Comme, je dis déjà bun run.
00:11:54C'est,
00:11:54encore une fois,
00:11:55parce que BUN se soucie vraiment de la compatibilité des nœuds.
00:11:57Donc normalement,
00:11:59si nous utilisons juste bun run next dev,
00:12:02BUN détectera que next CLI utilise ce shebang de nœud.
00:12:07Et dans ce cas,
00:12:07BUN sera comme,
00:12:08OK,
00:12:09je comprends que je dois utiliser nœud.
00:12:11Donc alors il va juste reculer par défaut à nœud,
00:12:13même si nous avons dit bun run.
00:12:15Mais avec le drapeau --bun,
00:12:16nous forçons en quelque sorte pour ignorer le shebang et dire,
00:12:19OK,
00:12:20nous utilisons juste le runtime bun.
00:12:21Donc juste comme une explication supplémentaire.
00:12:25Donc maintenant avec cette commande,
00:12:27bun démarre votre serveur next dev.
00:12:29Le bundler lui-même est toujours next.
00:12:31Donc c'est toujours, vous savez, Turbo Pack.
00:12:33Je suppose que Web Pack,
00:12:34Turbo Pack,
00:12:34maintenant c'est le défaut.
00:12:35Mais maintenant le runtime en dessous de tout cela,
00:12:38donc la chose qui exécute votre JavaScript,
00:12:41lit les fichiers,
00:12:41sert les réponses,
00:12:42et cetera,
00:12:43c'est tout bun.
00:12:44Et parce que bun est conçu pour être compatible avec node,
00:12:47vous ne devriez rien avoir à changer dans votre code.
00:12:50Ou vos paquets ou votre middleware.
00:12:51Tout devrait toujours fonctionner.
00:12:53Si ce n'est pas le cas,
00:12:55c'est aussi considéré comme un bogue dans bun.
00:12:57C'est supposé être 100% compatible avec node.
00:12:59Donc si vous essayez cela,
00:13:00vous rencontrez des problèmes,
00:13:01laissez-nous savoir.
00:13:02Mais vous ne devriez rien avoir à réécrire.
00:13:05Et maintenant que votre application s'exécute au-dessus de bun,
00:13:08vous avez accès à toutes les API intégrées de bun.
00:13:10Donc par exemple,
00:13:11nous pouvons juste utiliser le client S3,
00:13:13non,
00:13:13dans comme une fonction serveur,
00:13:14dans un composant de serveur React,
00:13:16et cetera.
00:13:16Donc nous n'avons pas à installer de dépendances.
00:13:18Donc juste pour comparer ce que cela aurait normalement ressemblé avec ceci avec node,
00:13:22vous pouvez voir qu'avec bun,
00:13:24nous avons beaucoup moins de code.
00:13:25Nous avons moins de dépendances.
00:13:27Et c'est instantanément compatible avec tous les autres fournisseurs S3 également.
00:13:32Donc si vous voulez passer d'Amazon S3 à comme Cloudflare R2,
00:13:35stockage de base super,
00:13:37tous ces autres fournisseurs,
00:13:39c'est vraiment simple.
00:13:40Ou un plus complet,
00:13:41nous pouvons utiliser S3,
00:13:43le shell bun,
00:13:44et SQL directement dans un composant serveur React.
00:13:47Donc d'abord,
00:13:48nous aimons interroger la base de données avec SQL pour récupérer un article de blog,
00:13:52générer une URL S3 présignée pour l'image,
00:13:54utiliser le shell bun pour compter les mots.
00:13:57Encore une fois,
00:13:57il n'y a pas comme une couche API supplémentaire ou des outils tiers que bun appelle.
00:14:02Bun gère le runtime,
00:14:03les connexions de base de données,
00:14:06et le shell tous nativement en SIG,
00:14:08si près du métal.
00:14:10Et encore, bien sûr, ce n'est pas seulement S3 SQL.
00:14:12Nous avons accès à toutes les API de bun en ajoutant simplement bun run --bun devant next dev.
00:14:20Mais bien sûr,
00:14:21maintenant vous pourriez penser,
00:14:22OK,
00:14:23je n'utilise pas Postgres.
00:14:24Je n'utilise pas S3.
00:14:25Je n'utilise pas de dépendances folles,
00:14:26donc pourquoi devrais-je m'en soucier?
00:14:28Ce qui m'a attiré à bun avant que je ne rejoigne était honnêtement juste l'incroyable DX.
00:14:34Vous pouvez juste exécuter n'importe quel fichier JS,
00:14:37TS,
00:14:38TSX,
00:14:38JSX,
00:14:39peu importe sans aucune configuration.
00:14:41Cela fonctionne juste.
00:14:41Vous ne devez pas penser à TSNode, Babel, SWC, et cetera.
00:14:46Donc même si vous n'utilisez pas next,
00:14:48même si vous développez juste,
00:14:50vous voulez un script de construction rapide,
00:14:52juste en utilisant bun run,
00:14:54juste essayez-le,
00:14:54cela rend votre vie tellement mieux car vous n'avez besoin d'aucune configuration.
00:14:59Bun vient également avec bun x.
00:15:01Et c'est bun's kind of équivalent à NPX.
00:15:04Encore une fois, vous n'avez pas à changer quoi que ce soit.
00:15:06Vous n'avez pas à utiliser le runtime bun pour cela.
00:15:08Vous pouvez juste changer NPX avec bun x.
00:15:11Et vous voyez des améliorations de démarrage instantanées.
00:15:13Donc par exemple,
00:15:15utiliser bun x create next step est comme 5 fois plus rapide que NPX create next step.
00:15:20Et encore,
00:15:21vous n'avez pas à utiliser le runtime bun pour cela.
00:15:23C'est juste beaucoup plus rapide.
00:15:25Mais bien sûr,
00:15:26il y a aussi bun install,
00:15:27qui encore une fois,
00:15:28ne vous oblige pas à changer le runtime.
00:15:31Cela rend vos installations tellement plus rapides,
00:15:34même sur les projets next basiques.
00:15:36Maintenant évidemment,
00:15:38exécuter bun localement est une chose.
00:15:39Mais comment déployons-nous les applications qui s'exécutent sur bun?
00:15:42Parce que c'est, bien sûr, un tout nouveau runtime.
00:15:46Maintenant,
00:15:47vous pouvez déjà utiliser Next.js sur bun sur plusieurs plates-formes comme render,
00:15:51railway,
00:15:51ou conteneuriser votre application avec Docker.
00:15:54Mais nous sommes tous des développeurs Next.js.
00:15:56Idéalement,
00:15:57nous voulons également pouvoir déployer sur Vercel.
00:16:00Donc naturellement,
00:16:01nous avons tweeté Guillermo,
00:16:03le demandant gentiment pour le support natif de bun sur Vercel.
00:16:07Et nous avons rapidement obtenu une réponse assez prometteuse.
00:16:10Et puis quelques semaines plus tard,
00:16:12le support de bun a été réalisé au moins en interne.
00:16:15Je suis donc très enthousiaste que le support natif de bun viendra sur Vercel très,
00:16:20très bientôt.
00:16:20Et cela signifie que vous pourrez-- [APPLAUDISSEMENTS]
00:16:25Les applaudissements vont aux grands ingénieurs chez Vercel qui ont rendu cela possible.
00:16:29Mais c'est très excitant car cela signifie que nous pouvons maintenant exécuter des applications bun aussi facilement que n'importe quel autre projet Next sur Vercel.
00:16:37Donc aussi juste un exemple du monde réel.
00:16:39Je ne suis pas sûr que vous pouvez le voir sur l'écran.
00:16:41Mais exécuter une API HONO avec bun a déjà vu une baisse de 30% ou une baisse d'utilisation du CPU en exécutant juste bun sur Vercel.
00:16:49C'est, bien sûr, un framework différent.
00:16:50C'est HONO API.
00:16:52Mais c'est les mêmes avantages de runtime que vous obtiendrez si c'était comme une fonction serveur,
00:16:56RSC,
00:16:57et cetera.
00:16:57Parce que bun économise beaucoup sur l'utilisation du CPU et de la mémoire.
00:17:02Maintenant nous,
00:17:02bien sûr,
00:17:03nous n'avons pas besoin d'attendre le support natif de bun pour commencer à l'utiliser dans nos applications.
00:17:06La façon la plus simple est de commencer à l'utiliser ou à l'adopter progressivement.
00:17:11Donc d'abord,
00:17:11je vous recommande juste de passer à bun install.
00:17:14Change rien dans votre base de code.
00:17:16Cela utilise juste le gestionnaire de paquets vraiment rapide de bun.
00:17:19Aussi,
00:17:19si vous êtes intéressé de savoir pourquoi bun install est tellement plus rapide,
00:17:22j'ai écrit un article à ce sujet pas trop longtemps.
00:17:24Je vous recommande fortement de le consulter.
00:17:26Cela explique juste-- vous savez,
00:17:27nous ne sautons pas seulement les étapes.
00:17:29Nous faisons peu importe.
00:17:29Cela explique en quelque sorte l'ingénierie système derrière elle qui la rend tellement plus rapide.
00:17:35Maintenant après avoir utilisé bun install,
00:17:37puis essayez d'utiliser le runtime bun.
00:17:39Vous pouvez juste l'utiliser localement avec bun run --bun.
00:17:42Testez votre application.
00:17:42Voyez si tout fonctionne.
00:17:44C'est supposé.
00:17:45Si ce n'est pas le cas, laissez-nous savoir.
00:17:47Et ensuite,
00:17:48finalement,
00:17:48vous pouvez en quelque sorte progressivement passer aux API natives de bun où cela a du sens.
00:17:53Vous pouvez,
00:17:53bien sûr,
00:17:54toujours mélanger et assortir ces dépendances NPM.
00:17:57Mais la meilleure partie c'est aussi que chaque étape ici est réversible.
00:18:00Donc si vous utilisiez l'une des API natives de bun et qu'elle ne fonctionnait pas,
00:18:04vous pouvez toujours juste basculer sur node.
00:18:06Mais c'est définitivement la peine de vérifier.
00:18:08Maintenant avant de terminer cette présentation,
00:18:11je veux juste dire un grand merci à l'équipe incroyable d'ingénieurs chez bun.
00:18:17La plupart des gens pourraient connaître Jared,
00:18:19mais il y a toute une équipe derrière bun qui travaille si fort chaque jour pour rendre bun encore plus rapide,
00:18:24plus stable,
00:18:25et tellement plus amusant à utiliser.
00:18:27Ils repoussent vraiment les limites de ce qui est possible avec JavaScript.
00:18:32Donc next a réimaginé comment nous construisons pour le web,
00:18:35mais bun réimagine ce qui le propulse.
00:18:38Merci beaucoup d'être venu à ma présentation,
00:18:40et je suis tellement enthousiaste de voir ce que vous allez construire avec bun et Next.