Das serverseitige JavaScript hat sich am Freitag deutlich konsolidiert. Ryan Dahl — Schöpfer von Node.js und danach von Deno — kündigte an, dass das gesamte Deno-Team zu Cloudflare wechselt und dass Denos eigene Runtime heruntergefahren wird.

Der Plan, gleichzeitig im Deno- und im Cloudflare-Blog veröffentlicht, ist konkret: Die Deno-Runtime erhält noch ein Jahr monatlicher Releases mit Bugfixes und Sicherheitsupdates; danach beendet Deno Land die Entwicklung der Runtime. Der Code bleibt Open Source, und das Team lädt ausdrücklich andere ein, ihn fortzuführen. Der gehostete Dienst Deno Deploy läuft noch sechs Monate und wird dann abgeschaltet; zahlende Kunden erhalten Migrationshilfe beim Umzug zu Cloudflare Workers. JSR, Denos TypeScript-first-Paketregistry, bleibt bestehen — ihre Infrastruktur zieht zu Cloudflare. Die Unterstützung für rusty_v8 läuft weiter und soll langfristig in workerd integriert werden.

Was Cloudflare eigentlich übernimmt, ist eine Notausstiegsluke. workerd, die Workers-Runtime, ist seit Jahren Open Source, doch Workers-Erfinder Kenton Varda räumt im gemeinsamen Beitrag ein, dass die Durable-Objects-Unterstützung dort nur eininstanzig funktionierte: gut genug für lokale Tests, unbrauchbar für den Produktivbetrieb. Cloudflares echtes Durable-Object-Routing wurde für Hunderte Standorte gebaut und hängt von Diensten ab, die kein Selbsthoster nachbauen kann.

Die fehlende Hälfte kam von Deno. celld, eine in Rust geschriebene Implementierung des Workers-Programmiermodells, die Dahl in diesem Jahr baute, reduziert eine verteilte Anwendung auf viele celld-Instanzen und einen einzigen Object-Storage-Bucket. Cloudflare und Dahl führen cellds Ideen nun in workerd zusammen, angeführt von Dahl und Bert Belder. Varda will damit eine Instanz von Cloudflare OS zu Hause betreiben.

Finanzielle Konditionen wurden nicht genannt. Für Entwickler bleibt konkret: rund ein Jahr Laufzeit für die Deno-Runtime, eine Sechs-Monats-Uhr für Deno Deploy und ein Workers-Programmiermodell, das womöglich endlich auf eigener Hardware läuft. Dahl rahmt den Schritt auch KI-seitig: Durable Objects, argumentiert er, passten natürlicherweise zu Agent-Harnessen, weil sie günstige serverlose Ausführung, persistenten Zustand, WebSockets und eine schlichte JavaScript-Schnittstelle bündeln.