Deno se une a Cloudflare y el riesgo de un monocultivo en JavaScript

El 9 de octubre, Ryan Dahl anunció que todo el equipo de Deno se une a Cloudflare. Lo que más pesa del anuncio no es la compra, sino lo que viene después: dentro de un año dejarán de desarrollar el runtime de Deno. Kate Holterhoff, de RedMonk, ha publicado un análisis que pone el foco en lo que esto significa para el ecosistema: cada vez quedan menos runtimes de JavaScript independientes, y casi todos dependen del motor de un navegador.

Qué cambia en concreto

El anuncio es bastante claro con los plazos:

El equipo se dedicará a celld, un proyecto basado en el modelo de programación de Workers y en Durable Objects, que según Dahl encajan especialmente bien para ejecutar agentes de IA: ejecución serverless barata, estado persistente y WebSockets.

Lo de Deno Deploy me ha hecho volver a mi artículo de principios de mes sobre Netlify y sus Edge Functions. Allí contaba que, desde 2022, esas funciones se ejecutaban en un servicio externo que el artículo de Netlify no nombraba, pero que era Deno Deploy, y que Netlify acababa de llevarlas a microVMs dentro de su propia red. Ocho días después llegaba el anuncio de Deno.

Con qué nos quedamos

Según RedMonk, sin Deno quedan dos runtimes generalistas importantes, Node.js, de la OpenJS Foundation, y Bun, de Anthropic, y además workerd, de Cloudflare, pensado sobre todo para su propia plataforma. Lo que preocupa a Holterhoff es de dónde sale el motor de cada uno:

flowchart LR
    A["V8 · Google"] --> N["Node.js"]
    A --> W["workerd"]
    A --> D["Deno"]
    J["JavaScriptCore · Apple"] --> B["Bun"]

Dos de las tres alternativas a Node pertenecen ahora a empresas cuyo negocio principal es otro, y tres de los cuatro runtimes comparten el motor de Chrome.

Por qué importa

El artículo de RedMonk lo argumenta con tres ideas que me parecen bien escogidas:

• El precedente de Internet Explorer 6. Microsoft lo publicó en 2001, llegó a tener nueve de cada diez usuarios y después prácticamente dejó de trabajar en él. Durante unos cinco años se programaba para las rarezas de un navegador y no para los estándares, hasta que Firefox, Safari y Chrome devolvieron la competencia.
• Los estándares necesitan implementaciones independientes. En TC39 una propuesta necesita dos implementaciones independientes para entrar en el estándar, porque una especificación escrita para un único producto acaba describiendo ese producto. En el servidor existe WinterTC, que define APIs comunes para que el código funcione en cualquier runtime. Con menos voces independientes, lo que haga el runtime más usado se convierte en el estándar por defecto.
• Los monocultivos fallan a la vez. Heartbleed, en 2014, afectó a la mayor parte de la web porque casi todos usaban OpenSSL, y de ahí nacieron LibreSSL y BoringSSL. Un fallo grave en V8 tendría un alcance parecido. La diversidad no evita los fallos, pero limita a cuántos afectan.

Lo que Deno ya consiguió

Hay una parte de la historia que me parece justo destacar: Deno nunca superó a Node, pero lo empujó. Muchas de las ideas con las que nació son hoy parte de Node: módulos ES, fetch(), soporte de ficheros .ts, un runner de tests integrado y un modelo de permisos.

Esto último lo tengo muy cerca. Este blog se compila con Hugo, y Hugo ejecuta Node con --permission, el modelo de permisos de Node que sigue la idea que popularizó Deno. Con Node 20 el build falla con bad option: --permission, y la configuración de Hugo necesita una lista de paquetes autorizados para cargar módulos nativos y lanzar procesos:

[security.node.permissions]
  allowaddons = ['tailwindcss', 'postcss']
  allowchildprocess = ['tailwindcss', 'postcss']

Que una herramienta como Hugo dé por hecho que el código JavaScript se ejecuta con permisos limitados es, en buena parte, consecuencia de que Deno lo planteara en 2018.

Los forks

Deno sigue siendo código abierto y el propio anuncio invita a otros a continuarlo. Ya hay dos intentos:

• Ende publicó su primera versión a mediados de octubre. Se presenta como un runtime seguro para TypeScript, ha quitado la compatibilidad con Node y mantiene Deno como alias permanente de su objeto global, así que los proyectos existentes siguen funcionando.
• Dodo todavía no tiene versiones y hay que compilarlo desde el código fuente. Quieren simplificar la estructura del proyecto, porque ahora el núcleo de Deno está repartido en varios repositorios y cada cambio exige publicar varios paquetes, lo que complica mucho las contribuciones externas.

Como apunta RedMonk, muestran a la vez las ganas de la comunidad y el riesgo: mantener un runtime de JavaScript es mucho trabajo, y Linux tiene muchas empresas financiando su núcleo, algo que a estos proyectos les falta.

Lo que me llevo

Hace poco más de un año escribía con ilusión sobre Deno 2.4 y el regreso de deno bundle, y me da pena ver cómo termina el runtime. Entiendo la decisión: una empresa con capital riesgo tiene que acabar dando un retorno, y ser comprada es uno de los finales probables.

Para quien tenga proyectos en Deno, hay un año de margen con parches de seguridad y JSR sigue en pie, así que no hay prisa, pero sí conviene decidir a dónde ir. Y para todos, la lección práctica que saco es apoyarse todo lo posible en las APIs estándar, fetch, Request, Response, Web Streams o Web Crypto, que funcionan igual en Node, Bun, Deno y Workers. Es lo que más facilita cambiar de runtime cuando uno desaparece.

Me quedo con la frase de James Snell, de Cloudflare y del comité técnico de Node, que recoge el artículo: no tener elección nunca es bueno. Hay que tenerlo en cuenta al leerlo, porque el propio RedMonk avisa de que Cloudflare, Microsoft y Google son clientes suyos, pero la idea de fondo me parece correcta: la web mejoró cuando hubo varios navegadores compitiendo, y el servidor necesita lo mismo.

Fuente: The Web Can’t Afford a JavaScript Runtime Monoculture, Kate Holterhoff, RedMonk, y Deno is joining Cloudflare, Ryan Dahl.