Bun.Image hace que todo tu proceso de imágenes quede obsoleto

Españolالعربية Deutsch English Français हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

Computing/SoftwareInternet Technology

Transcript

00:00:00Esto es Bun Image, una API de procesamiento de imágenes integrada en Bun 1.3.14 que puede redimensionar,

00:00:06recortar y convertir imágenes entre distintos formatos sin dependencias nativas,

00:00:10y todo ello se ejecuta fuera del hilo principal, lo que significa que no bloqueará tu servidor

00:00:14mientras procesa. Pero Bun ya es un entorno de ejecución, un gestor de paquetes, un bundler, un ejecutor de tests,

00:00:19¿y ahora también un procesador de imágenes? ¿Es demasiado, o nos está indicando algo

00:00:24más grande sobre hacia dónde se dirige Bun? Suscríbete y averigüémoslo.

00:00:30Si alguna vez has procesado imágenes en el servidor con JavaScript, quizás hayas usado una librería llamada

00:00:35Sharp sin siquiera saberlo, que tiene más de 55 millones de descargas semanales en npm, e incluso

00:00:41es utilizada por Next.js internamente para la optimización de imágenes. Pero Sharp depende de un binario nativo llamado libvips,

00:00:47lo que significa que cada instalación debe descargar la versión correcta para tu plataforma. Y si alguna vez has tenido

00:00:51un fallo en una compilación de Docker o en tu pipeline de CI debido a esto, sabes lo frustrante que es. Así que Bun decidió

00:00:57simplemente integrar el procesamiento de imágenes en el propio entorno de ejecución, y es más rápido que Sharp en

00:01:02la mayoría de los benchmarks. La lectura de metadatos es 70 veces más rápida y el redimensionamiento es aproximadamente un 30% más veloz. Ahora, muchos

00:01:08desarrolladores están confundidos sobre por qué Bun añadió esto, pero creo ver hacia dónde va todo esto,

00:01:13y te hablaré un poco de eso más tarde. Pero por ahora, veamos algunas demos de cómo usar

00:01:17la API de imágenes de Bun. Vamos a probarla en mi blog, que es un sitio Waku estático, el cual tiene

00:01:22imágenes muy grandes. Para empezar, hagamos un script sencillo que optimice una imagen,

00:01:27que es la foto de perfil con mi cara, y es capaz de reducir su tamaño en un 99%, lo cual es una locura.

00:01:33Veamos cómo. Primero, obtenemos la imagen, y fíjate que usamos Bun.image aquí, pero también podrías usar

00:01:37Bun.file con la función de imagen. Luego redimensionamos la imagen para reducir su tamaño, dándole un ancho de 800

00:01:43píxeles, y la altura se calcula automáticamente según la relación de aspecto. Pero si quisieras,

00:01:47podríamos añadirla también aquí. Luego le damos un formato de salida WebP con calidad reducida. Por

00:01:52supuesto, otros formatos de salida son compatibles, y luego guardamos la nueva imagen en un archivo,

00:01:56lo cual es una promesa, por lo que requiere la palabra clave await. Y puedes ver lo sencillo que es.

00:02:01De hecho, todo este código es innecesario, así que podríamos eliminarlo y hacerlo aún más simple.

00:02:06También podríamos establecer un filtro de redimensionamiento, cambiando el kernel de remuestreo, reduciendo aún más el tamaño de la imagen.

00:02:10Podríamos rotar o voltear la imagen, y esto es genial. Incluso podríamos cambiar el brillo o

00:02:15la saturación, lo que podría dar lugar a imágenes bastante extrañas. Pero hay algo muy inteligente que

00:02:19puedes hacer cuando tienes conexiones lentas, que es usar la función de marcador de posición (placeholder) para

00:02:23mostrar automáticamente una imagen borrosa mientras la principal se está cargando. Y para hacer eso, tengo este bucle for que

00:02:29recorre cada archivo que contiene estas extensiones dentro del directorio donde están todas

00:02:34las imágenes del blog. Así que cada imagen se redimensiona, se escala hacia abajo sin recortarse, y sin

00:02:39escalarse hacia arriba. Luego creamos un marcador de posición para cada imagen, lo que crea un 'thumb hash', lo que significa que codifica

00:02:45cualquier imagen en un hash de 28 bytes, perfecto como marcador de posición borroso.

00:02:49Este hash se añade a un objeto de marcadores de posición, y luego se escribe en un archivo,

00:02:53que se ve así. Ahora, la razón por la que el marcador de posición es una imagen en base64 en lugar de una

00:02:58imagen WebP más pequeña separada es para que la red no tenga que hacer una petición para obtenerla.

00:03:02Así que lo que podría hacer es importar todos los marcadores y añadirlos como imagen de fondo en CSS,

00:03:07mientras espero a que la imagen principal se cargue, lo cual funcionará para cada imagen de mi blog.

00:03:11Pero si quisieras hacer eso para una sola imagen en un archivo MDX, podrías simplemente añadir el código base64

00:03:16manualmente, lo cual funciona igual de bien. Nota: también puedes obtener un comportamiento similar usando

00:03:20imágenes JPEG estableciendo 'progressive' como true. Por supuesto, hay muchas otras cosas que Bun Image

00:03:24soporta que aún no he cubierto, como poder obtener imágenes de un bucket compatible con S3,

00:03:28o escribir imágenes en un bucket, usar el pipeline de imágenes como un cuerpo de respuesta válido,

00:03:33y configurar un formato de respaldo si un sistema operativo específico no soporta uno.

00:03:37Entonces, ¿vale la pena usarlo? Bueno, si ya estás usando Bun, entonces sí, es una decisión fácil.

00:03:41Pero si usas Node, entonces Sharp funciona muy bien y ha sido probado en batalla,

00:03:45y no hay necesidad de cambiar a un entorno de ejecución completamente diferente solo para el procesamiento de imágenes.

00:03:49Recuerdas cuando dije que hay una razón más grande por la que Bun añadió esto? Bueno, si miras lo que Bun ha estado

00:03:54haciendo durante el último año, SQLite integrado, S3, Postgres, y ahora imágenes, eso es básicamente

00:03:59todo lo que necesitas para una aplicación full-stack, excepto quizás autenticación y email. Pero esto me hace preguntarme,

00:04:04¿está intentando Bun construir el Laravel o Rails para JavaScript, pero al nivel del entorno de ejecución? Si lo están haciendo,

00:04:11entonces lo siguiente en lo que trabajarán será la autenticación. Y si es así, recuerda, lo escuchaste aquí primero.

00:04:15Pero desafortunadamente, hoy en día, no puedes hablar de Bun sin mencionar la enorme reescritura de Zig a Rust

00:04:20que, crucemos los dedos, saldrá en la próxima versión. Esperemos que todo salga bien.

00:04:25Hablando de Zig, si quieres aprender más sobre Language Zero de Vercel, que parece Zig,

00:04:29pero no es Zig, y está construido para agentes de IA, echa un vistazo a este video de James.

Key Takeaway

Bun 1.3.14 introduce Bun Image, una API de procesamiento de imágenes nativa y más rápida que Sharp que opera fuera del hilo principal y apunta hacia un ecosistema full-stack integrado.

Highlights

Bun 1.3.14 integra una API de procesamiento de imágenes que funciona fuera del hilo principal para evitar bloquear el servidor.
La lectura de metadatos con Bun Image es 70 veces más rápida y el redimensionamiento supera a Sharp en un 30% en velocidad.
El procesamiento permite reducir el tamaño de una imagen en un 99% mediante la combinación de redimensionamiento, formato WebP y calidad ajustada.
La función de marcador de posición genera un hash de 28 bytes en base64 para mostrar una previsualización borrosa antes de cargar la imagen principal.
El ecosistema de Bun incluye bases de datos integradas, almacenamiento S3 y procesamiento de imágenes, lo que cubre los requerimientos de una aplicación full-stack.

Timeline

Introducción a Bun Image y problemas con Sharp

Bun 1.3.14 añade una API nativa para redimensionar, recortar y convertir formatos de imagen.
El procesamiento se ejecuta fuera del hilo principal para prevenir bloqueos en el servidor.
La librería Sharp depende del binario nativo libvips, lo que genera fallos en Docker y pipelines de CI.
La lectura de metadatos en Bun Image es 70 veces más rápida y el redimensionamiento es un 30% más veloz que en Sharp.

Las librerías tradicionales de procesamiento de imágenes en JavaScript como Sharp dependen de binarios externos que complican las instalaciones y los despliegues. La integración directa de estas capacidades dentro del entorno de ejecución elimina dependencias y mejora el rendimiento general en los benchmarks de velocidad.

Demostración de optimización de imágenes y marcadores de posición

Un script sencillo con Bun Image reduce el tamaño de una foto de perfil en un 99%.
La API permite modificar el kernel de remuestreo, rotar, voltear, cambiar brillo y ajustar la saturación.
La función de marcador de posición codifica cada imagen en un hash de 28 bytes para conexiones lentas.
El hash se incrusta en base64 como imagen de fondo en CSS para evitar peticiones adicionales a la red.

Las demostraciones prácticas muestran la manipulación de archivos mediante funciones sencillas que aceptan formatos WebP y calidades personalizadas. Asimismo, la generación de miniaturas en base64 optimiza la experiencia de carga en sitios web estáticos al mostrar contenido visual borrosa de manera instantánea mientras se descarga el archivo principal.

Perspectivas futuras y reescritura de Bun

Bun Image resulta ideal para proyectos que ya utilizan este entorno de ejecución, aunque Node con Sharp sigue siendo viable.
La incorporación progresiva de SQLite, Postgres, S3 y procesamiento de imágenes abarca casi todo lo necesario para aplicaciones full-stack.
La autenticación podría ser el próximo componente en integrarse al nivel del entorno de ejecución.
La siguiente versión de Bun incluye una reescritura masiva desde Zig hacia Rust.

La acumulación de herramientas nativas sugiere una dirección clara hacia la simplificación del desarrollo full-stack en JavaScript. Las decisiones de arquitectura recientes y la transición tecnológica pendiente marcan la evolución técnica del entorno de ejecución.

Community Posts

Write about this video