Mon expérience sur Bun

Bun a récemment célébré sa grande première avec la version 1.0, une occasion qui suscite à la fois l'excitation et le mécontentement en moi. Bien que j'admire la vision ambitieuse de Jarred Sumner pour Bun, je ne peux m'empêcher de ressentir une pointe de frustration à propos de sa compatibilité déclarée avec Node.js. D'après mon expérience pratique, Bun ne remplace pas sans heurts Node.js ; en fait, il en diffère considérablement sur certains aspects sous-jacents. Cela a entraîné une série de problèmes aléatoires sur mes repos de test, nécessitant des corrections pour pallier les particularités de Bun lorsque les utilisateurs l'expérimentent. À mon avis, il aurait été judicieux pour Bun d'attendre d'atteindre une meilleure compatibilité avec l'écosystème existant avant de s'autoproclamer 1.0.

Pourquoi Bun Surpasse-t-il Node.js ? Plusieurs facteurs contribuent à la performance supérieure de Bun :

Node.js fonctionne avec des ressources limitées et repose sur une petite équipe pour gérer npm. La plupart des investissements sont axés sur l'ajout de nouvelles fonctionnalités ou le renforcement de la sécurité, plutôt que sur l'optimisation de la vitesse. Améliorer la vitesse ne se traduit pas directement par une augmentation des revenus mais c'est un moyen efficace d'améliorer son SEO ou son scoring sur vos AdWords. De plus, les fournisseurs de services cloud, les acteurs majeurs de l'industrie actuelle, n'ont aucune incitation à améliorer les performances, car cela pourrait potentiellement réduire leurs gains. En revanche, Bun a délibérément mis de côté les préoccupations concernant la compatibilité ascendante avec une part importante de l'écosystème npm. Leur objectif était résolument centré sur la vitesse. En revanche, les processus de Node.js sont conçus en tenant compte de la préservation de l'écosystème, c'est finalement un avantage mais aussi un désavantage.

Je suis un défenseur des normes ouvertes et de la gouvernance ouverte, toutes deux reconnues pour enrichir les runtimes et l'infrastructure (il suffit de se rappeler du fiasco de Terraform pour le comprendre). Adopter une gouvernance ouverte implique un processus décisionnel plus inclusif où chaque voix est entendue, mais cela nécessite également plus de temps pour parvenir à des décisions.

Limitations Actuelles de Bun : Absence de prise en charge de Pino et Fastify Au moment où j'écris ces lignes, Bun ne propose malheureusement pas de prise en charge pour deux acteurs importants : Fastify et Pino. Les deux modules ont une influence considérable, la popularité de Pino rivalisant avec celle de Next.js. Heureusement, l'équipe de Bun explore activement des solutions pour intégrer les API et les fonctionnalités manquantes, et je pense qu'ils combleront ce fossé dans les mois à venir. Étant donné les appels en faveur d'une prise en charge en provenance de nombreuses sources, une variante du message suivant a trouvé sa place parmi mes réponses enregistrées sur GitHub :

En substance, Bun ne reproduit pas fidèlement toutes les API de Node.js. Il ne remplace pas Node.js sans accroc, malgré leurs affirmations. Je vous encourage à vous référer au serveur Discord de Bun ou à la liste des problèmes pour les questions de cette nature.

Si l'un de mes dépôts présente des performances insuffisantes avec Bun, n'hésitez pas à ouvrir un incident dans le dépôt Bun. Cette approche s'aligne sur la directive de Jarred à la communauté.

Le Dilemme de l'Installation Rapide de Bun : La remarquable vitesse d'installation de Bun est l'une de ses caractéristiques les plus impressionnantes. Cependant, cela s'accompagne d'un compromis significatif en termes d'expérience de développement. npm, pnpm et yarn inspectent habituellement le registre pour vérifier la disponibilité de nouvelles versions et les téléchargent par défaut. En revanche, Bun penche initialement en faveur de l'utilisation d'une version locale. En fait, l'option pnpm --prefer-offline offre une expérience similaire à bun install, avec des résultats de performance comparables - sur ma configuration, la comparaison est de 750 ms contre 150 ms.

Bien que l'écart entre les deux chiffres soit notable, ils restent dans la même fourchette. Il convient de se demander comment les utilisateurs finaux percevront cette disparité de comportement. Opteriez-vous pour le dernier cri, ou resteriez-vous fidèle à la version installée localement, sachant que cela pourrait vous priver de correctifs de bogues ou de mises à jour de sécurité ?

Je tiens également à saluer la mise en œuvre astucieuse de 'copy-on-write' sur Mac OS X, qui se traduit par des performances quasiment instantanées avec un cache. Cette réalisation doit beaucoup à l'utilisation de clonefile, un mécanisme qui indique au système d'exploitation de dupliquer un fichier uniquement lors de sa première modification, une innovation qui permet de gagner de précieuses secondes. J'espère que les autres gestionnaires de paquets JavaScript emprunteront cette voie.

Quel Avenir pour Node.js ? Pendant quelques années, Node.js a connu une période où les améliorations des performances d'exécution ont été reléguées au second plan. Cependant, cette histoire a connu un changement transformateur l'année dernière, initié par Yagiz Nizipli, qui a pris la tête de l'équipe Performance, une initiative qui s'est depuis muée en un axe stratégique. Cette transition a engendré une série d'améliorations notables des performances, comme le détaille Rafael Gonzaga dans le rapport sur l'état des performances de Node.js en 2023. Node.js gagne en rapidité à chaque nouvelle version, sans introduire de changements majeurs perturbateurs, sans oublier la récente prise en charge des fichiers env dans la version 20 :-)

En définitive, si vous travaillez sur un projet simple, TS natif qui ne nécessite pas de centaines de packages npm, optez pour BUN et vous aurez un vrai gain de performance. Imaginons ici un petit serveur Bun/Mongo/Mongoose pour faire un petit site web ( avec Bun-React vous pourrez dev/build votre Front encore plus vite qu'avec Node.)

En revanche si votre projet nécessite de nombreuses lib et une stabilité importante, faite une MAJ de NodeJS et continuer à l'utiliser, c'est plus safe ( pour le moment).

#Nodejs #BUN #Performance #OpenSource