Bun.Image rend tout votre pipeline de traitement d'images obsolète

BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00Voici Bun Image, une API de traitement d'images intégrée fournie avec Bun 1.3.14 qui permet de redimensionner,
00:00:06de rogner et de convertir des images entre différents formats sans aucune dépendance native,
00:00:10et le tout s'exécute en dehors du thread principal, ce qui signifie que cela ne bloquera pas votre serveur pendant
00:00:14le traitement. Mais Bun est déjà un environnement d'exécution, un gestionnaire de paquets, un bundler, un exécuteur de tests,
00:00:19et maintenant c'est un processeur d'images ? N'est-ce pas un peu trop, ou est-ce que cela nous indique quelque chose
00:00:24de plus important sur l'avenir de Bun ? Abonnez-vous et découvrons-le.
00:00:30Si vous avez déjà traité des images sur le serveur avec JavaScript, vous avez peut-être utilisé une bibliothèque appelée
00:00:35Sharp sans même le savoir, qui compte plus de 55 millions de téléchargements par semaine sur npm, et qui est même
00:00:41utilisée par Next.js sous le capot pour l'optimisation des images. Mais Sharp repose sur un binaire natif appelé libvips,
00:00:47ce qui signifie que chaque installation doit récupérer la version adaptée à votre plateforme. Et si vous avez déjà eu
00:00:51un build Docker ou un pipeline CI qui a échoué à cause de cela, vous savez à quel point c'est frustrant. Bun a donc décidé
00:00:57d'intégrer directement le traitement d'images dans l'environnement d'exécution, et c'est en fait plus rapide que Sharp dans
00:01:02la plupart des benchmarks. La lecture des métadonnées est 70 fois plus rapide, et le redimensionnement est environ 30 % plus rapide. De nombreux
00:01:08développeurs se demandent vraiment pourquoi Bun a ajouté cela, mais je vois un peu où tout cela nous mène,
00:01:13et je vous en parlerai un peu plus tard. Mais pour l'instant, passons en revue quelques démos sur l'utilisation
00:01:17de l'API d'image de Bun. Nous allons l'essayer sur mon blog, qui est un site Waku statique comportant
00:01:22de très grosses images. Pour commencer, examinons un script simple qui optimise une seule image,
00:01:27à savoir la photo de profil avec mon visage, et qui permet de réduire la taille de 99 %, ce qui est fou.
00:01:33Voyons comment faire. Tout d'abord, nous récupérons l'image, et notez que nous utilisons Bun.image ici, mais vous pourriez aussi utiliser
00:01:37Bun file avec la fonction image. Ensuite, nous redimensionnons l'image pour réduire sa taille, en lui donnant une largeur de 800
00:01:43pixels, et la hauteur est automatiquement calculée en fonction du ratio d'aspect. Mais si vous le souhaitiez,
00:01:47nous pourrions l'ajouter ici également. Nous définissons ensuite un format de sortie WebP avec une qualité réduite. Bien
00:01:52entendu, d'autres formats de sortie sont pris en charge, puis nous enregistrons la nouvelle image dans un fichier,
00:01:56ce qui renvoie une promise, et nécessite donc le mot-clé await. Et vous pouvez voir à quel point c'est simple.
00:02:01En fait, tout ce code ici est inutile, nous pourrions donc le supprimer et rendre le code encore plus simple.
00:02:06Nous pouvons également définir un filtre de redimensionnement, en modifiant le noyau de rééchantillonnage, pour réduire encore la taille de l'image.
00:02:10Nous pouvons pivoter ou retourner l'image, et c'est vraiment génial. Nous pouvons même modifier la luminosité ou
00:02:15la saturation, ce qui peut donner des résultats assez bizarres. Mais il y a quelque chose de très astucieux que
00:02:19vous pouvez faire en cas de connexions lentes, qui consiste à utiliser la fonction placeholder pour afficher automatiquement
00:02:23une image floue pendant le chargement de l'image principale. Et pour ce faire, j'ai cette boucle for qui
00:02:29parcourt chaque fichier contenant ces extensions dans le répertoire qui regroupe toutes
00:02:34les images du blog. Chaque image est donc redimensionnée, réduite sans être rognée et sans être
00:02:39agrandie. Ensuite, nous créons un espace réservé pour chaque image, ce qui génère un thumbhash, c'est-à-dire qu'il encode
00:02:45n'importe quelle image dans un hachage de 28 octets, parfait comme espace réservé d'image floue.
00:02:49Ce hachage est ajouté à un objet placeholder, puis écrit dans un fichier,
00:02:53qui ressemble à ceci. Maintenant, si l'espace réservé est une image base64 au lieu d'une
00:02:58autre image WebP plus petite, c'est pour éviter au réseau d'avoir à effectuer une requête pour la récupérer.
00:03:02Je peux donc importer tous les espaces réservés et les ajouter comme image de fond en CSS,
00:03:07en attendant que l'image principale se charge, ce qui fonctionnera pour chaque image de mon blog.
00:03:11Mais si vous souhaitez faire cela pour une seule image dans un fichier MDX, vous pouvez simplement ajouter le code base64
00:03:16manuellement, ce qui fonctionne tout aussi bien. Notez que vous pouvez également obtenir un comportement similaire avec
00:03:20des images JPEG en définissant progressive sur true. Bien sûr, BUN image prend en charge
00:03:24tant d'autres choses que je n'ai pas encore abordées, comme la récupération d'images depuis un compartiment compatible S3,
00:03:28ou l'écriture d'images dans un compartiment, l'utilisation du pipeline d'images comme corps de réponse valide,
00:03:33et la configuration d'un format de secours si un OS spécifique ne prend pas en charge un format.
00:03:37Alors, est-ce que cela vaut la peine d'être utilisé ? Eh bien, si vous utilisez déjà BUN, c'est une évidence.
00:03:41Mais si vous utilisez Node, Sharp fonctionne très bien et a fait ses preuves,
00:03:45et il n'est pas nécessaire de passer à un environnement complètement différent juste pour le traitement d'images.
00:03:49Vous vous souvenez quand j'ai dit qu'il y avait une raison plus importante pour laquelle BUN a ajouté cela ? Eh bien, si vous regardez ce que BUN a fait
00:03:54cette dernière année : SQLite, S3, Postgres intégrés, et maintenant les images, c'est pratiquement
00:03:59tout ce dont vous avez besoin pour une application full-stack, à l'exception peut-être de l'authentification et des e-mails. Mais cela me fait me demander,
00:04:04est-ce que BUN essaie de créer le Laravel ou le Rails de JavaScript, mais au niveau de l'environnement d'exécution ? Si c'est le cas,
00:04:11la prochaine chose sur laquelle ils vont travailler, c'est l'authentification. Et si c'est le cas, rappelez-vous, vous l'avez entendu ici en premier.
00:04:15Mais malheureusement, de nos jours, on ne peut pas parler de BUN sans mentionner la grande réécriture de Zig vers Rust,
00:04:20qui, croisons les doigts, sortira dans la prochaine version. Espérons que tout se passe bien.
00:04:25En parlant de Zig, si vous voulez en savoir plus sur Language Zero de Vercel qui ressemble à Zig,
00:04:29mais n'est pas Zig, et qui est conçu pour les agents IA, allez jeter un œil à cette vidéo de James.

Key Takeaway

L'intégration de Bun Image dans Bun 1.3.14 permet d'effectuer des traitements d'images rapides et sans dépendances natives comme libvips, transformant l'environnement d'exécution en une solution complète pour les applications full-stack.

Highlights

  • Bun 1.3.14 intègre une API native de traitement d'images sans dépendance externe.

  • La lecture des métadonnées avec Bun Image s'exécute 70 fois plus rapidement que Sharp.

  • Le redimensionnement d'images avec Bun Image surpasse la vitesse de Sharp d'environ 30 %.

  • Un hachage de 28 octets nommé thumbhash permet d'encoder des espaces réservés flous pour les images.

  • Bun intègre désormais SQLite, S3, PostgreSQL et le traitement d'images au sein de son environnement d'exécution.

Timeline

Présentation de l'API Bun Image

  • Bun 1.3.14 introduit Bun Image pour redimensionner, rogner et convertir des images.
  • Le traitement s'exécute en dehors du thread principal pour éviter de bloquer le serveur.
  • Sharp gère plus de 55 millions de téléchargements par semaine mais dépend du binaire natif libvips.

L'utilisation de bibliothèques traditionnelles comme Sharp pose souvent des problèmes lors des builds Docker ou des pipelines CI en raison des dépendances binaires natives. Bun intègre directement cette logique dans l'environnement d'exécution pour éliminer ces frictions. Les performances surpassent celles de Sharp dans la plupart des benchmarks, avec une lecture des métadonnées 70 fois plus rapide et un redimensionnement amélioré de 30 %.

Démos et manipulation d'images

  • Le code de traitement réduit la taille des fichiers de manière significative tout en ajustant la largeur.
  • La fonction placeholder génère un thumbhash de 28 octets encodé en base64 pour afficher des images floues.
  • Bun Image prend en charge la récupération et l'écriture d'images depuis des compartiments compatibles S3.

Le redimensionnement d'une image s'effectue en spécifiant une largeur cible tandis que le ratio d'aspect s'ajuste automatiquement. Des filtres de rééchantillonnage, des modifications de luminosité ou de saturation, ainsi que des conversions au format WebP optimisent le poids des fichiers. Pour les connexions lentes, la génération de hachages miniatures évite les requêtes réseau superflues en servant d'image de fond temporaire.

Vision globale et écosystème Bun

  • Bun intègre progressivement SQLite, S3, PostgreSQL et le traitement d'images.
  • Ces ajouts positionnent Bun comme une solution d'infrastructure full-stack intégrée.
  • La migration future vers Rust et l'évolution potentielle vers des outils d'authentification marquent la prochaine étape.

L'accumulation de fonctionnalités natives au sein de Bun suggère une volonté de centraliser les briques logicielles nécessaires aux applications modernes, réduisant le besoin de dépendances tierces. Cette stratégie s'apparente aux frameworks full-stack monolytiques mais directement au niveau de l'environnement d'exécution. Les évolutions techniques incluent également la transition du code vers Rust.

Community Posts

View all posts