Beyond Benchmarks: Node.js, Deno, and Bun in Real Production

Hola. Entonces, levanta la mano si alguna vez has visto un benchmark comparando runtimes de JavaScript en el último mes o tal vez en el último año. Lo mismo aquí. He visto alrededor de 40 y cada uno de ellos me dijo algo útil sobre un escenario, pero un escenario que nunca encontraría o encontraría en producción. Así que hoy, quiero darte algo mejor que un gráfico. Quiero darte algunas preguntas que realmente hago antes de elegir un runtime para un sistema real. Mi nombre es Vinicius Neves y compartiré contigo algunos pensamientos sobre la elección de un runtime para JavaScript.

Entonces, este gráfico, lo has visto. O uno exactamente como este. Bun es rápido, como, absurdamente rápido. Dino es sólido. Un Node parece que está corriendo en sandalias. Y cada vez que uno de estos aparece en algún lugar, alguien en tu equipo te señala con, como, esto es algo a lo que debería cambiar. Y mira, el gráfico no está equivocado. Como, estos son números reales. Bun es rápido. Pero aquí está la cosa, rápido es la respuesta. Pero ¿cuál es la pregunta? Porque en ese benchmark, la pregunta era cuántas respuestas JSON puedes servir por segundo en un entorno controlado sin middleware, sin autenticación, sin base de datos, sin registro, sin A4PM, sin manejo de errores, y sin un usuario haciendo cosas raras. Eso no es tu producción. Eso no es la producción de nadie. El benchmark respondió a esa pregunta que nadie está haciendo en la vida real. Entonces, ¿cuáles son las preguntas correctas? Creo que este es el punto.

Así que quiero traerte seis preguntas. Y estas son las preguntas que realmente me importan al elegir un runtime para un sistema de producción. No cuán rápido es la palabra recargar. Estas. Y durante los próximos minutos, voy a guiarte a través de cómo Node, Dino y Bun responden a cada una de ellas. Honestamente, sin ser un fanático o algo así. Y sin declarar un ganador. Porque no hay un ganador aquí.

Pero la primera pregunta. Son las 3 a.m. Tu teléfono de guardia suena. Algo está roto. ¿Qué tan rápido puedes averiguar qué está pasando? Con Node, tienes años de herramientas probadas en batalla. Has hecho esto antes. No es divertido. Pero sabes dónde buscar.

Con Dino, la historia de depuración se ha vuelto un poco más rápida, un poco mejor. Y también soporta el V8 Inspector Protocol. Así que la integración con Chrome DevTools funciona. Pero el ecosistema de herramientas específicas de depuración es más delgado. Cuando te encuentras con un caso límite débil, podrías ser la primera persona escribiendo o buscando sobre ello.

Con Bun. Y digo esto con respeto por lo impresionante que es Bun. Las herramientas de depuración aún son jóvenes. Tiene un depurador. Soporta WebKit Inspector. Pero es un protocolo diferente al de V8. Eso significa que algunas de tus herramientas existentes simplemente no funcionan. A las 3 a.m. un protocolo diferente no es lo que quieres escuchar. Entonces, observabilidad. Las cosas aburridas que nos salvan la vida. El ecosistema de Node es increíblemente maduro aquí. Como Datadog, Neorealic, Sentry, OpenTelemetry. Todos tienen soporte de primera clase para Node. La auto-instrumentación funciona. Lo conectas. Obtienes trazas.

Obtienes métricas. Obtienes seguimiento de errores. Es aburrido. Pero lo aburrido es hermoso para producción. Dino ha estado invirtiendo aquí. Como OpenTelemetry soporta incorporado, lo cual es una elección arquitectónica inteligente. Pero las integraciones APM de terceros aún están poniéndose al día. Algunas funcionan muy bien. Algunas tienen lagunas. Quieres verificar antes de comprometerte.

Pero Bun es el más atrasado en esto. El soporte de OpenTelemetry todavía está evolucionando. Muchos proveedores de APM aún no soportan oficialmente Bun. Así que está mejorando rápido. Pero está mejorando rápido y listo para mi sistema de producción hoy. Son oraciones diferentes.

Otra más. Despliegue. Aquí es donde el contexto importa más que nada. Ejecutar un contenedor Docker con ECS, los tres funcionan. Pero Node tiene las imágenes Docker más probadas. Las mejores prácticas más documentadas. La mayoría de ejemplos de aquí está cómo hacer tu contenedor pequeño y rápido.

Ejecutando serverless. Aquí es donde las cosas se ponen interesantes. Dino tiene Dino deployed. Lo cual es genuinamente excelente. Construido para computación en el borde. Rápido. Elegante. Bun también está incursionando en el espacio. Node en Lambda es maduro. Pero lleva como algo de equipaje. Así que, ejecutándose en el borde como Dino fue diseñado para esto. Bun es rápido aquí. Node puede hacerlo. Pero no nació para ello. Y no olvides CICD. Tu runtime solo se ejecuta en producción. Se ejecuta en tu pipeline. Así que, tiempos de construcción, compatibilidad de contenedores de prueba, almacenamiento en caché de capas de Docker, soporte de acciones de GitHub. Node tiene todo. Configuraciones bien documentadas para cada proveedor de CI importante. Dino y Bun funcionan. Pero te encontrarás escribiendo pasos personalizados, depurando problemas de caché, o descubriendo que tu plugin de CI favorito simplemente no los soporta aún. No es un factor decisivo, pero es fricción. El punto es, qué runtime es mejor para el despliegue es una pregunta sin respuesta sin conocer tu objetivo de despliegue. El runtime no existe en vacío. Existe dentro de tu infraestructura. Así que, el invierno se acerca. Lo sé. Pero no se trata de eso. Se trata de los cold starts.

Y esto solo importa si escala a cero. Lo cual es cada vez más común con despliegues serverless y edgy. Aquí, Bun gana. No hay comparación. Bun arranca increíblemente rápido. Dino también es muy bueno aquí. Significativamente más rápido que Node. Y Node es el más lento en iniciar en frío.

Y si tienes un árbol de dependencias pesado, empeora. Pero ahora, si estás ejecutando contenedores de larga duración, esos reinicios también son débiles. Los inicios en frío son irrelevantes. No te importa. Pero si estás haciendo funciones serverless que se inician por solicitud, esta dimensión de repente se vuelve crítica. El contexto importa. Siempre.

Y las preguntas cinco y seis juntas. Las estoy combinando porque están conectadas. Ecosistema y personas. El ecosistema NPM de Node es masivo. Más de dos millones de paquetes. Sí, muchos de ellos son basura, pero es lo que es. Pero, para casi cualquier necesidad de producción, autenticación, controladores de base de datos, cliente de consultas, generación de PDF, lo que sea. Esa es una biblioteca mantenida importante. No eres la primera persona resolviendo ese problema. Dino ahora tiene compatibilidad con NPM, lo cual es un cambio de juego, pero compatible y mejor probado en diferentes momentos son cosas diferentes. Algunos paquetes funcionan perfectamente. Algunos tienen problemas sutiles. Así que, necesitas verificar.

BUN también tiene compatibilidad con NPM, y esto es impresionante. Impresionante, bueno, pero con alguna clave que se aplica. Y luego, está la contratación. Si estás construyendo un equipo o entregando un proyecto, ¿cuántas personas conocen este runtime? Node está en todas partes. Cada desarrollador de JavaScript ha tocado Node. Los desarrolladores de D1 acceden, pero el grupo de talento es significativamente más pequeño. Así que, para un sistema de producción de larga duración, eso es una consideración real.

Así que, antes de cerrar, solo una rápida ronda de casos extremos. El tipo de cosas que no aparecen en los benchmarks, pero que absolutamente aparecerán en tu sprint. Ya hablé sobre la compatibilidad con NPM. Es realmente impresionante hasta que encuentras una dependencia transitiva profunda en tu árbol que no funciona. Y ahora, estás depurando el paquete de otra persona a las 2 am. El modelo de permisos de Dino es una verdadera victoria de seguridad. Hasta que estás en CLI, cada paso necesita banderas explícitas, y tus configuraciones de pipeline se vuelven el doble de largas.

Node es lento para comenzar, pero si estás ejecutando contenedores de larga duración y eso se reinicia una vez al mes, literalmente no te importa. Tu proveedor de APM dice que soportamos todos los runtimes principales, pero revisa la letra pequeña. Soporte. Soporte a veces significa que tenemos un plugin beta con sin limitaciones, y mi favorito, el benchmark que demostró que BUN es tres veces más rápido usó, cero middleware, cero autenticación, cero manejo de errores. Tu aplicación tiene 12 capas de middleware, así que la brecha se reduce mucho más rápido. Estas no son razones para evitar ningún runtime. Son razones para probar tu carga de trabajo en tu infraestructura antes de comprometerte.