Passer au contenu principal

Ceux qui ont lu notre guide complet sur Node.js savent que l’environnement JavaScript côté serveur est devenu incontournable.

On parle de « Bun », « Bun.sh » ou « Bun JS » depuis plus d’un an. Mais maintenant il est en version 1.0 et ça devient sérieux, ou pas.
Est-il venu le temps de mettre Node JS de côté ? Bun va-t-il devenir mainstream là où Deno et Yarn n’ont pas réussi ? Qui est derrière bun ?
On répond à toutes ces questions.

Bun va vite, plus vite que ViteJS

Les temps d’exécution de Bun sont terriblement compétitifs par rapport à tous les concurrents dans l’écosystème Javascript.
Et en plus Bun veut tout remplacer tout l’écosystème Node.js d’un coup, au revoir : npx, ws, fetch, dotenv, babel, webpack, npm, yarn et lerna, jest et vitest.
Bun supporte déjà typescript.

Bun exécute un "hello world" TypeScript 5x plus vite que esbuild avec Node.js. - d'après la doc Bun.sh

Bun exécute un « hello world » TypeScript 5x plus vite que esbuild avec Node.js. – d’après la doc Bun.sh

Node JS c’était un quickwin à la base. C’est le moteur Chromium V8 de chrome qui du jour au lendemain s’est retrouvé côté serveur. Du coup toute l’API JavaScript fonctionnait bien. La gouvernance du Web a inspiré la fondation Node.js. Celle-ci va même fusionner avec la JS Foundation pour devenir « OpenJS Foundation ». Bref, on sait que le web évolue lentement, mais il est là pour durer.

Bun ne supporte pas toute l’API que Node.js supporte. Ça lui permet d’être optimisé pour cet usage serveur. Ils n’ont pas tout redéveloppé, ils sont bien partis du framework JavaScriptCore. Celui-ci sert à construire le WebKit, le moteur d’exécution de Safari. Il est donc plus bas niveau que le moteur V8.

Et il est implémenté avec un langage bas niveau qui s’appelle ZIG. Le fondateur du framework explique qu’il utilise des pointeurs étiquetés pour réduire l’espace mémoire utilisé par les pointeurs de fonction. Autre exemple, le ramasse-miette (GC, Garbage Collector) est programmé dès que la mémoire utilisée augmente (alors que Chrome prend toute la mémoire disponible).

C’est pour ça que les devs l’adorent parce que dès le premier jour, le temps de build et divisé par 4 ou par 10. Et puis commencer un projet est aussi simple que de mettre une lasagne Picard au four. Alors qu’un projet Node, c’est une pièce montée pour faire un « Hello World ».

Qui est derrière Bun JS ?

La rockstar, c’est Jarred Sumner. Il est lauréat de la bourse Thiel. Peter Thiel c’est le premier investisseur de Facebook, l’auteur de Zero To One, un Venture Capitalist de la Silicon Valley qui est très clivant. Et sa fondation donne propose une fellowship, 100K$ pour des jeunes qui veulent abandonner les études pour construire un projet.

Les contributeurs derrière Bun sont passé de 100 à 300 personnes en 12 mois. Et c’est aussi grâce à cette communauté que Bun a été intégré dans Vercel, Replit, Ruby on Rails ou Laravel Sails.

Mais c’est bien Jarred Sumner qui fait la majorité du code. Son historique de commit Github donne des semaines de plus de 80h de travail. Il faut dire que les développeurs ZIG qui connaissent les APIs de JavaScriptCore, c’est pas courant. J’ai cherché dans la CVThèque de WeLoveDevs, j’en ai pas trouvé.

M. Sumner a maintenant une entreprise appelée Oven.sh qui a annoncé avoir levé 7M$. Il a recruté du monde, en indiquant bien dans les annonces qu’il faut vouloir dédier sa vie à Bun.sh pour être retenu.

La puissance du Venture Capital sur un marché mature

Le marché qu’attaque Bun est vraiment très mature. Il y a des milliers de contributeurs aux paquets npm. Il y a des centaines de milliers de téléchargements tous les jours sur les repos npm. Les entreprises et les devs font tourner des centaines de milliers d’applications chaque jour avec Node. Bref, ce marché est déjà très mature !

Et la fondation OpenJS a des moyens limités. Aucun développeur, aucune développeuse de la fondation n’a de salaire. Ils sont tous bénévoles et ont un taff à côté. Sauf si leur taff, c’est d’être employé d’IBM et qu’IBM leur demande de contribuer pour maintenir une compatibilité.

Leur compétition, c’est des devs workhalocoholic, qui pratiquent le sommeil polyphasique comme Elon Musk, et vivent sur de la VC-Money. C’est sûr que l’équipe de Bun.sh va faire des choses qu’ils n’oseront pas faire.

Si Hollywood écrivait un scénario pour le film « Disruption of Node.js Ecosystem », on serait dans la situation initiale.

Quel futur pour Bun.sh ?

Les commentaires ne sont pas tendre avec Bun. Déjà personne ne le trouve dans Google, il n’y a que des photos de nourriture, sauf si vous recherchez « Bun js »

Bun en production c’est pas aujourd’hui. Il est assez certain que si vous avez une application de 50K lignes de code qui tourne en production sur Node.js vous n’allez pas la passer sur Bun aujourd’hui. L’API n’est pas complètement implémentée. Le célèbre Champion Axel Shaita m’a fait remarquer que beaucoup de paquets Node ne fonctionnent pas avec Bun. Ça concerne AdonisJS, Fastify ou Pino.

Et vous allez sûrement faire exploser le coût de maintenance. Déjà Node, si on essaie de prendre un code qui a 2 ans, on peut avoir du mal à le faire tourner parce que les runtimes ont changé, les dépréciations sont importantes (pour de bonnes raisons d’ailleurs). Bun, ils veulent aller vite et pas s’embêter avec la retro-compatibilité. Attendez-vous à voir des Segfaults et des breaking change.

@Neoelectron sur twitter fait remarquer que Bun avait des segfaults connus il y a encore quelques mois

@Neoelectron sur twitter fait remarquer que Bun avait des segfaults connus il y a encore quelques mois

Rien n’est gratuit avec les VCs

C’était déjà le sujet avec le changement de licence de Terraform. Le modèle de financement de l’Open-Source peut prendre différentes formes. Oven.sh ne va pas lever des fonds pour toujours et à un moment, il leur faudra : des clients et l’argent des clients.

Il ne serait pas étonnant de voir Bun passer de la licence MIT à la licence BSL. Est-ce que les contributeurs seront contrariés ?

J’ai pu interroger Hubert Sablonnière sur le sujet, et il fait remarquer que Node n’a pas besoin de business modèle.
« Maintenant, on a Deno et Bun, financés par des VCs vs Node.js un projet OSS gouverné par des bénévoles. Les deux premiers vont vite et cherchent un business model. Le dernier va plus lentement (quoi que) mais n’a pas besoin de BM. »

D’un autre côté, le pertinent @benjilegnard fait remarquer qu’il est courant de voir des projets open-sources couler après la disparition du fondateur. En choisissant Bun, vous faites confiance à Jared Summer et son équipe pour tenir le crunch dans la durée.

Mon opinion : c’est un jeu où Node.JS gagne toujours à la fin

Yarn devait détrôner npm, mais il est toujours là.
Deno est plus performant que Node et pourtant, c’est toujours Node qui tourne.

C’est l’histoire de l’écosystème JavaScript de voir des challengers arriver et remettre en question ses paradigmes.

Et quand le challenger se voit adopté largement, Node js intègre le changement. Et les moutons qui voulaient quitter le troupeau, reste à la bergerie. La gouvernance de l’OpenJS Fondation c’est la tortue et Bun.sh c’est le lièvre.
Depuis que Bun est en embuscade, les contributeurs de Node.js ont monté une Performance Team. Et cherchent déjà à rattraper le retard.

Ce qui est nouveau, et excitant, c’est de voir de larges investissements dans un outil JavaScript, sans monétisation à court terme.
Dépenser 7M$ pour faire progresser Node.js plus vite, c’est audacieux 🌚

Ressources – Ce que j’ai lu pour écrire cet article :

Damien Cavaillès

Auteur Damien Cavaillès

Plus d'articles par Damien Cavaillès

Laisser un commentaire