L'arrivée de nouveaux frameworks et de nouvelles bibliothèques en permanence est une caractéristique de JavaScript. En juillet 2022, l'écosystème JavaScript a accueilli un nouveau membre : Bun.js. Il est défini comme "un moteur d'exécution JavaScript rapide tout-en-un". Bun est le troisième outil du troisième de ce type après Node.js et Deno.js, et a été créé par Jarred Sumner à l'aide du langage de programmation Zig. Le langage est encore à ses débuts dans sa version 0.9.1, mais Sumner justifie le choix Zig par les avantages que présente son contrôle manuel de la mémoire de bas niveau et l'absence d'un "flux de contrôle caché".
Bun met l'accent sur la simplicité et la rapidité
Les développeurs auraient ainsi plus de facilité à écrire des logiciels rapides. Bun est un projet open source et est publié sous licence MIT. Il est basé sur le moteur JavaScriptCore de WebKit, qui est plus rapide que les alternatives courantes telles que V8, et comme Deno, Bun prend nativement en charge TypeScript. Mais contrairement à Deno, Bun est destiné à remplacer Node, Webpack, Babel, Yarn et PostCSS, le tout dans un seul et même paquet. Il est important de rappeler que Deno n'a pas été conçu comme un remplacement de Node. Son créateur, Ryan Dahl, l'a conçu pour améliorer la productivité. Alors, comment Bun se compare-t-il à Deno et Node ?
Bun veut surtout convaincre les développeurs avec un paquet complet qui comprend entre autres, un transpileur JSX/TypeScript, un client npm, un empaqueteur ainsi que des clients pour SQLite, HTTP et Websocket. Bien que Bun soit inspiré par les concurrents Node et Deno, Sumner a déclaré lors de sa présentation qu'il tente aussi clairement d'améliorer l'expérience de développement et la productivité en fournissant un ensemble d'outils. Bun supporte la résolution de modules Node.js, aussi bien avec des modules CommonJS qu'avec des modules EcmaScript (ESM). Cela devrait permettre d'utiliser une grande partie des paquets npm.
Sumner a expliqué que Bun est né de sa frustration face à la vitesse, ou au manque de vitesse, d'un langage : « j'ai été tellement frustré par la lenteur de tout ce qui est en JavaScript. Je sais que JavaScript peut être beaucoup plus rapide ». En tant qu'ancien développeur front-end chez Stripe, il a déclaré qu'il sait combien un cycle d'itération rapide est essentiel à la productivité. Ainsi, la vitesse de Bun ne se limiterait pas simplement à servir les requêtes plus rapidement que les autres moteurs d'exécution. Cela signifierait également qu'il est plus rapide pour installer des paquets, exécuter des tests, regrouper et transpiler.
La page d'accueil de Bun indique des performances 3 et 4 fois supérieures à celles de Deno et Node. Ce sont des des chiffres impressionnants, mais Tomas Fernandez, développeur et ingénieur en informatique dématérialisée, a réalisé quelques tests pour voir comment Bun se comporte réellement, mais aussi pour déterminer à quel point il est rapide. Il a récemment partagé les résultats de ces tests, dont en voici quelques points forts :
Gestion des paquets avec npm et Bun
Dans ce premier test, Fernandez a comparé les performances de Bun à celles de npm pour la création de nouveaux projets. Les résultats ont révélé que npm prend 49 secondes pour créer une application React vide. Par contre, il faut moins d'une seconde à Bun pour terminer la configuration. « C'est une sacrée amélioration », a écrit Fernandez. Mais est-ce une comparaison valable ? Après une inspection plus poussée, il a constaté que :
- npm a installé 1 392 paquets et la taille de node_modules est de 250 Mo ;
- Bun n'a installé que 8 paquets, pour une taille totale de 72 Mo.
D'après Fernandez, l'on compare ici des pommes et des oranges ici, car le modèle React de départ de Bun est plus petit. Toutefois, il a ajouté que le modèle tout à fait utilisable pour le développement. « Je peux lancer bun dev pour commencer à bidouiller immédiatement », a écrit l'ingénieur dans un billet de blogue. De plus, Bun se recharge également automatiquement à chaque changement. Il a néanmoins précisé que la commande React starter de Bun ne peut pas créer un build de production. Pour cela, il faut ajouter des react-scripts avec : bun add react-scripts -d.
La nouvelle dépendance installe 1 133 paquets supplémentaires, ce qui porte la taille totale de node_modules à 298 Mo. Fernandez estime que cela offre à présent de meilleures conditions pour la comparaison. Après avoir créé la nouvelle application 10 fois avec chaque outil, il a obtenu des chiffres à comparer. Dans ce test, Fernandez a observé que Bun est au moins 6 fois plus rapide que npm. De temps en temps, cependant, Bun se bloquerait (un problème connu). De même, npm ralentirait considérablement de temps en temps (Fernandez a indiqué qu'il n'a pas pu déterminer la cause de ce problème).
Ajout et suppression de paquets avec Bun et npm
Le test suivant concerne le temps que prennent npm et Bun pour ajouter et supprimer des paquets. Fernandez a utilisé une application React créée par npm comme terrain d'essai. Après avoir supprimé et réintroduit Webpack 10 fois avec chaque outil, il a obtenu les résultats suivants :
- Bun est 20 fois plus rapide que npm ;
- Bun utilise un fichier de verrouillage binaire au lieu de package-lock.json. Mais il peut imprimer un fichier de verrouillage JSON compatible avec Yarn avec bun install -y ;
- Bun n'installe pas les dépendances des pairs par défaut comme npm. Vous pouvez donc vous retrouver avec un ensemble de paquets différent de celui attendu dans votre dossier node_modules ;
- le seul problème est que le gestionnaire de paquets de Bun n'est pas compatible à 100 % avec npm.
Bun en tant qu'exécuteur de tâches
Selon Fernandez, le composant d'exécution de Bun n'a pas implémenté suffisamment d'API Node pour faire des choses complexes comme la construction de projets React ou l'exécution de tests de bout en bout. Pourtant, il estime qu'il y a un domaine dans lequel Bun peut aider dès maintenant : il pourrait être utiliser comme un remplacement de npm run. « Le problème avec npm est qu'il prend environ 150 à 200 ms pour démarrer. Cela peut sembler anodin, mais lorsque vous exécutez fréquemment des scripts, vous pouvez sentir ce quart de seconde grignoter peu à peu votre productivité », a-t-il déclaré.
« Bun n'a pas ce problème de démarrage, donc bun run test devrait être au moins quelques millisecondes plus rapide que npm run test », a-t-il ajouté. Pour le confirmer, il a exécuté le même ensemble de scripts 50 fois et a fait la moyenne des résultats. La figure ci-dessous présente les résultats de ce test. Les performances de Bun semblent légèrement supérieures à celles de npm.
Copie de gros fichiers
Dans ce test, il a comparé la façon dont chaque moteur d'exécution gère la copie de fichiers volumineux, un domaine dans lequel beaucoup d'efforts d'optimisation ont été déployés. Fernandez a copié le même fichier de 1 Go généré aléatoirement avec Bun, Deno, Node et cp pour le test. Après 20 exécutions avec chaque outil, il a déclaré qu'il semble que Bun et Deno soient aussi performants l'un que l'autre, et qu'ils l'emportent sur cp de près de 50 %. Quant à Node, il prend plus de 3 fois plus de temps pour effectuer la même tâche.
En outre, Bun inclut un serveur HTTP fonctionnel, ce qui selon Fernandez, présente une opportunité de comparaison avec Node et Deno. Pour le test, il a utilisé les scripts d'exemple de Bun. Les résultats ont révélé que Deno a obtenu des résultats supérieurs de 19 % à ceux de Node, mais Bun a écrasé la concurrence en étant deux fois plus rapide.
Conclusion
« Non seulement Bun est rapide, mais il donne l'impression d'être rapide. On a l'impression de pouvoir faire n'importe quoi en moins d'une seconde. Bun remplacera-t-il Node ? Il est trop tôt pour le dire. Lorsque Deno est sorti, il n'a certainement pas tué Node - mais je ne pense pas que c'était l'intention, car il n'a jamais été conçu comme un remplacement de Node. Mais Bun vise la compatibilité, il a donc plus de chances. Et, comme nous l'avons vu, même à ce stade précoce, il peut être un outil très puissant », a déclaré Fernandez. D'autres commentaires estiment qu'avec l'arrivée de Bun, beaucoup de choses pourraient s'améliorer avec JavaScript.
Il est probablement temps pour JavaScript d'être mieux adopté dans les domaines où les performances sont critiques comme l'IA/ML, le développement de jeux, etc. Jusqu'à présent, la plupart des observateurs s'accordent à dire que Bun mérite l'attention rien que pour ses performances, et que la compatibilité avec les modules npm est un énorme avantage. Cela dit, Zig n'a pas la sécurité mémoire intégrée de Rust, utilisée par Deno. Bun n'en est qu'à ses débuts et la question de savoir si le projet atteindra l'élan dont il a besoin pour prospérer reste ouverte, mais il est certain que c'est un projet à suivre et qu'il aura une certaine influence.
Par ailleurs, Bun pourrait avoir des problèmes d'adoptabilité. Alors que Deno et Node.js peuvent fonctionner sur plusieurs plateformes, Bun est lié à des variantes Unix hautes performances : macOS (x86 et Arm), Linux ou Windows Subsystem for Linux (WSL), ce qui limite son utilisation. Les développeurs Windows devront utiliser WSL, qui s'adresse principalement aux développeurs Linux opérant dans un environnement Windows et qui présente des limitations, comme le fait de n'être disponible que pour Windows 10.
Source : Billet de blogue
Et vous ?
Quel est votre avis sur le sujet ?
Que pensez-vous du moteur d'exécution JavaScript Bun ?
Pensez-vous que ces caractéristiques lui permettront de faire de l'ombre à Node ou le surpasser ?
Voir aussi
Bun, un nouveau moteur d'exécution JavaScript, livré avec un client SQLite3 rapide, il apporte un peu de concurrence pour Node et Deno
Pendant que Deno, le runtime de JS et TS, gagne en maturité, certaines entreprises tentent de l'utiliser en production, mais d'autres repartent non satisfaites à la suite des tests effectués
Les conteneurs JavaScript surpasseront-ils les conteneurs Linux ? Le créateur de Node.js pense que les conteneurs JavaScript pourraient simplifier l'écriture des services Web
Fresh, un framework web de nouvelle génération, conçu pour la vitesse, la fiabilité et la simplicité, il apporte un peu de concurrence pour Next.js