Deno 2.0 salió en octubre de 2024 y, cinco meses después, es un buen momento para hacer balance. La versión 2.0 no se parece al Deno original de 2018, que nació como un rechazo explícito al diseño de Node.js. Lo que ha hecho Ryan Dahl y su equipo es, probablemente, el movimiento más pragmático que podrían hacer: aceptar que npm ganó, integrarse con el ecosistema existente, y dejar de pelearse contra package.json y node_modules. Sin perder, eso sí, las piezas que siempre han hecho a Deno distinto.

Puntos clave

  • Deno 2 entiende package.json, crea node_modules y funciona con pnpm: la barrera de entrada a proyectos existentes ha caído drásticamente.

  • El modelo de permisos sigue siendo único: sandbox por defecto, sin red ni disco sin flags explícitos.

  • TypeScript nativo sin tsc ni tsx sigue siendo una ventaja real sobre Node.

  • La compatibilidad con Node es mejor que nunca pero no es total: frameworks grandes (Next.js, NestJS) siguen siendo imperfectos.

  • En el ecosistema JavaScript de 2025 hay tres runtimes serios: Node (default maduro), Bun (velocidad bruta), Deno (seguridad y DX).

Qué trae 2.0 de verdad

Compatibilidad con Node. Deno 2 admite el protocolo npm: para resolver paquetes, pero además ahora entiende package.json, respeta las dependencias declaradas ahí, crea y lee node_modules, y funciona con pnpm como gestor si está instalado.

Un deno install en un proyecto existente de Node funciona. Un deno run script.js sobre un archivo que usa require('express') funciona. Esto hace un año era impensable. El anuncio oficial detalla el proceso: Deno 2.0: blog de lanzamiento[1].

Workspaces nativos. Deno 2.0 admite de forma nativa monorepos con múltiples paquetes, compartiendo configuración y dependencias. Para equipos con estructura de monorepo, esto era imprescindible y su ausencia en 1.x era una barrera real.

JSR. El registro oficial que Deno, TypeScript y otros actores del ecosistema han empezado a empujar como alternativa moderna a npm. JSR[2] acepta paquetes directamente en TypeScript, resuelve tipos automáticamente, publica ESM por defecto y admite versionado semántico estricto. Es una propuesta atractiva técnicamente, pero su adopción es todavía pequeña; npm sigue siendo la fuente por defecto.

APIs de Node pendientes cerradas. process.env, partes de fs, y mejor soporte de workers. Las lagunas conocidas se han cerrado casi todas.

Qué problema resuelve en la práctica

El problema que resuelve Deno 2 es concreto: la barrera para probar Deno en un proyecto existente era demasiado alta. Antes, para migrar una app Express a Deno había que reescribir las importaciones, gestionar tipos a mano, convivir con dependencias transitivas extrañas. Hoy el experimento es abrir un proyecto existente, ejecutar deno run main.ts y ver qué pasa.

Esto cambia la conversación. Deno 1.x era una apuesta de todo-o-nada: o rehacías el proyecto a su estilo, o te quedabas en Node. Deno 2.0 es una actualización gradual posible: puedes usar Deno para ejecutar, probar, analizar estilo y formatear tu proyecto Node, manteniendo package.json como fuente de verdad. Migra a las APIs propias de Deno solo cuando te convengan.

Dónde brilla todavía

El modelo de permisos es la más evidente. Deno ejecuta código en un entorno aislado por defecto: un script no puede leer archivos, abrir sockets ni ejecutar subcomandos a menos que se lo permitas explícitamente con flags (--allow-read, --allow-net, etc.).

Para ejecutar código de terceros (scripts de migración, herramientas de terceros, generadores), esto es un valor real. En Node, el módulo --experimental-permission avanza pero sigue siendo experimental y menos completo. La documentación de seguridad de Deno[3] explica el modelo en detalle.

La experiencia de desarrollo sigue siendo un punto fuerte. deno fmt, deno lint, deno test, deno bench y deno task vienen integrados, con salida consistente, sin configuración, y suelen funcionar bien a la primera. En Node los equivalentes requieren ensamblar prettier, eslint, vitest o jest, y tsx o ts-node para ejecutar TypeScript.

Las Web APIs estándar funcionan como en el navegador: fetch, Request, Response, URL, crypto.subtle, WebSocket. Para escribir código que corra tanto en servidor como en edge (Cloudflare Workers, Deno Deploy, Bun), esta es una ventaja real. Ver nuestro análisis de Cloudflare Workers para más contexto.

TypeScript nativo sigue siendo mejor que cualquier alternativa. Deno ejecuta TypeScript sin compilación previa, sin tsc, sin tsx, sin configuración.

Dónde sigue cojeando

La compatibilidad con Node es mejor que nunca pero no es total. Algunos paquetes populares siguen sin funcionar. Los casos típicos son paquetes con binarios nativos que esperan exactamente la estructura de node_modules y el cargador de Node. Puppeteer y Playwright funcionan pero con asteriscos.

Algunos frameworks esperan un ciclo de vida de proceso específico (Next.js, NestJS) y, aunque Deno 2.0 hace un esfuerzo enorme por imitarlo, la compatibilidad con frameworks grandes sigue siendo imperfecta. Para APIs con Express, Fastify o Hono funciona bien en casi todos los casos. Para un Next.js 14 complejo, yo seguiría en Node.

La comunidad y el ecosistema son menores. Encontrar tutoriales, respuestas en Stack Overflow o ejemplos específicos de Deno es más difícil que para Node. Esto se va cerrando pero es un coste real.

El rendimiento en cold starts ha mejorado mucho, pero sigue siendo ligeramente inferior a Bun en benchmarks. Para funciones serverless sensibles al arranque, conviene medir. Para un análisis completo del ecosistema de runtimes JavaScript, ver también full-stack TypeScript en 2025.

Deno frente a Bun frente a Node

El ecosistema JavaScript tiene tres runtimes serios:

  • Node: la opción por defecto, maduro, estable y con todo el soporte del ecosistema. Si no tienes razón concreta para cambiar, no cambies.

  • Bun: apuesta por velocidad bruta y un gestor de paquetes rapidísimo. Para desarrollo es agradable, y su compatibilidad con Node es buena. Para producción es usable ya pero con menos historial.

  • Deno: apuesta por seguridad, experiencia de desarrollo y APIs web estándar. La compatibilidad con Node en 2.0 resuelve la principal fricción.

Mi recomendación informal: Nuevas APIs pequeñas o scripts de infraestructura: Deno 2. Servicios grandes con ecosistema establecido: Node. Desarrollo local con reinicio rápido: Bun. Cualquier proyecto donde la seguridad frente a código de terceros sea importante: Deno por defecto.

Cómo pensar la decisión

La pregunta que resuelve Deno 2.0 no es «¿es mejor que Node?» sino «¿merece la pena intentarlo en mi proyecto?». La respuesta, a diferencia de 2022, es un sí matizado en tres casos:

  • Si tienes un proyecto nuevo que no dependa de un framework grande de Node, Deno es una opción seria.

  • Si tienes un proyecto existente y quieres probar herramientas (formatter, tests, linter) con menos configuración, Deno puede convivir sin reescribir.

  • Si tu preocupación es seguridad frente a dependencias de terceros, el modelo de permisos sigue siendo único.

Deno 2.0 es más humilde que Deno 1.x. Reconoce que Node es el estándar y que la vida práctica pasa por convivir con su ecosistema, pero sigue teniendo identidad propia. Un runtime tiene que elegir entre ser puro o ser útil, y Deno 2 ha elegido útil sin renunciar a sus principios de diseño. Es una decisión madura.

Fuentes:

  1. Deno: Anuncio oficial de Deno 2.0[1]
  2. JSR: Registro de paquetes TypeScript[2]
  3. Deno Docs: Modelo de seguridad y permisos[3]

Preguntas frecuentes

¿Puedo ejecutar un proyecto Node existente con Deno 2 sin reescribirlo?

Sí, con matices. Deno 2 entiende package.json, respeta las dependencias declaradas ahí, crea y lee node_modules, funciona con pnpm si está instalado y admite el protocolo npm:. Un deno install en un proyecto Node existente funciona, y también deno run script.js sobre un archivo que usa require('express'). Puedes mantener package.json como fuente de verdad y migrar a las APIs propias de Deno solo cuando te convenga.

¿Funcionan Next.js o NestJS en Deno 2?

De forma imperfecta: esos frameworks esperan un ciclo de vida de proceso específico y, aunque Deno 2.0 hace un esfuerzo enorme por imitarlo, la compatibilidad con frameworks grandes sigue sin ser total. Para un Next.js 14 complejo conviene seguir en Node. También fallan algunos paquetes con binarios nativos que esperan exactamente la estructura de node_modules de Node. En cambio, APIs con Express, Fastify o Hono funcionan bien en casi todos los casos.

¿Cuándo elegir Deno en lugar de Node o Bun?

Deno 2 encaja en APIs nuevas pequeñas, scripts de infraestructura y cualquier proyecto donde importe la seguridad frente a código de terceros, porque ejecuta en sandbox por defecto y exige flags como --allow-read o --allow-net. Node sigue siendo la opción para servicios grandes con ecosistema establecido, y Bun destaca en desarrollo local con reinicio rápido y en cold starts, donde sigue ligeramente por delante de Deno en benchmarks.

Fuentes

  1. Deno 2.0: blog de lanzamiento
  2. JSR
  3. documentación de seguridad de Deno