Se acabó mi amistad con Deno, ahora Node es mi mejor amigo
Una publicación de blog que sostiene que “no hay razón para usar Deno hoy” reaviva el debate sobre los méritos relativos de Node.js, Deno y Bun como runtimes de JavaScript/TypeScript. Los comentaristas contrastan la estabilidad, longevidad y creciente tooling integrado de Node (como `node:test` y la eliminación de tipos de TS) con la cadena de herramientas integrada de Deno, su modelo más estricto de seguridad/permisos y el ecosistema JSR, y con las afirmaciones de rendimiento y ergonomía de Bun, atenuadas por preocupaciones sobre errores, compatibilidad y el reciente drama corporativo. Varios señalan que los asistentes de codificación de IA ahora influyen fuertemente en la adopción de runtimes al optar por defecto por stacks populares, lo que puede estar acelerando la consolidación en torno a opciones “aburridas” como Node incluso cuando las alternativas ofrecen mejor experiencia de desarrollo o seguridad.
Runtimes: Node, Deno, Bun
- Muchos ven Node como la “opción aburrida y segura”: de larga duración, estable y con probabilidades de sobrevivir a runtimes más nuevos.
- Deno se percibe como filosóficamente más agradable y moderno, pero algunos lo ven derivando hacia la oscuridad.
- Bun recibe elogios por su ergonomía y velocidad, pero también preocupación por errores pasados, la reescritura a Rust, el drama de la adquisición y la supuesta política en torno a sus creadores.
Por qué algunos prefieren Bun
- Elogiado como “más ligero” que Node/Deno: menos dependencias, bundler/herramientas de prueba integradas, compilaciones TS sencillas y despliegue en un solo binario.
- Algunos informan de una buena DX y de una menor necesidad de scripts de shell.
- Otros replican que en benchmarks simples Node usó menos memoria y una CPU similar, cuestionando la narrativa de rendimiento de Bun.
Por qué algunos se quedan con Node
- Considerado maduro, estable y ampliamente compatible; rendimiento “lo suficientemente bueno”.
- Algunos dicen que todo lo demás acaba siendo reabsorbido por el ecosistema de Node.
node:testy la cobertura integrados se señalan como mejoras, aunque el linting/la comprobación de tipos siguen necesitando herramientas extra.
Por qué algunos siguen eligiendo Deno
- Puntos fuertes: test/lint/check integrados, historia sencilla con TS, permisos de seguridad, JSR/biblioteca estándar y capacidad de compilar a un solo binario.
- Se destacan el soporte de escritorio/WebGPU y el sandboxing como ventajas únicas, especialmente para uso de agentes/IA.
- A varios les gusta su sensación de “una sola CLI, todo incluido” frente a la dispersión de configuración/herramientas de Node.
Debates sobre HTTP y compatibilidad
- Debate acalorado sobre HTTP GET con un cuerpo de petición:
- Un lado insiste en que no es estándar e inseguro; las implementaciones pueden ignorarlo.
- Otros señalan que herramientas muy usadas (p. ej., Elasticsearch, algunos clientes GraphQL, herramientas de infraestructura) dependen de ello y esperan el comportamiento de Node; el comportamiento más estricto de Bun se ve como una ruptura de compatibilidad.
TypeScript y ecosistema
- Desacuerdo con la afirmación del artículo de que las limitaciones de TS en Node son anti-Microsoft “filosóficas”; los comentaristas citan razones técnicas concretas (diferencias de tsconfig, rendimiento).
- Algunos sostienen que los archivos de declaración resuelven la mayoría de las necesidades de tipado de librerías; otros solo quieren un simple eliminación de tipos para el código fuente TS.
- División más amplia: algunos ven TypeScript/el tipado fuerte como esencial para sistemas no triviales, otros ven TS como una sobrecarga con beneficio limitado.
LLMs y elección de herramientas
- Varios señalan que los LLM suelen optar por defecto por Node/Bun/Next.js/Supabase, empujando la adopción.
- Otros sostienen que los usuarios competentes deberían decir explícitamente a los LLM qué runtime/stack usar; que “los LLM no lo eligen” afecta sobre todo a la popularidad del producto, no a su capacidad.