Arquitectura · 28 de octubre de 2026 · Daniel Murillo

Deno en 2026: seguridad, TypeScript y una nueva forma de ejecutar JavaScript

Deno tiene sentido cuando permisos, APIs web y tooling integrado resuelven necesidades reales. La compatibilidad con Node ha avanzado, pero hay que verificarla.

Deno tiene sentido cuando su modelo de permisos, sus APIs web y su tooling integrado resuelven necesidades reales. Su compatibilidad con Node ha avanzado, pero debe verificarse sobre las dependencias de cada proyecto.

Introducción: ¿y si el runtime también ayudara a limitar el daño?

Deno surgió como una alternativa a Node.js con una filosofía diferente: seguridad por permisos, APIs web modernas, TypeScript directo y un conjunto integrado de herramientas. La idea no era únicamente ejecutar JavaScript más rápido, sino reducir algunas complejidades y riesgos del desarrollo backend.

Con Deno 2, la historia evolucionó. El runtime incorporó compatibilidad más amplia con paquetes npm y APIs de Node, soporte para proyectos con package.json y mejoras en la migración desde ecosistemas existentes. En Deno 2.9, publicado en junio de 2026, el equipo destacó compatibilidad con Node.js 26, soporte de lockfiles de varios gestores y mejoras de rendimiento.

Eso cambia la pregunta. Deno ya no debe evaluarse únicamente como un entorno nuevo que obliga a reescribir todo: también puede ser una plataforma para ejecutar aplicaciones modernas con un modelo de permisos distinto.

La pregunta importante es: ¿cuándo sus principios de diseño compensan las diferencias de ecosistema y operación?

1. ¿Qué es Deno?

Deno es un runtime de JavaScript y TypeScript basado en V8. Incluye herramientas para ejecutar código, comprobar tipos, formatear, linting, testing, tareas y gestión de dependencias.

Entre sus componentes y capacidades están:

Runtime JavaScript/TypeScript.
APIs web como fetch, Request, Response, URL y streams.
Permisos explícitos para acceso al sistema.
deno check, deno fmt, deno lint y deno test.
Gestión de paquetes y compatibilidad con npm (incluido leer lockfiles de npm, pnpm, Yarn y Bun en Deno 2.9).
Registro JSR y soporte de dependencias remotas.
Deno.serve() para HTTP.
Herramientas de auditoría y tareas.
Desde Deno 2.9, deno desktop para empaquetar una UI web + lógica Deno en un binario de escritorio (webview), sin el boilerplate típico de Electron.

deno desktop no convierte a Deno en un sustituto automático de Electron para cualquier app: evalúa empaquetado, APIs de sistema, actualizaciones y distribución. Pero sí amplía el mapa de casos de uso más allá de APIs y CLIs.

2. El modelo de permisos: seguridad por defecto

En Node.js, el código ejecutado dentro de un proceso suele tener acceso al sistema de archivos, la red y las variables de entorno según los permisos del usuario del sistema operativo. Deno adopta un modelo diferente: el programa no recibe acceso irrestricto a recursos sensibles por defecto.

Por ejemplo, un servicio puede recibir permiso de red solo para un host, acceso de lectura a un directorio concreto y permiso para consultar una variable de entorno específica.

# Permitir solo acceso de red al host especificado
deno run --allow-net=api.example.com main.ts

# Permitir lectura solo de una carpeta
deno run --allow-read=./data main.ts

# Permitir acceso a una variable de entorno concreta
deno run --allow-env=API_KEY main.ts

Esto facilita aplicar el principio de mínimo privilegio en scripts, herramientas y servicios. También hace más visible qué recursos necesita un programa.

Lo que el modelo no hace

Los permisos no convierten automáticamente a Deno en una sandbox perfecta para código completamente hostil. Los módulos que se ejecutan dentro del mismo hilo comparten el nivel de privilegios del proceso. Conceder permisos para ejecutar procesos hijos o cargar librerías nativas amplía considerablemente el riesgo. Y los permisos de runtime no sustituyen la auditoría de dependencias ni los controles del sistema operativo.

El modelo es una capa útil, no un sustituto de contenedores, aislamiento, revisión de dependencias y prácticas seguras de despliegue.

Fuente: Deno — Security and permissions

¿Cuándo aporta valor?

Scripts que acceden a archivos o red.
Herramientas internas que ejecutan código de múltiples fuentes.
Servicios que pueden limitarse a un conjunto pequeño de recursos.
Equipos que quieren hacer explícitos los permisos de ejecución.
Procesos de automatización y CI donde se busca reducir el acceso accidental.

En una aplicación donde el contenedor ya aplica límites estrictos, el valor adicional depende de la amenaza que se intenta mitigar y de cómo se administran los permisos.

3. TypeScript y herramientas integradas

Deno permite ejecutar TypeScript sin configurar un transpiler externo para el caso común. Además, su tooling incluye comprobación estática, formatter, linter, pruebas, tareas y herramientas de cobertura/documentación.

Ejemplo de un servicio Hono:

import { Hono } from "hono";

const app = new Hono();

app.get("/health", (context) => {
  return context.json({ status: "ok" });
});

Deno.serve(app.fetch);

En este ejemplo, el código usa TypeScript y APIs web, y el servidor nativo de Deno recibe el handler de Hono.

Ejecutar y comprobar son cosas distintas

Una ventaja de Deno es que puede integrar el type-checking mediante deno check. Un pipeline típico puede incluir:

deno fmt --check
deno lint
deno check main.ts
deno test

La configuración concreta depende del proyecto y de la versión, pero el principio es claro: la facilidad para ejecutar TypeScript no elimina la necesidad de comprobar tipos, tests y contratos.

¿Las herramientas integradas siempre son mejores?

No necesariamente. La integración puede reducir fricción y diferencias de configuración. Pero un equipo puede tener ya un stack consolidado con otras herramientas y no obtener suficiente beneficio de cambiarlo. El objetivo es reducir complejidad real, no sustituir herramientas por deporte.

4. Deno 2 y la compatibilidad con Node.js

Una de las transformaciones más importantes de Deno es su evolución hacia la compatibilidad con npm y APIs de Node.

Deno 2 admite package.json, paquetes npm y un conjunto creciente de módulos node:. Deno 2.9, publicado el 25 de junio de 2026, actualizó su objetivo de compatibilidad hacia Node.js 26 y añadió lectura directa de lockfiles de npm, pnpm, Yarn y Bun en el comando de instalación.

Fuente: Deno 2.9

Eso reduce la barrera de adopción, pero compatibilidad amplia no significa compatibilidad perfecta. Hay que verificar:

APIs de Node utilizadas por las dependencias;
módulos nativos y Node-API;
scripts de instalación;
herramientas que inspeccionan node_modules;
comportamiento de workers y procesos hijos;
SDKs cloud y clientes de base de datos;
APM, tracing y profiling;
paquetes que asumen un gestor o un sistema de módulos específico.

No tomes una afirmación general de compatibilidad como garantía para tu aplicación. La prueba decisiva es la matriz de dependencias del proyecto.

Una migración razonable

Empieza con un servicio pequeño o una herramienta interna. Ejecuta los tests completos, revisa los permisos necesarios y comprueba el despliegue. Si el proyecto depende de una gran cantidad de integraciones de Node, evalúa el costo de cada incompatibilidad antes de cambiar el runtime por defecto.

Documentación: Deno — Node and npm compatibility

5. APIs web y portabilidad

Deno se apoya en APIs web conocidas: fetch, Request, Response, Headers, URL y streams. Eso facilita construir servicios que dependen menos de módulos específicos de Node.

Hono es un ejemplo interesante porque soporta Node.js, Bun y Deno. Una aplicación que usa sus APIs portables puede tener menos acoplamiento al runtime, aunque las dependencias, el despliegue y las APIs de sistema todavía pueden introducir diferencias.

La portabilidad no ocurre por arte de magia. Conviene:

mantener la lógica de negocio separada de las APIs de runtime;
usar interfaces y contratos claros para acceso a base de datos y servicios externos;
evitar importar APIs específicas de un runtime en todos los módulos;
ejecutar tests en cada runtime que realmente se pretenda soportar;
revisar la compatibilidad de dependencias de terceros.

La portabilidad solo es útil si el equipo va a usarla. Si el producto está ligado a una plataforma concreta, no vale la pena pagar un costo adicional solo por una posibilidad hipotética.

6. Frameworks para Deno

Hono

Hono ofrece una interfaz basada en APIs web y se ejecuta en Deno. Puede ser una opción para APIs que quieren mantener una arquitectura portable entre runtimes.

import { Hono } from "hono";

const app = new Hono();

app.get("/", (c) => c.text("Hello from Deno"));

Deno.serve(app.fetch);

Fuente: Hono — Deno

Fresh

Fresh está asociado al ecosistema Deno y se enfoca en aplicaciones web con renderizado en servidor y una arquitectura centrada en islas. Es una opción a evaluar cuando el objetivo no es solo una API REST, sino una aplicación web.

Fuente: Fresh

Oak

Oak es un middleware framework inspirado en Koa y tradicional dentro del ecosistema Deno. Puede ser relevante para equipos que ya tienen aplicaciones Deno construidas con ese estilo.

Fuente: Oak

Express y otros frameworks npm

Deno 2 puede ejecutar muchos paquetes npm, pero no se debe asumir que cualquier aplicación Express, NestJS o Fastify funciona sin ajustes. Los adaptadores, módulos nativos, plugins y herramientas auxiliares deben validarse individualmente.

La elección del framework debe responder a la arquitectura y a las capacidades que necesita el proyecto, no solo al hecho de que el runtime pueda ejecutarlo.

7. Benchmarks de Deno 2.9

Deno 2.9 publicó mejoras de arranque, memoria y throughput HTTP. En la prueba de Deno.serve, el equipo midió tres cargas con concurrencia 100: respuesta de texto, respuesta de 1 MiB y una petición «realworld» que recibe JSON con bearer token y lo devuelve como JSON. La comparación publicada es Deno 2.8 frente a Deno 2.9, en una máquina Linux x86_64 dedicada.

Métrica	Deno 2.8	Deno 2.9	Cambio reportado
Cold start	34,2 ms	17,3 ms	1,98× más rápido
HTTP realworld	56,8k req/s	72,4k req/s	1,27×
HTTP texto	77,0k req/s	85,6k req/s	1,11×
Respuesta de 1 MiB	1 617 req/s	1 907 req/s	1,18×
RSS, realworld	142 MB	64 MB	2,2× menos memoria
RSS, respuesta de 1 MiB	197 MB	63 MB	reducción importante

Fuente: Deno 2.9 — Performance

Qué nos dicen los datos

Estos números demuestran una mejora de Deno entre versiones en las cargas seleccionadas. No demuestran por sí solos que Deno sea más rápido que Node o Bun en cualquier aplicación.

Para comparar runtimes, se necesita una prueba común con las mismas operaciones, dependencias, hardware, configuración, versiones y herramientas. También hay que medir percentiles de latencia, CPU, memoria, errores y comportamiento bajo carga sostenida.

Benchmarks publicados por Bun

La página de benchmarks de Bun también incluye Deno 2.9.5 en pruebas de Express sobre HTTPS, PostgreSQL y WebSockets. Por ejemplo, en su prueba de Express 5.2.1 sobre TLS 1.3, Deno reporta 19 243 req/s y 176 MB de RAM máxima; Bun y Node aparecen con resultados distintos en la misma configuración.

Esos datos son útiles como otra referencia, pero proceden del sitio de Bun y deben interpretarse con la metodología y el código que el proyecto publica. La prueba de PostgreSQL, además, usa un cliente distinto en Bun, por lo que no aísla el runtime.

Fuente: Bun — benchmarks

8. Seguridad no significa automáticamente más rendimiento

Deno ofrece un modelo de permisos integrado que puede reducir el acceso accidental a recursos. Eso puede mejorar la postura de seguridad, pero no garantiza una aplicación más rápida.

Los permisos también requieren trabajo operativo:

definir los recursos necesarios por entorno;
revisar flags y permisos concedidos;
gestionar secretos sin exponerlos;
probar scripts y tareas en CI;
evitar permisos amplios si basta con permisos acotados;
revisar el efecto de procesos hijos y librerías nativas.

La seguridad es una propiedad del sistema completo. El runtime puede aportar controles, pero la aplicación necesita validación de entradas, manejo seguro de secretos, actualizaciones, aislamiento del sistema operativo, controles de red y observabilidad.

9. ¿Cuándo elegir Deno?

Lo evaluaría primero cuando…

los permisos explícitos forman parte de los requisitos de seguridad;
el proyecto es nuevo y puede usar APIs web estándar;
se valora TypeScript, linting, testing y tooling integrados;
Hono u otra librería compatible satisface los requisitos;
se quiere reducir el acoplamiento a APIs específicas de Node;
las dependencias del proyecto se pueden validar en Deno.

Sería más conservador cuando…

la aplicación depende de módulos nativos o internals de Node;
un proveedor solo soporta oficialmente Node.js;
la observabilidad o los procesos auxiliares tienen dependencias específicas;
la organización ya tiene un pipeline maduro y el beneficio de cambiar es pequeño;
la migración implica un riesgo operativo mayor que el valor de los permisos o el tooling.

10. Checklist para evaluar Deno

Identificar APIs de Node y módulos nativos usados por el proyecto.
Probar dependencias npm, SDKs, ORM y drivers de base de datos.
Definir permisos mínimos para archivos, red, entorno y subprocesses.
Ejecutar formatter, linter, type-checker y tests en CI.
Validar OpenTelemetry, APM, profiling y logs.
Probar Docker, health checks, señales y apagado.
Medir arranque, throughput, latencia p95/p99, memoria y CPU.
Hacer una prueba de carga representativa.
Definir despliegue gradual y rollback.
Documentar las diferencias que el equipo debe mantener.

Conclusión

Deno combina TypeScript directo, herramientas integradas, APIs web y un modelo de permisos explícitos. Su compatibilidad con npm y Node ha mejorado lo suficiente como para que merezca evaluarse también como plataforma para proyectos existentes, no solo para aplicaciones nuevas.

Sus ventajas son especialmente relevantes cuando el equipo quiere permisos explícitos, un flujo de desarrollo integrado y menos dependencia de APIs particulares de Node. Su principal cautela sigue siendo la compatibilidad específica de las dependencias y las herramientas operativas.

Elegiría Deno cuando sus permisos y su modelo de desarrollo aporten valor concreto, no simplemente porque sea diferente. Y antes de migrar una plataforma grande, probaría los componentes que más cuestan reemplazar: drivers, SDKs, módulos nativos, observabilidad y despliegues.

En esta serie

Node.js: por qué sigue siendo una apuesta sólida
Bun: ¿realmente es más rápido que Node.js?
Deno (esta nota)
Comparativa final: Node.js vs Bun vs Deno

Lecturas relacionadas

Referencias

Las cifras de rendimiento se atribuyen a los proyectos que las publican. Las mejoras de Deno 2.9 comparan versiones de Deno entre sí; no son un ranking independiente de todos los runtimes. Para una decisión de producción, reproduce los escenarios con la misma carga y publica las versiones y la configuración.

Índice

Arquitectura · 28 de octubre de 2026 · Daniel Murillo

Deno en 2026: seguridad, TypeScript y una nueva forma de ejecutar JavaScript

Deno tiene sentido cuando permisos, APIs web y tooling integrado resuelven necesidades reales. La compatibilidad con Node ha avanzado, pero hay que verificarla.

Deno tiene sentido cuando su modelo de permisos, sus APIs web y su tooling integrado resuelven necesidades reales. Su compatibilidad con Node ha avanzado, pero debe verificarse sobre las dependencias de cada proyecto.

Introducción: ¿y si el runtime también ayudara a limitar el daño?

La pregunta importante es: ¿cuándo sus principios de diseño compensan las diferencias de ecosistema y operación?

1. ¿Qué es Deno?

Deno es un runtime de JavaScript y TypeScript basado en V8. Incluye herramientas para ejecutar código, comprobar tipos, formatear, linting, testing, tareas y gestión de dependencias.

Entre sus componentes y capacidades están:

Runtime JavaScript/TypeScript.
APIs web como fetch, Request, Response, URL y streams.
Permisos explícitos para acceso al sistema.
deno check, deno fmt, deno lint y deno test.
Gestión de paquetes y compatibilidad con npm (incluido leer lockfiles de npm, pnpm, Yarn y Bun en Deno 2.9).
Registro JSR y soporte de dependencias remotas.
Deno.serve() para HTTP.
Herramientas de auditoría y tareas.
Desde Deno 2.9, deno desktop para empaquetar una UI web + lógica Deno en un binario de escritorio (webview), sin el boilerplate típico de Electron.

2. El modelo de permisos: seguridad por defecto

Por ejemplo, un servicio puede recibir permiso de red solo para un host, acceso de lectura a un directorio concreto y permiso para consultar una variable de entorno específica.

# Permitir solo acceso de red al host especificado
deno run --allow-net=api.example.com main.ts

# Permitir lectura solo de una carpeta
deno run --allow-read=./data main.ts

# Permitir acceso a una variable de entorno concreta
deno run --allow-env=API_KEY main.ts

Esto facilita aplicar el principio de mínimo privilegio en scripts, herramientas y servicios. También hace más visible qué recursos necesita un programa.

Lo que el modelo no hace

El modelo es una capa útil, no un sustituto de contenedores, aislamiento, revisión de dependencias y prácticas seguras de despliegue.

Fuente: Deno — Security and permissions

¿Cuándo aporta valor?

Scripts que acceden a archivos o red.
Herramientas internas que ejecutan código de múltiples fuentes.
Servicios que pueden limitarse a un conjunto pequeño de recursos.
Equipos que quieren hacer explícitos los permisos de ejecución.
Procesos de automatización y CI donde se busca reducir el acceso accidental.

En una aplicación donde el contenedor ya aplica límites estrictos, el valor adicional depende de la amenaza que se intenta mitigar y de cómo se administran los permisos.

3. TypeScript y herramientas integradas

Ejemplo de un servicio Hono:

import { Hono } from "hono";

const app = new Hono();

app.get("/health", (context) => {
  return context.json({ status: "ok" });
});

Deno.serve(app.fetch);

En este ejemplo, el código usa TypeScript y APIs web, y el servidor nativo de Deno recibe el handler de Hono.

Ejecutar y comprobar son cosas distintas

Una ventaja de Deno es que puede integrar el type-checking mediante deno check. Un pipeline típico puede incluir:

deno fmt --check
deno lint
deno check main.ts
deno test

La configuración concreta depende del proyecto y de la versión, pero el principio es claro: la facilidad para ejecutar TypeScript no elimina la necesidad de comprobar tipos, tests y contratos.

¿Las herramientas integradas siempre son mejores?

4. Deno 2 y la compatibilidad con Node.js

Una de las transformaciones más importantes de Deno es su evolución hacia la compatibilidad con npm y APIs de Node.

Fuente: Deno 2.9

Eso reduce la barrera de adopción, pero compatibilidad amplia no significa compatibilidad perfecta. Hay que verificar:

APIs de Node utilizadas por las dependencias;
módulos nativos y Node-API;
scripts de instalación;
herramientas que inspeccionan node_modules;
comportamiento de workers y procesos hijos;
SDKs cloud y clientes de base de datos;
APM, tracing y profiling;
paquetes que asumen un gestor o un sistema de módulos específico.

No tomes una afirmación general de compatibilidad como garantía para tu aplicación. La prueba decisiva es la matriz de dependencias del proyecto.

Una migración razonable

Documentación: Deno — Node and npm compatibility

5. APIs web y portabilidad

Deno se apoya en APIs web conocidas: fetch, Request, Response, Headers, URL y streams. Eso facilita construir servicios que dependen menos de módulos específicos de Node.

La portabilidad no ocurre por arte de magia. Conviene:

mantener la lógica de negocio separada de las APIs de runtime;
usar interfaces y contratos claros para acceso a base de datos y servicios externos;
evitar importar APIs específicas de un runtime en todos los módulos;
ejecutar tests en cada runtime que realmente se pretenda soportar;
revisar la compatibilidad de dependencias de terceros.

La portabilidad solo es útil si el equipo va a usarla. Si el producto está ligado a una plataforma concreta, no vale la pena pagar un costo adicional solo por una posibilidad hipotética.

6. Frameworks para Deno

Hono

Hono ofrece una interfaz basada en APIs web y se ejecuta en Deno. Puede ser una opción para APIs que quieren mantener una arquitectura portable entre runtimes.

import { Hono } from "hono";

const app = new Hono();

app.get("/", (c) => c.text("Hello from Deno"));

Deno.serve(app.fetch);

Fuente: Hono — Deno

Fresh

Fuente: Fresh

Oak

Oak es un middleware framework inspirado en Koa y tradicional dentro del ecosistema Deno. Puede ser relevante para equipos que ya tienen aplicaciones Deno construidas con ese estilo.

Fuente: Oak

Express y otros frameworks npm

La elección del framework debe responder a la arquitectura y a las capacidades que necesita el proyecto, no solo al hecho de que el runtime pueda ejecutarlo.

7. Benchmarks de Deno 2.9

Métrica	Deno 2.8	Deno 2.9	Cambio reportado
Cold start	34,2 ms	17,3 ms	1,98× más rápido
HTTP realworld	56,8k req/s	72,4k req/s	1,27×
HTTP texto	77,0k req/s	85,6k req/s	1,11×
Respuesta de 1 MiB	1 617 req/s	1 907 req/s	1,18×
RSS, realworld	142 MB	64 MB	2,2× menos memoria
RSS, respuesta de 1 MiB	197 MB	63 MB	reducción importante

Fuente: Deno 2.9 — Performance

Qué nos dicen los datos

Estos números demuestran una mejora de Deno entre versiones en las cargas seleccionadas. No demuestran por sí solos que Deno sea más rápido que Node o Bun en cualquier aplicación.

Benchmarks publicados por Bun

Fuente: Bun — benchmarks

8. Seguridad no significa automáticamente más rendimiento

Deno ofrece un modelo de permisos integrado que puede reducir el acceso accidental a recursos. Eso puede mejorar la postura de seguridad, pero no garantiza una aplicación más rápida.

Los permisos también requieren trabajo operativo:

definir los recursos necesarios por entorno;
revisar flags y permisos concedidos;
gestionar secretos sin exponerlos;
probar scripts y tareas en CI;
evitar permisos amplios si basta con permisos acotados;
revisar el efecto de procesos hijos y librerías nativas.

9. ¿Cuándo elegir Deno?

Lo evaluaría primero cuando…

los permisos explícitos forman parte de los requisitos de seguridad;
el proyecto es nuevo y puede usar APIs web estándar;
se valora TypeScript, linting, testing y tooling integrados;
Hono u otra librería compatible satisface los requisitos;
se quiere reducir el acoplamiento a APIs específicas de Node;
las dependencias del proyecto se pueden validar en Deno.

Sería más conservador cuando…

la aplicación depende de módulos nativos o internals de Node;
un proveedor solo soporta oficialmente Node.js;
la observabilidad o los procesos auxiliares tienen dependencias específicas;
la organización ya tiene un pipeline maduro y el beneficio de cambiar es pequeño;
la migración implica un riesgo operativo mayor que el valor de los permisos o el tooling.

10. Checklist para evaluar Deno

Identificar APIs de Node y módulos nativos usados por el proyecto.
Probar dependencias npm, SDKs, ORM y drivers de base de datos.
Definir permisos mínimos para archivos, red, entorno y subprocesses.
Ejecutar formatter, linter, type-checker y tests en CI.
Validar OpenTelemetry, APM, profiling y logs.
Probar Docker, health checks, señales y apagado.
Medir arranque, throughput, latencia p95/p99, memoria y CPU.
Hacer una prueba de carga representativa.
Definir despliegue gradual y rollback.
Documentar las diferencias que el equipo debe mantener.

Conclusión

En esta serie

Node.js: por qué sigue siendo una apuesta sólida
Bun: ¿realmente es más rápido que Node.js?
Deno (esta nota)
Comparativa final: Node.js vs Bun vs Deno

Lecturas relacionadas

Referencias

Índice

Arquitectura · 28 de octubre de 2026 · Daniel Murillo

Deno en 2026: seguridad, TypeScript y una nueva forma de ejecutar JavaScript

Deno tiene sentido cuando permisos, APIs web y tooling integrado resuelven necesidades reales. La compatibilidad con Node ha avanzado, pero hay que verificarla.

Deno tiene sentido cuando su modelo de permisos, sus APIs web y su tooling integrado resuelven necesidades reales. Su compatibilidad con Node ha avanzado, pero debe verificarse sobre las dependencias de cada proyecto.

Introducción: ¿y si el runtime también ayudara a limitar el daño?

La pregunta importante es: ¿cuándo sus principios de diseño compensan las diferencias de ecosistema y operación?

1. ¿Qué es Deno?

Deno es un runtime de JavaScript y TypeScript basado en V8. Incluye herramientas para ejecutar código, comprobar tipos, formatear, linting, testing, tareas y gestión de dependencias.

Entre sus componentes y capacidades están:

Runtime JavaScript/TypeScript.
APIs web como fetch, Request, Response, URL y streams.
Permisos explícitos para acceso al sistema.
deno check, deno fmt, deno lint y deno test.
Gestión de paquetes y compatibilidad con npm (incluido leer lockfiles de npm, pnpm, Yarn y Bun en Deno 2.9).
Registro JSR y soporte de dependencias remotas.
Deno.serve() para HTTP.
Herramientas de auditoría y tareas.
Desde Deno 2.9, deno desktop para empaquetar una UI web + lógica Deno en un binario de escritorio (webview), sin el boilerplate típico de Electron.

2. El modelo de permisos: seguridad por defecto

Por ejemplo, un servicio puede recibir permiso de red solo para un host, acceso de lectura a un directorio concreto y permiso para consultar una variable de entorno específica.

# Permitir solo acceso de red al host especificado
deno run --allow-net=api.example.com main.ts

# Permitir lectura solo de una carpeta
deno run --allow-read=./data main.ts

# Permitir acceso a una variable de entorno concreta
deno run --allow-env=API_KEY main.ts

Esto facilita aplicar el principio de mínimo privilegio en scripts, herramientas y servicios. También hace más visible qué recursos necesita un programa.

Lo que el modelo no hace

El modelo es una capa útil, no un sustituto de contenedores, aislamiento, revisión de dependencias y prácticas seguras de despliegue.

Fuente: Deno — Security and permissions

¿Cuándo aporta valor?

Scripts que acceden a archivos o red.
Herramientas internas que ejecutan código de múltiples fuentes.
Servicios que pueden limitarse a un conjunto pequeño de recursos.
Equipos que quieren hacer explícitos los permisos de ejecución.
Procesos de automatización y CI donde se busca reducir el acceso accidental.

En una aplicación donde el contenedor ya aplica límites estrictos, el valor adicional depende de la amenaza que se intenta mitigar y de cómo se administran los permisos.

3. TypeScript y herramientas integradas

Ejemplo de un servicio Hono:

import { Hono } from "hono";

const app = new Hono();

app.get("/health", (context) => {
  return context.json({ status: "ok" });
});

Deno.serve(app.fetch);

En este ejemplo, el código usa TypeScript y APIs web, y el servidor nativo de Deno recibe el handler de Hono.

Ejecutar y comprobar son cosas distintas

Una ventaja de Deno es que puede integrar el type-checking mediante deno check. Un pipeline típico puede incluir:

deno fmt --check
deno lint
deno check main.ts
deno test

La configuración concreta depende del proyecto y de la versión, pero el principio es claro: la facilidad para ejecutar TypeScript no elimina la necesidad de comprobar tipos, tests y contratos.

¿Las herramientas integradas siempre son mejores?

4. Deno 2 y la compatibilidad con Node.js

Una de las transformaciones más importantes de Deno es su evolución hacia la compatibilidad con npm y APIs de Node.

Fuente: Deno 2.9

Eso reduce la barrera de adopción, pero compatibilidad amplia no significa compatibilidad perfecta. Hay que verificar:

APIs de Node utilizadas por las dependencias;
módulos nativos y Node-API;
scripts de instalación;
herramientas que inspeccionan node_modules;
comportamiento de workers y procesos hijos;
SDKs cloud y clientes de base de datos;
APM, tracing y profiling;
paquetes que asumen un gestor o un sistema de módulos específico.

No tomes una afirmación general de compatibilidad como garantía para tu aplicación. La prueba decisiva es la matriz de dependencias del proyecto.

Una migración razonable

Documentación: Deno — Node and npm compatibility

5. APIs web y portabilidad

Deno se apoya en APIs web conocidas: fetch, Request, Response, Headers, URL y streams. Eso facilita construir servicios que dependen menos de módulos específicos de Node.

La portabilidad no ocurre por arte de magia. Conviene:

mantener la lógica de negocio separada de las APIs de runtime;
usar interfaces y contratos claros para acceso a base de datos y servicios externos;
evitar importar APIs específicas de un runtime en todos los módulos;
ejecutar tests en cada runtime que realmente se pretenda soportar;
revisar la compatibilidad de dependencias de terceros.

La portabilidad solo es útil si el equipo va a usarla. Si el producto está ligado a una plataforma concreta, no vale la pena pagar un costo adicional solo por una posibilidad hipotética.

6. Frameworks para Deno

Hono

Hono ofrece una interfaz basada en APIs web y se ejecuta en Deno. Puede ser una opción para APIs que quieren mantener una arquitectura portable entre runtimes.

import { Hono } from "hono";

const app = new Hono();

app.get("/", (c) => c.text("Hello from Deno"));

Deno.serve(app.fetch);

Fuente: Hono — Deno

Fresh

Fuente: Fresh

Oak

Oak es un middleware framework inspirado en Koa y tradicional dentro del ecosistema Deno. Puede ser relevante para equipos que ya tienen aplicaciones Deno construidas con ese estilo.

Fuente: Oak

Express y otros frameworks npm

La elección del framework debe responder a la arquitectura y a las capacidades que necesita el proyecto, no solo al hecho de que el runtime pueda ejecutarlo.

7. Benchmarks de Deno 2.9

Métrica	Deno 2.8	Deno 2.9	Cambio reportado
Cold start	34,2 ms	17,3 ms	1,98× más rápido
HTTP realworld	56,8k req/s	72,4k req/s	1,27×
HTTP texto	77,0k req/s	85,6k req/s	1,11×
Respuesta de 1 MiB	1 617 req/s	1 907 req/s	1,18×
RSS, realworld	142 MB	64 MB	2,2× menos memoria
RSS, respuesta de 1 MiB	197 MB	63 MB	reducción importante

Fuente: Deno 2.9 — Performance

Qué nos dicen los datos

Estos números demuestran una mejora de Deno entre versiones en las cargas seleccionadas. No demuestran por sí solos que Deno sea más rápido que Node o Bun en cualquier aplicación.

Benchmarks publicados por Bun

Fuente: Bun — benchmarks

8. Seguridad no significa automáticamente más rendimiento

Deno ofrece un modelo de permisos integrado que puede reducir el acceso accidental a recursos. Eso puede mejorar la postura de seguridad, pero no garantiza una aplicación más rápida.

Los permisos también requieren trabajo operativo:

definir los recursos necesarios por entorno;
revisar flags y permisos concedidos;
gestionar secretos sin exponerlos;
probar scripts y tareas en CI;
evitar permisos amplios si basta con permisos acotados;
revisar el efecto de procesos hijos y librerías nativas.

9. ¿Cuándo elegir Deno?

Lo evaluaría primero cuando…

los permisos explícitos forman parte de los requisitos de seguridad;
el proyecto es nuevo y puede usar APIs web estándar;
se valora TypeScript, linting, testing y tooling integrados;
Hono u otra librería compatible satisface los requisitos;
se quiere reducir el acoplamiento a APIs específicas de Node;
las dependencias del proyecto se pueden validar en Deno.

Sería más conservador cuando…

la aplicación depende de módulos nativos o internals de Node;
un proveedor solo soporta oficialmente Node.js;
la observabilidad o los procesos auxiliares tienen dependencias específicas;
la organización ya tiene un pipeline maduro y el beneficio de cambiar es pequeño;
la migración implica un riesgo operativo mayor que el valor de los permisos o el tooling.

10. Checklist para evaluar Deno

Identificar APIs de Node y módulos nativos usados por el proyecto.
Probar dependencias npm, SDKs, ORM y drivers de base de datos.
Definir permisos mínimos para archivos, red, entorno y subprocesses.
Ejecutar formatter, linter, type-checker y tests en CI.
Validar OpenTelemetry, APM, profiling y logs.
Probar Docker, health checks, señales y apagado.
Medir arranque, throughput, latencia p95/p99, memoria y CPU.
Hacer una prueba de carga representativa.
Definir despliegue gradual y rollback.
Documentar las diferencias que el equipo debe mantener.