Deno 2.8

• deno add y deno install ahora tratan por defecto los nombres de paquete sin prefijo como paquetes npm: en el CLI, por lo que resulta más fácil usarlos en proyectos Node existentes en lugar de npm install, yarn o pnpm install
• deno audit fix actualiza automáticamente las dependencias npm vulnerables a la versión de parche más cercana que cumpla las restricciones de versión, y muestra por separado los casos que requieren un cambio de versión mayor
• Se agregaron nuevos subcomandos: deno ci, deno pack, deno transpile, deno why y deno bump-version, con soporte para instalaciones reproducibles, creación de tarballs para publicar en npm, conversión de TS→JS, rastreo de rutas de dependencias y actualización de versiones en workspaces
• La compatibilidad con la API de Node.js subió de alrededor del 42% en Deno 2.7 al 76.4% (3,405/4,457) en Deno 2.8 según la propia suite de pruebas de Node, y muchos módulos node: ahora se cargan de forma diferida, acelerando el arranque de los programas que no los usan
• En rendimiento, frente a Deno 2.7.1 la instalación cold de npm pasó de 3,319 ms a 906 ms, 3.66 veces más rápida; node:buffer base64 mejoró 3.07 veces, el throughput de node:http 2.21 veces y node:crypto scrypt 2.12 veces
• Como cambio de compatibilidad, setTimeout y setInterval globales ahora devuelven el objeto Timeout de Node en lugar de un número, por lo que el código que guardaba el valor de retorno como number o lo usaba en verificaciones de tipo o aritmética debe ajustarse a NodeJS.Timeout u otros equivalentes
• Se integra TypeScript 6.0.3 y deno check junto con el LSP incluyen lib.node por defecto, interpretando tipos de Node como NodeJS.*, Buffer y process sin configuración adicional
• En depuración, la pestaña Network de Chrome DevTools puede mostrar tráfico de fetch(), node:http/node:https y WebSocket de Deno, y con --cpu-prof, --cpu-prof-flamegraph y --cpu-prof-md se pueden generar perfiles de V8, flamegraphs SVG y reportes en Markdown
• Para gestión de paquetes y workspaces se añadieron el protocolo catalog:, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", min-release-age en .npmrc y --package-json, reforzando la unificación de versiones en monorepos, las instalaciones multiplataforma, las instalaciones de producción y la migración desde proyectos Node existentes
• deno compile detecta proyectos de Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start y Vite SSR para ejecutar deno task build y generar el punto de entrada adecuado, además de mostrar el progreso al procesar árboles grandes de dependencias npm
• En pruebas y Web API, los valores predeterminados de sanitizeOps y sanitizeResources en Deno.test() cambian a false, se añaden timeout por prueba y cobertura por función, y llegan OffscreenCanvas, Headers, Request, Response y Streams transferibles, soporte para digest SHA3 y Web Crypto P-521
• En actualizaciones y base del runtime, deno upgrade reduce la descarga de unos 48 MB a 3–6 MB mediante actualizaciones delta cuando están disponibles, permite instalar builds de PR con deno upgrade pr <number>, y V8 sube de 14.6 a 14.9

[GN⁺]

Opiniones de Hacker News

• Deno es útil por su modelo de permisos por defecto, está escrito en Rust y soporta TypeScript de forma nativa
  No estoy tan metido en el ecosistema de desarrollo web/Node/Bun, pero durante años he usado Deno con satisfacción en servicios pequeños. Me pregunto por qué parece que Bun está creciendo tan rápido. No sé si se usa sobre todo como bundler y menos como runtime de JavaScript
  Solo por el sistema de permisos Deno ya resulta atractivo, y no termino de entender por qué la gente se pasa de Node a Bun en vez de irse a Deno

  • Deno y Bun tenían enfoques bastante distintos cuando salieron. Deno era el intento de Ryan, el creador original de Node, de corregir muchas cosas que él veía mal en Node, mientras que Bun desde el inicio se centró en la compatibilidad con Node y en ejecutar frameworks populares como Next.js
    Durante mucho tiempo muchas dependencias y frameworks no funcionaban bien en Deno, y al principio ni siquiera tenía la capacidad de instalar dependencias desde npm. Viendo los ataques a la cadena de suministro de npm, quizá Ryan tenía razón
    Por eso Bun parecía un mejor Node, con muchas funciones de conveniencia y que funcionaba de inmediato con mucha menos configuración. El equipo de Deno parece haber entendido que para tener éxito necesitaba compatibilidad con Node y se ha enfocado en eso en los últimos años. Ahora mismo diría que Deno es más compatible con Node que Bun
  • Cuando empiezas un proyecto paralelo pequeño en TypeScript, puedes usar solo Bun en vez de ahogarte en el mar de npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime
    Como referencia, solo algunos de esos son movimientos de Pokémon; el resto son herramientas reales del ecosistema JS/TS
  • Uso ambos y me gustan. Bun se parece más a un reemplazo drop-in de Node
    Cuando no quieres tocar la configuración de tests, tsconfig o módulos ES, suele funcionar simplemente. Deno tiene una buena biblioteca estándar y excelente soporte de CLI; antes también me gustaba deno deploy, pero últimamente se ha vuelto bastante engorroso
  • Soy principalmente desarrollador backend, pero cuando toco un poco de frontend en proyectos personales, Deno parece la opción más sensata
    Da muchísimo gusto trabajar con él, y es una pena que no se haya expandido más entre la gente de JS
  • Usé Deno alrededor de un año y me gustó por las ventajas ya mencionadas, pero había demasiados problemas de compatibilidad con paquetes como Astro, Prisma y Vite
    Así que me cambié a Bun y todo fue mucho más fluido

• Me pregunto cuál es el estado actual de Deno
  Node es la solución estable y va a seguir ahí. Ahora ya puede usarse TypeScript y parece que pronto también se podrán compilar apps en un solo ejecutable, incluso con dependencias nativas
  Bun es confuso pero rápido, y su enfoque de incluirlo todo en la biblioteca estándar es interesante. Además, fue adquirido por Anthropic
  Deno tenía una narrativa atractiva con el sandbox y la facilidad para importar dependencias de terceros, pero el sandbox ya parece bastante generalizado y no sé si al final su forma de hacer imports era realmente mucho mejor que npm add

  • Deno despidió a cerca de la mitad de su empresa hace unos 2 meses: https://news.ycombinator.com/item?id=47467746
  • ¿Quién ve como algo positivo que lo haya adquirido Anthropic?
  • Para que el ecosistema no se estanque, conviene tener varias opciones
  • La distribución en ejecutable único ya es posible. El CLI de mi producto es una aplicación de ejecutable único en Node
  • No sabía que se podría compilar un ejecutable único incluyendo dependencias nativas. Esa es una función potente

• Deno es excelente. Estoy escribiendo servicios web pequeños y medianos con Deno
  Funciona como reloj suizo y la filosofía del proyecto encaja muy bien con el espíritu Unix
  Personalmente, me parece que la gente que creó Deno es un poco demasiado humilde. Incluso cuando usuarios agradecidos ofrecen donar al proyecto, lo rechazan cortésmente. Entiendo por qué, pero a largo plazo eso podría generar una presión financiera innecesaria sobre el proyecto
  Una suscripción mensual del tipo “por favor acepten mi dinero” podría funcionar bastante bien para usuarios que dependen del éxito a largo plazo del proyecto

  • De verdad es un placer usarlo. Se siente casi como una mezcla de JavaScript y Go
    Es rápido y flexible, ofrece una gestión de paquetes un poco más cuerda y con capacidades más potentes que otras alternativas de JS/TS, un mejor modelo de seguridad, una mejor biblioteca estándar. Y además es rapidísimo

• Para quienes no reconozcan el nombre Deno, Deno es un runtime de JavaScript y TypeScript
  Hay una reseña que compara Deno 2.6 con sus competidores Bun 1.3 y Node.js 25: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Sorprende que Bun sea tanto más rápido procesando solicitudes web. El artículo menciona Zig como factor, pero me pregunto si el control fino de memoria por sí solo puede dar una ventaja de más del doble frente a Node
    De forma parecida, aunque no lo dice claramente, Bun parece haberse ejecutado con caché de paquetes ya caliente. Me pregunto si los otros runtimes también tenían caché

• El ritmo constante de lanzamientos de Deno es impresionante. Tengo curiosidad por ver qué mejoras de rendimiento trae esta versión

• El nuevo comando deno pack es una buena adición para un empaquetado seguro y simple
  Si usas Node.js, un comando único parecido es posible con https://www.npmjs.com/package/ts-node-pack
  Ahora que Node.js soporta importar módulos .ts, más repositorios podrán usar esto sin una etapa de build o sin incluir artefactos compilados en el checkout

  • Al leer esta entrada del blog me puse a pensarlo de inmediato. deno pack quizá podría reemplazar el flujo actual de npm publish de mi paquete open source y servir para seguir moviendo mi trabajo hacia un enfoque Deno-first/centrado en Deno
    Por otro lado, como el soporte de TypeScript en Node sigue creciendo, también creo que cambiarlo a un paquete npm solo para TypeScript podría ser un mensaje muy pequeño para el ecosistema
    Aun así, da gusto que JSR exista como un ecosistema relativamente más limpio
  • Suena bastante parecido a DNT(https://github.com/denoland/dnt), que existe desde hace mucho
    Pero al entrar en el CLI de Deno, su visibilidad aumenta muchísimo

• Si Deno hubiera conservado un poco más sus valores iniciales por más tiempo, la presión por la compatibilidad con Node probablemente habría sido compensada en parte por los agentes de IA
  Gran parte de esa presión viene de un tema de familiaridad. Si solo sabes configurar cosas con express.js, entonces terminas sintiendo que cualquier herramienta o runtime posterior también debe ofrecer abstracciones parecidas para que la transición sea “fluida”, sin importar qué tan mala fuera la primera solución desde el principio
  Hoy se puede entregar junto con el producto el paquete tecnológico necesario e introducir nuevas tecnologías a los desarrolladores; eso a veces realmente reemplaza la documentación y puede servir bastante bien para mostrar formas mejores de abordar las alternativas

  • Si un SDK de JS/TS que me dio un proveedor SaaS no funciona en Deno sin modificaciones, no voy a dedicarle ni un segundo a arreglarlo

• Por haber usado Deno en varios proyectos de hobby, estoy convencido de que Deno es la dirección hacia la que debería ir el ecosistema JS
  Aun así, es complicado recomendarlo en el trabajo fuera de algunos casos de uso específicos y por lo general limitados. Si en algún momento el proyecto cambia de rumbo por razones de negocio, al final terminas necesitando Node

• Desde el lanzamiento de Edge.js [1], da gusto ver que Deno está tomándose más en serio la compatibilidad con Node.js
  En unos 2 meses pasó de estar en el rango del 40% a alrededor del 75%, así que, haya sido coincidencia o no, es claramente un paso en la dirección correcta
  Buen trabajo para todo el equipo de Deno
  [1] https://edgejs.org/

  • ¿No te cansas de autopromocionarte?

• Envuelvo la mayoría de los modismos al estilo Node y uso Deno como runtime. Funciona bien
  Si el proyecto es TypeScript puro, simplemente lo ejecuto con Deno. También me gustan las opciones extra para seguridad y que los scripts de instalación estén desactivados por defecto
  Si estás usando Node directamente, ojalá dejes de hacerlo. Como mínimo, me parece mejor usar Bun
  En trabajo basado en agentes, casi no hay razón para usar otra cosa que no sea Rust y TypeScript. Se puede discrepar, pero la seguridad de tipos, la seguridad de memoria y un corpus enorme de trabajo importan. A los agentes les resulta más fácil explorar cuando hay errores quisquillosos y patrones integrados. Para UI, TypeScript tiene más sentido simplemente porque hay muchísimos ejemplos de diseño disponibles