Conçu comme un remplacement direct pour l’exécution d’applications JavaScript et Typescript, Bun, un nouveau moteur d’exécution JavaScript construit avec un moteur JavaScriptCore, a été conçu pour être un outil tout-en-un pour regrouper, transpiler et exécuter du code à la vitesse de l’éclair.
Construit par Jarred Sumner, un ancien ingénieur frontend chez Stripe, Bun vise à “exécuter la plupart du JavaScript mondial en dehors des navigateurs, apportant des améliorations de performances et de complexité à votre future infrastructure, ainsi que la productivité des développeurs grâce à des outils meilleurs et plus simples”, a déclaré Sumner. dans une interview YouTube, menée par le PDG de Ping Labs, Theo Browne.
Bun traite environ trois fois plus de requêtes HTTP par seconde que Node.js lors du rendu React côté serveur. WebSocket, ReadableStream et fetch sont intégrés. Bun est également un transpileur, donc TypeScript et JSX fonctionnent immédiatement. Étant donné que Bun implémente l’algorithme de résolution de module de Node.js, les packages npm fonctionnent également.
“J’ai été frustré par la lenteur de tout en JavaScript et je pense plutôt, je sais, que JavaScript peut devenir beaucoup plus rapide”, a déclaré Sumner.
Battre un cycle d’itération lent
C’est la vitesse qui a d’abord suscité le besoin de quelque chose de nouveau qui a conduit à la création de Bun. À cette époque, Sumner développait un jeu dans Next.js mais était frustré par la vitesse du cycle d’itération. La première solution consistait à utiliser le constructeur esbuild avec Next.js mais cela n’a pas apporté le résultat qu’il recherchait même après avoir fait fonctionner les technologies avec les plugins. L’idée suivante de Sumner était de construire un bundler et un transpiler mais à la fin, il a construit un runtime qui inclut un bundler et un transpiler.
Dans l’interview, Sumner a expliqué qu’il savait que JavaScript pouvait être plus rapide, en raison d’une expérience qu’il avait eue en écrivant du code natif en Objective-C. La vitesse du NSLog d’Apple, qui est l’équivalent Objective-C de console.log en JavaScript, lui a montré à quelle vitesse il était possible d’écrire sur le terminal. C’était une fenêtre d’aperçu sur un flux de travail possible qui ralentissait les applications JavaScript.
Après avoir jeté un coup d’œil à un certain nombre de langues pour construire Bun, Sumner a finalement atterri sur le Zig relativement peu connu. L’approche de métaprogrammation “comptime” de Zig a aidé à conclure l’affaire. Comptime est une métaprogrammation basée sur l’exécution de code au moment de la compilation et l’évaluation paresseuse.
Dans Zig, le programmeur peut étiqueter une variable au moment de la compilation garantissant au compilateur que chaque chargement et stockage de la variable est effectué au moment de la compilation. Essentiellement, comptime peut exécuter du code arbitraire au moment de la compilation. “Je viens de l’essayer et j’ai réalisé que comptime serait un outil incroyablement puissant pour écrire du code rapide”, a expliqué Sumner.
Avant Bun, Sumner n’a jamais écrit une ligne de code en Zig. Il attribue à l’utilité du serveur de discorde l’une des raisons pour lesquelles il a pu écrire Bun complètement en Zig.
Comptime est utilisé dans l’analyseur lexical, appelé “lexer”, l’une des parties les plus lentes de l’analyse de Bun. Son travail consiste à parcourir tout le texte pour déterminer si le jeton actuel est un identifiant valide ou un mot-clé. En raison de comptime, Bun utilise un jeu de bits généré au moment de la compilation. Ce processus donne une amélioration des performances de 2% à Bun.
Pour les défis techniques, qui étaient nombreux, Sumner déclare spécifiquement : “L’une des choses que travailler sur Bun m’a vraiment beaucoup appris, c’est comment lire les messages d’erreur.” Il fait référence à la formulation des messages d’erreur de Zig qui ressemble davantage à celle des compilateurs. Par exemple, le mot jeton, que l’on voit surtout dans la lexique ou l’analyse syntaxique, était en fait très courant dans les messages d’erreur qu’il recevait.
Sumner prévoit d’avoir au moins deux modèles d’autorisation à l’avenir, l’un étant l’élimination du code mort binaire. Ce modèle activera et désactivera les fonctionnalités, donc si une fonctionnalité n’est pas utilisée dans une application, Bun n’aura pas le code. Étant donné qu’il y a un impact sur les performances à chaque fois qu’une autorisation est atteinte, il y aura moins d’impacts sur les performances en fonction du nombre de fonctionnalités désactivées.
À l’heure actuelle, Sumner recommande Railway ou voler.io comme les meilleures options de déploiement. Il y aura une option intégrée mais il est trop tôt pour des détails supplémentaires. Les API de test Express, Angular et Jest sont des technologies spécifiques pour lesquelles Sumner travaille sur l’ajout d’un support approprié, mais sur les frameworks JavaScript en général, il dit: «Je ne dirais pas que je suis en concurrence avec n’importe quel framework parce que je veux que tous ces frameworks utilisent Chignon.”
Secouer les bogues
Et le dernier mais non le moindre, les tests. Bun est nouveau et il a des bugs. Sumner en est conscient et attribue au manque de tests généralisés l’une des raisons pour lesquelles il est si bogué. À propos de cela, dit-il, “bun n’a pas suffisamment de couverture de test et c’est pourquoi il est si bogué.” Bun a un testeur JavaScript et la commande cli est bun wiptest.
Les développeurs et Sumner sont très enthousiasmés par Bun et bien qu’il soit encore nouveau, il y a de très grands espoirs pour lui. Sumner a déclaré: “Je suis venu du point de vue de ‘il doit fonctionner autant que possible avec l’écosystème existant parce que les gens ne devraient pas avoir à réécrire leur code’ mais peut-être que je devrais commencer à réfléchir davantage à ce qui se passerait si nous faisions / quelles nouvelles choses sont possibles grâce au bun des API. »