Anuncio del lanzamiento de Bun 1.2

Actualización de Bun 1.2

• Bun 1.2 mejora considerablemente la compatibilidad con Node.js e incorpora una API de almacenamiento de objetos S3 y un cliente de Postgres. bun install ahora usa bun.lock, basado en texto. También triplica el rendimiento de Express.

Compatibilidad con Node.js

• Bun fue diseñado como un reemplazo de Node.js y mejora la compatibilidad ejecutando el conjunto de pruebas de Node.js.
• Al resolver diferencias en las API internas y en los mensajes de error, logra pasar más del 90% de las pruebas de los módulos de Node.js.

Servidor HTTP/2 y otros módulos

• Se puede crear un servidor HTTP/2 usando node:http2, lo que también es necesario para servidores gRPC.
• Se pueden enlazar y conectar sockets UDP usando node:dgram.
• Se pueden crear varias instancias de Bun con node:cluster para procesar trabajo en paralelo.
• El módulo node:zlib fue reescrito en código nativo, duplicando su rendimiento.

Soporte para S3

• Bun 1.2 integra la API de S3 para leer, escribir y eliminar archivos.
• El cliente S3 de Bun está escrito en código nativo y es 5 veces más rápido que Node.js.

Soporte para Postgres

• Se pueden ejecutar consultas SQL con Bun.sql, lo que ayuda a prevenir inyecciones SQL.
• Bun.sql es un 50% más rápido que otros clientes de Postgres.

Gestor de paquetes

• bun install ahora usa bun.lock, basado en texto, para ser más rápido y reducir conflictos de merge.
• Se pueden usar comentarios y comas finales en package.json.
• Se puede leer el archivo .npmrc para configurar el registro de npm.

Test runner

• Bun ofrece un test runner integrado que facilita escribir y ejecutar pruebas.

[GN⁺]

Opiniones en Hacker News

• Algunos usuarios cuestionan que se incluyan bibliotecas externas en la biblioteca principal, y consideran que sería mejor dejarlas como bibliotecas opcionales

  • Un runtime debería ser muy cuidadoso al incluir cosas en la biblioteca estándar, y lo que ya se ha incluido puede volver más complejo el proyecto

• Hay quienes comentan que la experiencia de usar Bun ha sido muy buena

  • Configurar TypeScript, Jest, React y Webpack era engorroso, pero Bun es simple y efectivo
  • No pueden opinar sobre la integración de bibliotecas externas, pero en general se están enfocando en lo que más se pide

• Hay opiniones de que el comportamiento predeterminado es demasiado mágico

  • Por ejemplo, dar al usuario una URL prefirmada en lugar de descargar un archivo de S3 es una decisión sorprendente
  • No está claro cómo desactivar este comportamiento

• También se comenta que las funciones integradas marcan una gran diferencia

  • Les gusta que la Web API venga incluida de forma predeterminada en los runtimes de V8 y WebKit
  • Sin embargo, S3 puede haber ido demasiado lejos; los drivers SQL se entienden, pero hace falta pensar hasta dónde conviene incluir cosas
  • Al agregar APIs sensibles, podrían estar pasándose por alto problemas de seguridad

• Una opinión señala que un cliente ya usa Bun en producción y que la experiencia de desarrollo es muy buena

  • La experiencia de desarrollo puede jugar un papel muy importante a largo plazo
  • Si el codebase o los procesos no son buenos, se puede terminar perdiendo talento valioso

• Hay comentarios de que la lista de funciones de Bun es tan larga que genera dudas sobre si todo será sólido y libre de bugs

  • Desde la perspectiva de gestión del proyecto, no se entiende dedicar tiempo al soporte de S3
  • Conseguir clientes de Next.js podría ser una mejor forma de crecer

• En Bun 1.2 se añadió soporte para HTML import

  • Con una sola sentencia import, se puede reemplazar todo el toolchain de frontend
  • Hay quienes opinan que es una función muy sorprendente y genial

• Algunos comentan que su primera experiencia con Bun fue muy impresionante

  • Configurar Webpack o Vite era molesto, pero Bun simplemente funcionó
  • No valía la pena configurar todo eso para scripts pequeños, pero Bun funcionó de maravilla

• Hay opiniones de quienes pensaban que fracasaría como alternativa a Node.js, pero tras usar Bun quedaron satisfechos

  • Pudieron crear fácilmente scripts independientes para manejar TypeScript y actualizaciones de bases de datos SQLite
  • También lo probaron en proyectos nuevos de JS/TypeScript, y todo funcionó rápido

• Se comenta que el proceso de aseguramiento de calidad es más bien formal

  • Parece que se fusionaron y lanzaron cambios cuando el build no estaba pasando
  • Si las pruebas son inestables, será difícil rastrear regresiones