Bun vient de rendre les API d'images obsolètes

Le traitement d'images côté serveur est depuis longtemps une source de frustration pour les développeurs JavaScript, principalement à cause de bibliothèques comme Sharp. Bien qu'immensément populaire, avec plus de 55 millions de téléchargements hebdomadaires sur NPM et alimentant l'optimisation d'images de Next.js, le talon d'Achille de Sharp est sa dépendance au binaire natif `libvips`. Cette dépendance externe entraîne fréquemment des échecs d'installation exaspérants dans les builds Docker et les pipelines CI/CD, les développeurs étant aux prises avec des binaires spécifiques à chaque plateforme.

Bun élimine désormais entièrement ce problème avec Bun.Image, une API de traitement d'images intégrée introduite dans Bun 1.3.14. Faisant partie intégrante du runtime, Bun.Image ne possède aucune dépendance native, ce qui signifie qu'elle « fonctionne tout simplement » dès l'installation. Cette approche révolutionnaire évite toute une catégorie de problèmes de build et de déploiement, simplifiant considérablement les flux de travail de développement pour des tâches telles que le redimensionnement, le recadrage et la conversion d'images entre des formats comme JPEG, PNG et WebP.

De manière cruciale, Bun.Image fonctionne avec une architecture non bloquante. Toutes les opérations d'image s'exécutent en dehors du thread principal, garantissant que le traitement gourmand en calcul ne ralentit jamais les performances du serveur ni ne bloque les requêtes entrantes. Cette conception garantit que votre application reste réactive, même sous de lourdes charges de manipulation d'images.

Bun.Image ne se contente pas de simplifier les flux de travail d'images ; il pulvérise les benchmarks de performance existants. Par rapport à Sharp, une bibliothèque largement adoptée, Bun effectue les lectures de métadonnées un étonnant 70 fois plus vite. Les opérations de redimensionnement connaissent également des gains significatifs, s'achevant environ 30 % plus rapidement. Cet avantage de vitesse signifie des chargements de page plus rapides et une réduction de la charge du serveur pour toute application.

Au-delà de la vitesse brute, Bun.Image offre une API robuste et conviviale pour les développeurs. Son API chaînable permet des transformations élégantes en plusieurs étapes comme le redimensionnement, le recadrage et la rotation en un seul appel fluide. Elle convertit sans effort les images vers des formats modernes tels que WebP, améliorant les performances web, et prend en charge nativement une gamme d'autres formats, y compris JPEG, PNG, GIF et BMP, avec HEIC, AVIF et TIFF sur macOS et Windows. Surtout, tout le traitement s'exécute en dehors du thread principal, garantissant des opérations serveur non bloquantes.

Une fonctionnalité remarquable est la fonction astucieuse `placeholder()`, qui génère un ThumbHash ultra-léger de 28 octets. Ce hachage s'encode en une image floue en base64, servant d'indice visuel immédiat pendant le chargement de l'image en pleine résolution. L'intégration de ce minuscule placeholder directement dans le HTML ou le CSS élimine les requêtes réseau supplémentaires, améliorant considérablement les performances perçues sur les connexions plus lentes sans surcharger le serveur ou le client avec des récupérations supplémentaires.

Bun.Image n'est pas une fonctionnalité isolée ; c'est une pièce stratégique d'un puzzle beaucoup plus vaste. Les récentes mises à jour révèlent la voie délibérée de Bun vers un runtime JavaScript verticalement intégré, allant bien au-delà d'un simple gestionnaire de paquets ou d'un bundler. Bun offre désormais SQLite intégré, des clients de base de données unifiés pour S3, Postgres, MySQL, MariaDB, et même un client Redis. Ce n'est pas de l'inflation de fonctionnalités ; c'est un effort méthodique pour consolider et posséder davantage l'infrastructure de base de l'écosystème JavaScript.

Cette approche cohérente alimente la thèse des "Rails for JavaScript". Bun assemble méticuleusement une boîte à outils batteries-included, visant à réduire drastiquement l'dependency hell et à offrir une expérience de développement full-stack fluide, depuis le runtime. En internalisant l'infrastructure commune, Bun élimine la friction liée à la gestion de packages disparates et de leurs dépendances natives souvent fragiles, un problème courant pour les développeurs habitués au paysage fragmenté de Node.js.

Si cette tendance se poursuit, l'ambition de Bun pourrait bientôt englober des solutions pour l'authentification, les services de messagerie et d'autres fonctionnalités d'application essentielles directement au sein du runtime. Cette trajectoire positionne Bun pour éroder davantage la dépendance à Node.js et à son vaste écosystème de packages, offrant une plateforme véritablement tout-en-un. Bien que des solutions externes éprouvées comme Sharp - High Performance Node.js Image Processing restent essentielles pour beaucoup, Bun construit une alternative convaincante et autonome.

Pour les développeurs utilisant déjà Bun, l'adoption de Bun.Image est une évidence incontestable. Il offre des lectures de métadonnées 70 fois plus rapides et des opérations de redimensionnement environ 30 % plus rapides, tout en éliminant les frustrantes dépendances natives `libvips`. Les utilisateurs de Node.js, cependant, trouveront que Sharp reste une solution robuste et éprouvée avec plus de 55 millions de téléchargements hebdomadaires sur NPM ; migrer une pile d'applications et un runtime entiers uniquement pour le traitement d'images constitue une décision significative et complexe.

Cette dernière fonctionnalité arrive au milieu de la réécriture controversée et en cours de Bun, de Zig vers Rust, une décision suscitant des réactions mitigées au sein de la communauté sur des plateformes comme Twitter (maintenant X) (maintenant X). Ce changement, qui utiliserait des outils d'AI, introduit une incertitude quant à la stabilité et à la trajectoire de développement future du projet, malgré son acquisition par Anthropic et ses engagements à rester open-source.

En fin de compte, Bun.Image transcende une simple utilité ; c'est la dernière déclaration d'intention frappante de Jarred Sumner et de l'équipe Bun. Après les clients SQLite, S3/Postgres intégrés, un client Redis et des capacités de développement full-stack, ce processeur d'images natif complète une autre pièce du puzzle audacieux de Bun : construire une nouvelle fondation tout-en-un pour le web moderne, un "Rails for JavaScript" intégré au niveau du runtime.

Qu'est-ce que Bun.Image ?

Bun.Image est une API de traitement d'images intégrée au runtime Bun. Elle vous permet de redimensionner, recadrer, convertir et optimiser des images sans aucune dépendance native, contrairement à des bibliothèques comme Sharp.

En quoi Bun.Image est-il plus rapide que la bibliothèque Sharp ?

Les benchmarks montrent que les lectures de métadonnées de Bun.Image sont jusqu'à 70 fois plus rapides et les opérations de redimensionnement environ 30 % plus rapides que Sharp, principalement en raison de son intégration native avec le runtime Bun et de son implémentation en C++.

Bun.Image prend-il en charge les formats modernes comme AVIF et WebP ?

Oui, Bun.Image prend en charge la conversion d'images vers et depuis des formats modernes comme WebP nativement. Il prend également en charge AVIF, HEIC et TIFF sur macOS et Windows via des backends natifs du système d'exploitation.

Bun.Image est-il une raison suffisante pour passer de Node.js ?

Pour les utilisateurs existants de Bun, c'est une solution native et convaincante. Pour les utilisateurs de Node.js, bien que puissant, changer tout un runtime juste pour le traitement d'images pourrait ne pas être nécessaire car Sharp reste une bibliothèque robuste et éprouvée.