Deno en 2023

Deno Deploy, regiones y viabilidad comercial

• Se informa que Deno Deploy pasó de 35 a 12 regiones de GCP.
• Algunos ven esto como un recorte de costes sensato para una startup; otros temen que señale un crecimiento débil y pueda disuadir a usuarios que necesitan regiones específicas.
• Preocupación sobre el riesgo del proveedor: si el hosting falla, ¿sobrevivirán el runtime y el ecosistema de Deno? Muchos suponen que sí por ser de código abierto y poder autoalojarse, pero no está garantizado.

JSR y el ecosistema de paquetes

• Se entiende JSR como un registro de paquetes JavaScript centrado en TypeScript y una alternativa de facto a npm.
• Reacciones mixtas: antes, el mensaje de Deno sugería que las importaciones por URL evitarían necesitar un registro; ahora parece que están cambiando de rumbo, posiblemente aprendiendo de la experiencia.

Compatibilidad con Node/Bun y propuesta de valor

• Deno se ha movido hacia la compatibilidad con Node (por ejemplo, package.json, integración con npm), en parte porque la falta de compatibilidad dificultaba la adopción.
• Bun se ve como un reemplazo de Node más rápido y directo, mientras que Deno busca “reinventar Node” con APIs de estándares web y herramientas integradas (TS, pruebas, linting, formato, bundling).
• Algunos sostienen que si Node adoptara herramientas integradas similares, Deno/Bun perderían gran parte de su atractivo.

Experiencia del desarrollador: pros y contras

• Puntos a favor de Deno:
  • Instalación en un solo binario; actualizaciones fáciles.
  • Soporte de TS listo para usar, incluido el REPL.
  • Valores predeterminados sensatos; un solo archivo de configuración en lugar de muchos.
  • La stdlib y las herramientas integradas reducen la dispersión de dependencias y el riesgo de la cadena de suministro.
  • Bueno para scripts puntuales y CLIs; puede compilarse a un solo binario.
• Críticas:
  • Las importaciones por URL pueden ser incómodas (especialmente en repositorios privados).
  • El modelo de permisos puede parecer engorroso; algunos acaban usando --allow-all amplio.
  • Ejecutar múltiples procesos de CPU / clustering es más débil que la historia de cluster+pm2 de Node para despliegues bare-metal.

Tamaño de compilación y despliegue

• Los binarios compilados han crecido de ~50 MB a ~90 MB+, lo que algunos ven como demasiado grande para despliegue al estilo Go, límites de serverless o muchas herramientas pequeñas.
• Otros argumentan que 90–100 MB es aceptable para muchos casos de servidor/CLI, especialmente por su carácter autocontenido; los críticos responden que el tamaño importa para FaaS, CI/CD y muchas instancias.
• Miembros del equipo de Deno informan de trabajo continuo que ya ha reducido el tamaño base del binario en ~40% en pruebas, con más mejoras esperadas.

Frameworks, hosting y Next.js/Fresh

• El framework Fresh de Deno se considera competidor de Next.js; algunos temen que su existencia reduzca el incentivo para hacer que Next.js funcione bien en Deno.
• Otros sostienen que Next.js/Vercel están igualmente acoplados, así que es razonable que Deno promocione su propia pila mientras sigue mejorando el soporte para Next.js.
• Fresh se considera prometedor pero “todavía no está listo” para proyectos grandes; algunos ven inmadura la tooling de CSS (más allá de Tailwind/CSS plano).
• Deno Deploy recibe elogios por su simplicidad, pero también críticas por los cold starts y, ahora, por tener menos regiones.

Deno KV y datos

• Deno KV se compara con el datastore de App Engine: clave-valor con indexación manual y transacciones.
• Funciona bien para registros pequeños; los límites estrictos de tamaño lo hacen inadecuado para blobs grandes.
• La herramienta local de desarrollo para KV se describe como agradable; la experiencia en producción en el hilo es limitada, pero cautelosamente positiva.

Seguridad y sandboxing

• El modelo de permisos de Deno (sin acceso a FS/red/env por defecto) se considera un diferenciador central y útil para limitar módulos de terceros (por ejemplo, red solo a hosts específicos).
• Los críticos señalan que un aislamiento similar puede lograrse mediante contenedores o sandboxing del sistema operativo; otros apuntan que los permisos integrados funcionan multiplataforma sin la sobrecarga de contenedores y aportan valor incluso cuando no se usa containerización.

Multihilo y concurrencia

• Se plantea por qué las alternativas a Node (incluido Deno) no tienen “verdadero” multihilo más allá de workers.
• Algunos argumentan que las cargas de trabajo en JS son naturalmente asíncronas y pueden aprovechar workers/C++ addons; otros dicen que el multihilo real sería ampliamente útil, pero es difícil de adaptar al ecosistema asíncrono existente sin problemas de condiciones de carrera.

Nuevos casos de uso e integraciones

• Jupyter + Deno es bien recibido por personas que dominan JS/TS y solo trabajan ocasionalmente con datos, evitando la fricción de dependencias de Python.
• Los hooks de WebGPU y windowing de Deno despiertan interés para crear GUIs de escritorio en JS/TS sin empaquetar un navegador completo (Electron); sin embargo, la creación de ventanas y la entrada/accesibilidad todavía dependen de bibliotecas nativas extra, así que la historia está incompleta.

Sentimiento general

• Muchos expresan un fuerte entusiasmo por el diseño, las herramientas y la marca de Deno, y reportan experiencias de producción fluidas para aplicaciones pequeñas y medianas.
• Los escépticos cuestionan la viabilidad a largo plazo, el tamaño de los binarios, ciertas funciones ausentes (clustering, ecosistema GUI rico, tooling de CSS) y la necesidad de otro runtime/registro de JS.