Guía práctica sobre cómo las decisiones de Ryan Dahl con Node.js y Deno moldearon el backend en JavaScript, las herramientas, la seguridad y el flujo de trabajo diario de los desarrolladores — y cómo elegir hoy.
Un runtime de JavaScript es más que una forma de ejecutar código. Es un conjunto de decisiones sobre características de rendimiento, APIs incorporadas, valores por defecto de seguridad, empaquetado y distribución, y las herramientas diarias de las que dependen los desarrolladores. Esas decisiones definen cómo se siente el backend en JavaScript: cómo estructuras servicios, cómo depuras problemas en producción y cuánta confianza tienes al hacer deploy.
El rendimiento es la parte obvia: cuán eficientemente un servidor gestiona I/O, concurrencia y tareas intensivas en CPU. Pero los runtimes también deciden qué obtienes “gratis”. ¿Tienes una forma estándar de obtener URLs, leer archivos, levantar servidores, ejecutar tests, linting o empaquetar una app? ¿O ensamblas esas piezas tú mismo?
Incluso cuando dos runtimes pueden ejecutar JavaScript similar, la experiencia de desarrollador puede ser radicalmente distinta. El empaquetado importa también: sistemas de módulos, resolución de dependencias, lockfiles y cómo se publican las librerías afectan la fiabilidad de build y el riesgo de seguridad. Las elecciones de tooling influyen en el tiempo de incorporación y en el coste de mantener muchos servicios durante años.
Esta historia suele contarse alrededor de personas, pero es más útil enfocarse en restricciones y compensaciones. Node.js y Deno representan respuestas distintas a las mismas preguntas prácticas: cómo ejecutar JavaScript fuera del navegador, cómo gestionar dependencias y cómo equilibrar flexibilidad con seguridad y consistencia.
Verás por qué algunas decisiones tempranas de Node desbloquearon un ecosistema enorme —y qué exigencias trajo eso. También verás qué intentó cambiar Deno y qué nuevas restricciones aparecen con esos cambios.
Este artículo recorre:
Está escrito para desarrolladores, tech leads y equipos que eligen un runtime para servicios nuevos —o mantienen código Node.js existente y evalúan si Deno encaja en partes de su stack.
Ryan Dahl es conocido por crear Node.js (lanzado por primera vez en 2009) y más tarde iniciar Deno (anunciado en 2018). Tomados juntos, ambos proyectos son un registro público de cómo evolucionó el backend en JavaScript y de cómo las prioridades cambian cuando el uso real expone compensaciones.
Cuando apareció Node.js, el desarrollo de servidores estaba dominado por modelos hilo-por-solicitud que sufrían con muchas conexiones concurrentes. El foco temprano de Dahl fue práctico: hacer viable construir servidores de red intensivos en I/O en JavaScript emparejando el motor V8 de Google con un enfoque orientado a eventos y I/O no bloqueante.
Los objetivos de Node fueron pragmáticos: lanzar algo rápido, mantener el runtime pequeño y dejar que la comunidad llenara las lagunas. Ese énfasis ayudó a que Node se expandiera rápido, pero también estableció patrones difíciles de cambiar más tarde —especialmente alrededor de la cultura de dependencias y los valores por defecto.
Casi diez años después, Dahl presentó “10 Things I Regret About Node.js”, describiendo problemas que consideraba incrustados en el diseño original. Deno es el “segundo borrador” modelado por esos arrepentimientos, con valores por defecto más claros y una experiencia de desarrollo más opinada.
En lugar de maximizar la flexibilidad primero, los objetivos de Deno se inclinan hacia una ejecución más segura, soporte moderno de lenguaje (TypeScript) y herramientas integradas para que los equipos necesiten menos piezas de terceros solo para empezar.
El tema en ambos runtimes no es que uno sea “la respuesta correcta”: las restricciones, la adopción y la retrospectiva pueden empujar a la misma persona a optimizar por resultados muy distintos.
Node.js ejecuta JavaScript en un servidor, pero su idea central no es tanto “JavaScript everywhere” como el modo en que maneja la espera.
La mayor parte del trabajo backend es esperar: una consulta a la base de datos, una lectura de archivo, una llamada de red a otro servicio. En Node.js, el bucle de eventos es como un coordinador que lleva la cuenta de esas tareas. Cuando tu código inicia una operación que tardará (como una petición HTTP), Node delega ese trabajo de espera al sistema y sigue adelante inmediatamente.
Cuando el resultado está listo, el bucle de eventos encola una callback (o resuelve una Promise) para que tu JavaScript continúe con la respuesta.
El JavaScript de Node se ejecuta en un hilo principal único, lo que significa que una pieza de JS se ejecuta a la vez. Eso suena limitante hasta que entiendes que está diseñado para evitar hacer “esperas” dentro de ese hilo.
I/O no bloqueante significa que tu servidor puede aceptar nuevas solicitudes mientras otras siguen esperando la base de datos o la red. La concurrencia se logra mediante:
Por eso Node puede sentirse “rápido” bajo muchas conexiones simultáneas, aun cuando tu JS no corre en paralelo en el hilo principal.
Node destaca cuando la mayor parte del tiempo es de espera. Tiene problemas cuando tu app pasa mucho tiempo computando (procesamiento de imágenes, cifrado a escala, transformaciones grandes de JSON), porque el trabajo intensivo en CPU bloquea el hilo único y retrasa todo.
Opciones típicas:
Node suele brillar en APIs y backend-for-frontend, proxies y gateways, apps en tiempo real (WebSockets) y CLIs amigables para desarrolladores donde importa el arranque rápido y el ecosistema rico.
Node.js se construyó para volver práctico JavaScript en el servidor, especialmente para apps que pasan mucho tiempo esperando: solicitudes HTTP, bases de datos, lecturas de archivos y APIs. Su apuesta central fue que la throughput y la capacidad de respuesta importan más que “un hilo por solicitud”.
Node empareja el motor V8 de Google (ejecución rápida de JavaScript) con libuv, una librería en C que maneja el bucle de eventos y el I/O no bloqueante entre sistemas operativos. Esa combinación permitió que Node se mantuviera en un solo proceso y orientado a eventos mientras rendía bien con muchas conexiones concurrentes.
Node también arrancó con módulos centrales pragmáticos —notablemente http, fs, net, crypto y stream— para que pudieras construir servidores reales sin esperar paquetes de terceros.
Trade-off: una librería estándar pequeña mantuvo a Node ligero, pero también empujó a los desarrolladores hacia dependencias externas antes que en otros ecosistemas.
Node temprano dependía mucho de callbacks para expresar “haz esto cuando termine el I/O”. Eso encajaba con el modelo no bloqueante, pero llevó a anidamientos confusos y patrones de manejo de errores.
Con el tiempo, el ecosistema pasó a Promises y luego async/await, que hicieron el código más parecido a la lógica síncrona manteniendo el mismo comportamiento no bloqueante.
Trade-off: la plataforma tuvo que soportar varias generaciones de patrones, y tutoriales, librerías y código de equipos a menudo mezclaron estilos.
El compromiso de Node con la compatibilidad hacia atrás lo hizo seguro para empresas: las actualizaciones rara vez rompen todo de golpe y las APIs centrales tienden a mantenerse estables.
Trade-off: esa estabilidad puede retrasar o complicar mejoras que rompan con el pasado. Algunas inconsistencias y APIs heredadas siguen presentes porque eliminarlas perjudicaría apps existentes.
La capacidad de Node de llamar a bindings en C/C++ posibilitó librerías críticas en rendimiento y acceso a funciones del sistema mediante native addons.
Trade-off: los native addons pueden introducir pasos de compilación específicos por plataforma, fallos de instalación y cargas de seguridad/actualización —especialmente cuando las dependencias se compilan de forma distinta entre entornos.
En resumen, Node optimizó la entrega rápida de servicios en red y el manejo eficiente de I/O, aceptando complejidad en compatibilidad, cultura de dependencias y evolución de APIs a largo plazo.
npm es una gran razón por la que Node.js se propagó tan rápido. Convirtió “necesito un servidor web + logging + driver de base de datos” en unos pocos comandos, con millones de paquetes listos para enchufar. Para los equipos, eso significó prototipos más rápidos, soluciones compartidas y conocimiento comunitario.
npm bajó el coste de construir backends estandarizando cómo instalar y publicar código. ¿Necesitas validación JSON, un helper de fechas o un cliente HTTP? Probablemente hay un paquete —con ejemplos, issues y comunidad— que acelera la entrega, especialmente cuando ensamblas muchas pequeñas funcionalidades bajo fecha límite.
El trade-off es que una dependencia directa puede traer docenas (o cientos) de dependencias indirectas. Con el tiempo, los equipos suelen encontrarse con:
Semantic Versioning (SemVer) suena tranquilizador: los parches son seguros, los minors añaden funcionalidades sin romper y los majors pueden romper. En la práctica, los grandes grafos de dependencias tensionan esa promesa.
Algunos mantenedores publican cambios incompatibles en versiones menores, paquetes quedan abandonados o una “actualización segura” provoca cambios por una dependencia transitoria profunda. Al actualizar una cosa puede que actualices muchas.
Unas prácticas reducen el riesgo sin frenar el desarrollo:
package-lock.json, o ) y commitealosnpm es a la vez un acelerador y una responsabilidad: facilita construir rápido y hace que la higiene de dependencias sea parte real del trabajo backend.
Node.js es famoso por ser poco opinado. Eso es una fortaleza: los equipos pueden ensamblar exactamente el flujo que desean, pero también implica que un proyecto “típico” de Node es realmente una convención construida por hábitos comunitarios.
La mayoría de repos Node gira en torno a un package.json con scripts que funcionan como panel de control:
dev / start para ejecutar la appbuild para compilar o empaquetar (cuando hace falta)test para ejecutar un test runnerlint y para aplicar estilo de códigoEste patrón funciona porque cada herramienta se puede encadenar en scripts y CI/CD puede ejecutar los mismos comandos.
Un flujo típico de Node se convierte en un conjunto de herramientas separadas, cada una resolviendo una parte:
Ninguno de estos es “malo”: son potentes, y los equipos pueden escoger lo mejor. El coste es integrar un toolchain, no solo escribir código de aplicación.
Porque las herramientas evolucionan independientemente, los proyectos Node pueden encontrar problemas prácticos:
Con el tiempo, estos puntos de dolor influyeron en runtimes más nuevos —especialmente Deno— para incluir más valores por defecto (formateador, linter, test runner, soporte TypeScript) y así permitir empezar con menos piezas móviles.
Deno se creó como un segundo intento de runtime JavaScript/TypeScript —uno que reevalúa decisiones tempranas de Node tras años de uso real. Dahl reflexionó públicamente sobre qué cambiaría si empezara de nuevo: la fricción causada por árboles de dependencias complejos, la ausencia de un modelo de seguridad de primera clase y la naturaleza “añadida” de conveniencias de desarrollo que con el tiempo se volvieron esenciales.
Las motivaciones de Deno se resumen en: simplificar el flujo por defecto, convertir la seguridad en una parte explícita del runtime y modernizar la plataforma alrededor de estándares y TypeScript.
En Node.js, un script suele poder acceder a la red, al sistema de archivos y a las variables de entorno sin pedir permiso. Deno invierte ese valor por defecto. Por defecto, un programa Deno se ejecuta sin acceso a capacidades sensibles.
En el día a día, eso significa que concedes permisos intencionadamente al ejecutar:
--allow-read=./data--allow-net=api.example.com--allow-envEsto cambia hábitos: piensas en qué debería poder hacer tu programa, mantienes permisos ajustados en producción y obtienes una señal más clara cuando el código intenta hacer algo inesperado. No es una solución completa de seguridad por sí sola (aún necesitas revisión de código e higiene de la cadena de suministro), pero hace que el camino hacia el “menor privilegio” sea el más natural.
Deno permite importar módulos mediante URLs, lo que cambia cómo piensas las dependencias. En vez de instalar paquetes en un árbol node_modules local, puedes referenciar código directamente:
import { serve } from "https://deno.land/std/http/server.ts";
Esto empuja a los equipos a ser más explícitos sobre de dónde viene el código y qué versión usan (a menudo fijando URLs). Deno también cachea módulos remotos, así que no los vuelves a descargar en cada ejecución —pero aún necesitas una estrategia clara para versionado y actualizaciones, similar a cómo gestionarías upgrades de paquetes npm.
Deno no es “Node.js pero mejor para todo proyecto”. Es un runtime con valores por defecto distintos. Node sigue siendo una opción sólida cuando dependes del ecosistema npm, infraestructura existente o patrones establecidos.
Deno es atractivo cuando valoras herramientas integradas, un modelo de permisos y un enfoque ESM/URL-first —especialmente para servicios nuevos donde esas suposiciones encajan desde el día uno.
Una diferencia clave entre Deno y Node.js es a qué puede acceder un programa “por defecto”. Node asume que si puedes ejecutar el script, puede acceder a todo lo que tu cuenta de usuario pueda: red, archivos, variables de entorno y más. Deno invierte esa suposición: los scripts arrancan con sin permisos y deben solicitar acceso explícitamente.
Deno trata las capacidades sensibles como características con puerta. Las concedes en tiempo de ejecución (y puedes acotarlas):
--allow-net): si el código puede hacer peticiones HTTP u abrir sockets. Puedes restringirlo a hosts concretos (por ejemplo, solo api.example.com).Eso reduce el “radio de blast” de una dependencia o de un snippet copiado, porque no puede acceder automáticamente a cosas que no debería.
Para scripts puntuales, los valores por defecto de Deno reducen exposiciones accidentales. Un script que parsea CSV puede ejecutarse con --allow-read=./input y nada más —así, aunque una dependencia se comprometa, no puede “phoney home” sin --allow-net.
Para servicios pequeños, puedes ser explícito sobre lo que necesitan. Un listener de webhooks podría recibir --allow-net=:8080,api.payment.com y --allow-env=PAYMENT_TOKEN, pero sin acceso al sistema de archivos, dificultando la exfiltración de datos si algo falla.
El enfoque de Node es conveniente: menos flags y menos momentos de “¿por qué falla esto?”. El enfoque de Deno añade fricción —especialmente al principio— porque debes decidir y declarar qué necesita el programa.
Esa fricción puede ser una característica: obliga a los equipos a documentar intenciones. Pero también implica más configuración y depuración ocasional cuando falta un permiso que bloquea una lectura o petición.
Los equipos pueden tratar los permisos como parte del contrato de una app:
--allow-env o amplía --allow-read, pregunta por quéSi se usan de forma consistente, los permisos de Deno se convierten en una checklist ligera de seguridad que vive junto a cómo ejecutas el código.
Deno trata TypeScript como ciudadano de primera clase. Puedes ejecutar un archivo .ts directamente y Deno maneja la compilación en segundo plano. Para muchos equipos, eso cambia la “forma” de un proyecto: menos decisiones de configuración, menos piezas móviles y un camino más claro de “nuevo repo” a “código que funciona”.
Con Deno, TypeScript no es un añadido opcional que requiere un build chain separado desde el día uno. Normalmente no empiezas eligiendo un bundler, configurando tsc y múltiples scripts solo para ejecutar código localmente.
Esto no significa que los tipos desaparezcan: siguen importando. Significa que el runtime se hace cargo de fricciones comunes de TypeScript (ejecución, cacheo de output compilado y alinear comportamiento runtime con chequeos de tipos) para que los proyectos se estandaricen más rápido.
Deno viene con un conjunto de herramientas que cubren lo básico que la mayoría de equipos busca inmediatamente:
deno fmt) para estilo de código consistentedeno lint) para comprobaciones comunes de calidad y correccióndeno test) para ejecutar tests unitarios e de integraciónComo estas herramientas vienen integradas, un equipo puede adoptar convenciones compartidas sin debatir “Prettier vs X” o “Jest vs Y” al inicio. La configuración suele centralizarse en deno.json, lo que mantiene los proyectos previsibles.
Los proyectos Node pueden soportar TypeScript y excelente tooling, pero normalmente ensamblas el flujo tú mismo: typescript, ts-node o pasos de build, ESLint, Prettier y un framework de tests. Esa flexibilidad es valiosa, pero puede llevar a setups inconsistentes entre repos.
El language server y las integraciones de editor de Deno buscan que formateo, linting y feedback de TypeScript se sientan uniformes entre máquinas. Cuando todos usan los mismos comandos integrados, los problemas de “funciona en mi máquina” suelen reducirse —especialmente con formateo y reglas de lint.
Cómo importas código afecta todo lo demás: estructura de carpetas, tooling, publicación e incluso la velocidad para revisar cambios.
Node creció con CommonJS (require, module.exports). Es simple y funcionó bien con paquetes tempranos de npm, pero no es el mismo sistema de módulos que estandarizaron los navegadores.
Node ahora soporta ES modules (ESM) (import/export), pero muchos proyectos viven en un mundo mixto: algunos paquetes son solo CJS, otros solo ESM, y las apps a veces necesitan adaptadores. Eso aparece como flags de build, extensiones de archivo (.mjs/.cjs) o ajustes en package.json ("type": "module").
El modelo de dependencias es típicamente por nombre de paquete resuelto a través de node_modules, con versionado controlado por un lockfile. Es potente, pero también significa que el paso de instalación y el árbol de dependencias pueden formar parte del debugging diario.
Deno nació desde la premisa de que ESM es el predeterminado. Las importaciones son explícitas y a menudo parecen URLs o rutas absolutas, lo que deja más claro de dónde viene el código y reduce la “resolución mágica”.
Para los equipos, el mayor cambio es que las decisiones de dependencia son más visibles en las revisiones de código: una línea de import suele decirte la fuente exacta y la versión.
Las import maps permiten definir alias como @lib/ o fijar una URL larga a un nombre corto. Los equipos las usan para:
Son especialmente útiles cuando una base de código tiene muchos módulos compartidos o quieres nombres coherentes entre apps y scripts.
En Node, librerías suelen publicarse en npm; apps se despliegan con su node_modules (o empaquetadas); scripts suelen depender de instaladores locales.
Deno hace que scripts y herramientas pequeñas se sientan más ligeras (se ejecutan directamente con imports), mientras que librerías tienden a enfatizar compatibilidad ESM y puntos de entrada claros.
Si mantienes un código legado Node, quédate con Node y adopta ESM gradualmente donde reduzca fricción.
Para un código nuevo, elige Deno si quieres estructura ESM-first y control con import-maps desde el día uno; elige Node si dependes mucho de paquetes npm existentes y tooling maduro específico de Node.
Elegir un runtime es menos sobre “qué es mejor” y más sobre encaje. La forma más rápida de decidir es alinear lo que vuestro equipo debe entregar en los próximos 3–12 meses: dónde corre, de qué librerías dependéis y cuánto cambio operativo podéis absorber.
Haz estas preguntas en orden:
Si estás evaluando runtimes mientras necesitas acelerar la entrega, puede ayudar separar la elección del runtime del esfuerzo de implementación. Por ejemplo, plataformas como Koder.ai permiten a equipos prototipar y desplegar apps web, backend y móviles mediante un flujo guiado (con export de código cuando lo necesites). Así puedes hacer un piloto Node vs Deno sin semanas de scaffolding.
Node suele ganar cuando tenéis servicios Node existentes, necesitáis librerías e integraciones maduras o debéis encajar en un playbook de producción muy establecido. También es buena opción cuando la rapidez de contratación e incorporación importa, ya que muchos desarrolladores ya lo conocen.
Deno suele encajar en scripts seguros, herramientas internas y servicios nuevos donde queréis desarrollo TypeScript-first y una cadena de herramientas integrada con menos decisiones de terceros.
En lugar de una reescritura masiva, elige un caso de uso contenido (un worker, un webhook, un job programado). Define criterios de éxito por adelantado —tiempo de build, tasa de errores, latencia en frío, esfuerzo de revisión de seguridad— y limita el piloto en tiempo. Si funciona, tendrás una plantilla replicable para adoptar más.
Un runtime es el entorno de ejecución más sus APIs integradas, expectativas de herramientas, valores por defecto de seguridad y el modelo de distribución. Esas decisiones influyen en cómo estructuras servicios, gestionas dependencias, depuras en producción y estandarizas flujos entre repositorios —no solo en el rendimiento bruto.
Node popularizó un modelo orientado a eventos y I/O no bloqueante que gestiona muchas conexiones concurrentes de forma eficiente. Eso hizo práctico usar JavaScript para servidores centrados en I/O (APIs, gateways, tiempo real), pero también obligó a los equipos a considerar con cuidado el trabajo ligado a CPU que puede bloquear el hilo principal.
El hilo principal de JavaScript en Node ejecuta una porción de JS a la vez. Si realizas cálculos pesados en ese hilo, todo lo demás espera.
Mitigaciones prácticas:
Una librería estándar reducida mantiene el runtime ligero y estable, pero empuja a depender antes de paquetes de terceros para necesidades cotidianas. Con el tiempo eso implica más gestión de dependencias, más revisión de seguridad y más esfuerzo de integración del toolchain.
npm acelera el desarrollo al hacer la reutilización trivial, pero también crea grandes árboles de dependencias transitivas.
Guardarrabos prácticos:
npm audit (y revisiones periódicas) y elimina dependencias que no usesEn grafos de dependencias reales, una actualización puede traer muchos cambios transitivos y no todos los mantenedores siguen SemVer al pie de la letra.
Para reducir sorpresas:
Los proyectos Node suelen ensamblar herramientas separadas para formateo, linting, testing, TypeScript y bundling. Esa flexibilidad es potente, pero genera proliferación de configuraciones, desajustes de versiones y deriva de entornos.
Para mitigarlo: estandariza scripts en package.json, fija versiones de herramientas y fuerza una misma versión de Node en local y CI.
Deno nació como un “segundo borrador” que reevalúa decisiones de la era Node: es TypeScript-first, trae herramientas integradas (fmt/lint/test), usa módulos ESM por defecto y enfatiza un modelo de permisos. Es una alternativa con distintos valores por defecto, no un reemplazo absoluto de Node.
Node suele permitir por defecto acceso total a red, sistema de archivos y variables de entorno del usuario que ejecuta el script. Deno deniega esas capacidades por defecto y exige flags explícitos (por ejemplo, --allow-net, --allow-read).
En la práctica, esto fomenta ejecuciones con principio de menor privilegio y hace que los cambios de permisos sean revisables junto al código.
Empieza con un piloto pequeño y delimitado (un webhook, un job programado o un CLI interno) y define criterios de éxito (despliegue, rendimiento, observabilidad, esfuerzo de mantenimiento).
Comprobaciones iniciales:
npm-shrinkwrap.jsonyarn.locknpm audit es un mínimo; considera revisiones programadas de dependenciasformattypecheck cuando hay TypeScript--allow-read, --allow-write): si puede leer o escribir archivos. Puedes limitarlo a carpetas concretas (como ./data).--allow-env): si puede leer secretos y configuración desde variables de entorno.