Une introduction au runtime Bun JavaScript —

Un concurrent d’exécution JavaScript est entré dans la bataille entre Node.js et Deno. Dans cet article, nous jetons un premier coup d’œil à Bun et aux raisons pour lesquelles il peut vous éloigner de votre favori actuel.

Ryan Dahl a publié Node.js en 2009. Ce n’était pas le premier environnement d’exécution JavaScript côté serveurmais Node.js a rapidement pris de l’ampleur. La version 20 est arrivée en 2023et Node.js possède le plus grand écosystème de développement, avec 3,2 millions de modules, ce qui représente près de 500 milliards de téléchargements par semaine (selon npmjs.com).

En 2020, Ryan Dahl a sorti Pas – un remixer de « noDe » – pour moderniser le développement JavaScript et résoudre les problèmes hérités avec la sécurité Node.js, la compatibilité des API, outillage, et la gestion des modules. La réception a été positive, bien que Deno n’ait pas encore défié la domination de Node.

En 2022, Jarred Sumner a publié Bun suite à ses frustrations face à la vitesse de Node.js lors du développement d’un projet Next.js. L’origine du nom n’est pas claire, et le logo n’aide pas ! Cela pourrait être lié à la nourriture, aux lapins moelleux, au « paquet », ou peut-être est-ce un nom court et mémorable et le chignon.sh domaine était disponible.

L’intention : Bun deviendra un remplaçant de Node.js, Deno, JavaScript sans serveur et des outils tels que Webpack, Babel et Yarn. Plutôt que de courir npm start pour lancer votre script Node, vous pouvez exécuter bun start et profitez de la vitesse de Bun.

Avantages du petit pain savoureux

Node.js et Deno utilisent Chrome Moteur JavaScript V8. Bun opte pour le Moteur JavaScriptCore qui alimente les navigateurs WebKit tels que Safari. Bun lui-même est écrit en Zig — un langage de programmation de bas niveau avec gestion manuelle de la mémoire et threading natif pour gérer la concurrence. Le résultat est un environnement d’exécution léger avec une empreinte mémoire réduite, des temps de démarrage plus rapides et des performances qui peuvent être quatre fois plus rapides que Node.js et Deno dans certaines conditions (d’analyse comparative).

Comme Deno, Bun prend en charge nativement JavaScript et Manuscrit sans nécessiter de transpiler ou de configuration tiers. Il prend également en charge Fichiers .jsx et .tsx pour convertir le balisage de type HTML en JavaScript natif. Support expérimental pour la course à pied Fichiers .wasm compilés par WebAssembly est disponible.

En interne, Bun utilise Modules SEprend en charge le niveau supérieur awaittraduit CommonJS et implémente Node’s node_modules algorithme de résolution. Bun met en cache les modules dans ~/.bun/install/cache/ et utilise des liens physiques vers copie les intégrer dans un projet node_modules annuaire. Tous les projets de votre système référenceront donc une seule instance de la même bibliothèque, ce qui réduit les besoins en espace disque et améliore les performances d’installation. (Notez que les installations macOS conservent les versions locales pour la vitesse.)

Bun prend en charge les nœuds package.json, npm commandes équivalentes, et bunx – un npx-like option pour installer et exécuter automatiquement les packages en une seule commande. Par exemple:

bunx cowsay "Hello, world!"

bun init échafaude des projets vides de la même manière que npm initmais vous pouvez aussi modéliser un nouveau projet avec bun create <template> <destination>où <template> est un paquet officiel, un référentiel Github ou un package local. Par exemple, pour créer un nouveau projet Next.js :

bun create next ./myapp

Le chignon comprend un bundler pour importer toutes les dépendances dans un seul fichier et peut cibler Bun, Node.js et JavaScript côté client. Cela réduit la nécessité d’utiliser des outils tels que esbuild ou Cumul:

bun build ./index.ts —outdir ./out

La plupart des options d’interface de ligne de commande sont disponibles via une API JavaScript, il est donc possible de créer des scripts de construction sophistiqués sans exécuteur de tâches dédié. Voici une version identique à la commande ci-dessus :

await Bun.build({
  entrypoints: ['./index.ts'],
  outdir: './out',
})

Bun a une norme testeur comme Pas et Node.js 20. En cours bun test exécute des scripts nommés comme ceci :

*.test.{js|jsx|ts|tsx}
*_test.{js|jsx|ts|tsx}
*.spec.{js|jsx|ts|tsx}
*_spec.{js|jsx|ts|tsx}

Il n’y a pas besoin de Nodemon-comme des outils, puisque bun a un —watch drapeau qui redémarre les scripts ou les tests lorsque vous modifiez un fichier de dépendance. Les redémarrages sont si rapides qu’il devient possible de recharger en direct à chaque frappe. (Que ce soit pratique et non une distraction, c’est une autre affaire !)

Le rechargement en direct n’est pas joli! (Attention : contenu clignotant !) Afficher le GIF animé original.

Un similaire —hot mode est disponible, où Bun surveille les changements et doux recharge les modules. Tous les fichiers sont réévalués, mais l’état global persiste.

Variables d’environnement contenues dans le projet .env les fichiers sont automatiquement chargés et analysés, ce qui les rend disponibles dans les applications Bun, il n’est donc pas nécessaire d’utiliser des packages tels que dotenv.

Ainsi que le sien Bonnes API pour la mise en réseau, l’accès aux fichiers, les processus enfants, etc., Bun prend en charge :

• API Web tel que fetch, URL, blob, WebSocket, JSON, setTimeoutet événements.

• API de compatibilité Node.js tel que console, assert, dns, http, path, streamet utilainsi que des globals, y compris __dirnameet __filename. Bun affirme que 90 % des API les plus utilisées sont entièrement implémentées, bien que vous deviez revérifier celles spécifiques à votre projet.

Enfin, Bun a un client natif SQLite3 — chignon: sqlite — ce qui pourrait réduire le nombre de dépendances nécessaires dans certains projets.

Petit pain pas assez cuit

Bun est en développement actif, donc les fonctionnalités suivantes n’apparaissent pas encore :

• un modèle d’autorisation de type Deno pour restreindre l’accès aux fichiers, au réseau, aux processus enfants, aux variables d’environnement, aux informations sur le système d’exploitation, etc. L’ajout ultérieur de droits d’autorisation peut entraîner des complications (comme on le voit dans Node.js 20), donc je soupçonne que les options arriveront avant la version 1.0.

• Des outils tels qu’une boucle de lecture-évaluation-impression (REPL), un inspecteur de dépendances, un linter, un débogueur, un formateur de code, un générateur de documentation et un générateur de script autonome sont manquants mais devraient apparaître au fil du temps.

Installation du chignon

Bun n’a pas atteint la version 1.0, mais il est disponible sous la forme d’un binaire unique que vous pouvez installer sur Linux, macOS et Windows WSL avec :

curl -fsSL https://bun.sh/install | bash

Alternativement, vous pouvez l’installer avec le gestionnaire de packages de Node :

npm install -g bun

Une version native de Windows arrive, bien que le Sous-système Windows pour Linux est souvent l’option la plus simple et la plus performante. Vous pouvez également utiliser Docker pour exécuter Bun dans un conteneur :

docker run —rm —init —ulimit memlock=-1:-1 oven/bun

Une fois installé, vous pouvez mettre à niveau le moteur avec :

bun upgrade

Pour désinstaller, supprimez le ~/.bun répertoire binaire et cache :

rm -rf ~/.bun

Ensuite, mettez à jour votre fichier de configuration du shell (.bashrc, .zshrcou similaire) pour supprimer ~/.bun/bin références de la $PATH variable.

Utiliser le chignon

Bun est fiable si vous l’utilisez dès le début de votre projet. La vitesse est meilleure que Node.js, bien qu’il soit peu probable que vous voyiez une amélioration significative des performances à moins que votre application n’effectue des tâches intensives spécifiques telles que le traitement SQLite lourd ou la messagerie WebSocket.

La compatibilité Node.js est bonne pour les projets plus petits et plus simples, et j’ai réussi à lancer des scripts en utilisant bun start sans apporter de modifications. Des applications plus complexes ont échoué, avec des messages d’erreur obscurs générés profondément dans le node_modules hiérarchie.

Bun contre Deno contre Node.js

Deno a résolu de nombreux inconvénients de Node, mais les développeurs ne se sont pas nécessairement sentis obligés de changer :

1. Deno ne prenait pas en charge les modules tiers de Node.
2. La migration de Node.js vers Deno a nécessité l’apprentissage de nouvelles techniques.
3. Alors que Deno offrait une meilleure expérience de développement, Node.js était assez bon.

Deno a maintenant ajouté Options de compatibilité Node.js. C’était le moyen le plus simple de faire passer les développeurs à Deno, mais entre-temps, Node.js a adopté certaines des fonctionnalités de Deno, notamment les modules ES, un testeur natif et un —watch mode.

Bun a adopté une approche différente, visant à être un moteur rapide et compatible Node avec les avancées de Deno. Les signes sont prometteurs, mais ce n’est pas encore là :

• Les performances sont excellentes, mais peu de développeurs se plaignent de la vitesse de Node.js.

• La compatibilité est bonne, mais ce sera un défi de prendre en charge tous les modules Node.js dans un moteur JavaScript différent. JavaScriptCore peut-il suivre les développements V8 avec beaucoup moins d’investissement ?

• Bun a le potentiel de remplacer votre suite d’outils, mais il n’offre pas encore la gamme complète trouvée à Deno.

Résumé : Devriez-vous passer à Bun ?

Bun est un environnement d’exécution JavaScript accompli, mais Node.js reste le champion des projets critiques ou des applications héritées. Vous devriez essayer d’exécuter votre application en utilisant bun startmais plus votre base de code est grande, moins il y a de chances qu’il s’exécute sans modification.

Deno est probablement une meilleure option que Bun pour les nouveaux projets, étant donné qu’il est plus mature et complet.

Bun est génial, mais il est nouveau, en cours de développement actif, et n’a pas encore atteint le jalon de la version 1.0. L’exécution est stable, mais peu parieraient sur son avenir à long terme à ce stade. Cela dit, Bun a des idées intéressantes que j’espère que les équipes Node.js et Deno envisageront d’adopter (API CLI et chargement automatique .env s’il te plaît!)

En passant, j’aime le nom de Bun, mais il peut être difficile de rechercher des ressources. ChatGPT fait la déclaration audacieuse qu’il n’y a pas d’exécution JavaScript largement connue appelée ‘Bun’. Autant que je sache, il n’y a pas une telle technologie dans l’écosystème JavaScript. Cela peut être dû au fait que les données post-2021 sont limitées, bien que certaines questions renvoient une réponse Bun et des excuses pour l’erreur !

Je soupçonne que nous nous dirigeons vers une ère de JavaScript côté serveur isomorphe, où les développeurs de modules tentent d’écrire du code compatible avec tous les runtimes : Node.js, Deno, Bun, sans serveur, bord, intégré, etc. Nous pourrions éventuellement atteindre un point où les runtimes JavaScript sont pour la plupart interchangeables de la même manière que les navigateurs le sont aujourd’hui.