Focus sur Bun : le glas de Node.js a-t-il sonné ?

Rarement un nouvel outil aura suscité autant d’attentes, et d’intérêt. Tout juste né, dans sa v1.0.0, il y a de cela quelques semaines (8 septembre 2023), le dépôt Github de Bun compte déjà plus de 63 000 stars. Il faut bien reconnaître que la promesse est de taille, et les enjeux d’envergure. 

Au rang des fonctionnalités les plus notables de ce qui est défini comme étant un runtime, un gestionnaire de paquets, ou encore une boîte à outils JavaScript tout-en-un, on retrouve notamment : 

• Des performances décuplées (quatre fois plus rapides que Node.js sur une simple commande run).
• Le support natif de Typescript et JSX.
• Une expérience développeur simplifiée.
• La gestion native de nombreuses dépendances (adieu dotenv, tsc, webpack, nodemon, parcel, rollup, babel, npm, yarn, et autres…?).
• La compatibilité avec la très large majorité des packages npm existants.

Source : https://bun.sh

A la lecture de tels avantages, et avec l’ambition clairement affichée de s’y substituer, il est donc légitime de se poser la question : Bun dispose-t-il, à termes, de la capacité à venir remplacer NodeJs ?

Bun & furious

S’il est bien un argument mis en avant, via la communication officielle de l’équipe en charge du développement de Bun, il s’agit de celui de la performance. Sur la documentation officielle de l’outil, on le retrouve partout : Bun serait le runtime le plus rapide de l’écosystème Javascript, le gestionnaire de paquets le plus rapide, ou encore le lanceur de tests le plus rapide. 

Loin d’être le fruit du hasard, il s’agirait plutôt là de la résultante de choix techniques, le premier étant ni plus ni moins que le langage de programmation de l’outil.

En effet, Bun est codé en Zig. Si la popularité du langage n’égale pas celle d’un Python ou d’un Java, il s’agit d’un jeune langage de bas niveau proche du C, reconnu, justement, pour ses performances. 

Second choix, celui de s’être basé sur JavaScriptCore, moteur développé par Apple, et utilisé par Safari, plutôt que sur le V8 de Google. Le premier étant considéré, actuellement, comme le plus rapide.

Ainsi, les premiers benchmarks font effectivement état d’un écart de performances, à la faveur de Bun. Même s’ils se montrent toutefois plus nuancés, avec des résultats qui diffèrent parfois, en fonction de la nature du programme exécuté, il faut bien reconnaître qu’en la matière, les résultats sont bel et bien là.

Une expérience développeur riche

Mais là où l’outil se démarque véritablement, c’est par l’incroyable expérience développeur qu’il propose. Nativement, il propose un très large éventail de fonctionnalités. 

S’il fallait, pour débuter, orienter son choix vers l’une d’entre elles, on retiendrait très probablement le support natif de Typescript, tant le langage**** continue de prendre de l’ampleur. Sans qu’il y ait besoin d’effectuer quelque action que ce soit, une simple commande « bun run … » permet d’exécuter un fichier Typescript. Cela est rendu possible par l’intégration d’un système de transpilation native, qui transpile à la volée les fichiers, avant de les exécuter. Cette fonctionnalité est également valable pour les fichiers JSX et TSX.

Dans cette volonté de fournir un outil complet, capable sans dépendance de gérer des projets TypeScript, Bun intègre également son propre bundler. Une fonctionnalité essentielle, notamment pour que le code puisse être utilisé par les navigateurs. Et là encore, la performance est au cœur du sujet.

Source : https://bun.sh

Bun, c’est également la gestion native des variables d’environnement. Dotenv peut se faire du souci, car dès lors que Bun rencontre une référence à une variable d’environnement, il va automatiquement chercher sa définition dans le fichier .env correspondant, en fonction de la valeur du NODE_ENV.

Existe également la possibilité de définir une variable comme n’étant pas optionnelle, et de profiter de l’autocomplétion, dans le cadre d’un projet TS, via l’interface merging.

L’une des fonctionnalités majeures de Bun, qui s’inscrit dans cette recherche perpétuelle de la performance, c’est indubitablement l’intégration de son propre gestionnaire de paquets. La commande « bun install … » permet d’installer à peu près n’importe quel paquet… npm. Car l’excellente nouvelle, c’est que l’outil est compatible avec l’immense majorité des paquets npm. Et, en la matière, Bun se montre si rapide que l’on en vient parfois à se demander si le package a correctement été installé.

On retrouve évidemment les possibilités d’installer une version spécifique, d’ajouter un paquet en tant que devDependancy ou optionalDependency, de l’installer de manière globale, ou de le mettre à jour via un « bun update … ».

Il est intéressant de noter que le choix a été fait de l’utilisation d’un cache global (~/.bun/install/cache). Les paquets y sont enregistrés par nom, et numéro de version.

Ainsi, lorsqu’on cherche à installer un package dont le numéro de version correspond à une entrée du cache, c’est cette dernière qui va être retournée, plutôt que de récupérer le package via internet. Cette approche permet de sauver de l’espace disque (notamment dans le cas ou plusieurs projet utiliseraient une même association package@version), et d’accroître considérablement les performances.

Enfin, Bun s’installe également avec sa propre suite de tests. Et, comme à son habitude, l’équipe produit a fait le choix de la compatibilité avec les acteurs majeurs de l’écosystème actuel. Ce qui signifie donc que l’outil, qui se base sur son propre runtime, pour là encore obtenir d’impressionnantes performances, est notamment compatible avec Jest. On retrouve par ailleurs des fonctionnalités telles que watch mode, mocking, ou lifecycle hooks.

Quel modèle pour la pérennité ?

Au-delà des simples différences techniques, de performance, ou autres, Node.js et Bun se distinguent également par un autre biais : leur modèle. 

Le premier, faut-il le rappeler, est un runtime open-source, dont la force réside dans une communauté solide, et rompue à l’exercice. Node.js a vu, au fil du temps, se succéder les prétendants, le plus connu d’entre eux étant très certainement Deno, sans jamais qu’aucun ne parvienne à l’égaler. Node.js et sa communauté savent s’adapter. Preuve en est, s’il en fallait une : à l’aube de Bun naquit la Performance Team de Node.js. De là à imaginer, à termes, l’intégration par Node.js de certaines des idées novatrices de son jeune cousin, il n’y a qu’un pas.

De son côté, le modèle Bun est aux antipodes de celui de Node.js. L’outil est développé par une société privée, Oven, qui vit notamment grâce à une levée de fonds de 7 millions de dollars. Cela pose déjà une question : celle de la viabilité du produit, sur le long terme. Quid de celle-ci, sans système de monétisation ? De plus, il faut bien comprendre qu’un tel modèle implique une dépendance totale quant aux choix techniques de la société qui développe l’outil. Nous avons pu constater, qu’aujourd’hui, la majorité de ceux-ci étaient effectués dans l’optique de compatibilité avec les outils de l’écosystème existant. En sera-t-il toujours de même demain, dans les prochaines versions, une fois la phase de conquête de nouveaux utilisateurs révolue ? Personne, si ce n’est l’avenir, ne peut l’assurer.

Si nous devions conclure

Pour ces raisons est-il encore prématuré pour affirmer que Bun pourra s’imposer comme une alternative crédible à Node.js.

Sur le papier, les avancées techniques sont plus qu’alléchantes. Couplées à une expérience de développement unique, elles expliquent l’intérêt massif qui lui est porté et l’engouement que suscite l’outil. 

Cela ne saurait toutefois masquer l’incertitude que génère la nature même de son modèle, voire certains des choix techniques (quelle maintenance, dans le futur, pour un projet en Zig ?).

Migrer aujourd’hui un projet d’envergure sous Bun, c’est jouer à la roulette russe avec trois balles dans le barillet. Démarrer un projet Bun, sans trop d’enjeu, c’est rester alerte, et prendre du plaisir.