Kommentar: Deno geht zu Cloudflare – gemessen an den eigenen Versprechen

Am 9. Oktober 2026 hat Cloudflare angekündigt, Deno zu übernehmen. Aus dem Projekt war längst ein Unternehmen mit Risikokapital geworden, und dieses Unternehmen wurde nun verkauft. Ich schreibe darüber nicht aus eigenem Schaden, denn wir selbst haben Deno nie eingesetzt und sind immer bei Node.js geblieben. Einige unserer Kundinnen und Kunden setzen Deno dagegen ein. Mich stört an der Übernahme allerdings weniger der Käufer als etwas anderes: der Bruch zwischen dem Anspruch, mit dem Deno angetreten ist, und diesem Verkauf.

Was übernommen wird und was endet

Zunächst zu den Fakten. Laut den Ankündigungen von Cloudflare und Deno wechselt das gesamte Deno-Team zu Cloudflare und arbeitet dort künftig an der Plattform Workers. Die Deno-Runtime erhält noch ein Jahr lang monatliche Releases mit Bugfixes und Sicherheitsupdates. Danach endet ihre Entwicklung durch das Team. Deno bleibt Open Source, und wer die Entwicklung weiterführen möchte, ist dazu ausdrücklich eingeladen.

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Deno Deploy, der Hosting-Dienst des Unternehmens, läuft noch sechs Monate und wird dann abgeschaltet. Zahlende Kundinnen und Kunden erhalten Unterstützung beim Umzug zu Cloudflare Workers. Die Paket-Registry JSR bleibt in Betrieb, ihre Infrastruktur zieht zu Cloudflare um. Ryan Dahl und Mitgründer Bert Belder sollen außerdem celld, ein Projekt von Deno für verteilte Anwendungen, mit workerd zusammenführen, der Runtime hinter Workers, damit sich Workers künftig auch selbst betreiben lässt.

In der Ankündigung von Deno steht zudem ein Dank:

„To everyone who contributed code, built businesses on Deno, reported problems, and trusted our direction: thank you.“

Dieser Satz wird später noch eine Rolle spielen.

Cloudflare mache ich dabei keinen Vorwurf. Das Unternehmen handelt folgerichtig. Es holt sich ein erfahrenes Team und eine Technologie, die zur eigenen Plattform passt. So arbeiten Unternehmen, und das ist ihr gutes Recht. Die Frage, die mich beschäftigt, richtet sich an die andere Seite.

Ein Anspruch in drei Akten

Der erste Akt begann, als Ryan Dahl, der Softwareentwickler hinter Deno, im Juni 2018 auf der JSConf EU seinen Vortrag „10 Things I Regret About Node.js“ hielt. Darin rechnete er mit Entscheidungen ab, die er bei Node.js getroffen hatte. Das waren die fehlende Sandbox, das Build-System, die package.json, das Verzeichnis node_modules und die zentrale Rolle von npm. Deno sollte es besser machen, sicher von Grund auf, mit TypeScript und ohne Abhängigkeit von einer zentralen Registry. Der Anspruch war von Beginn an groß, nämlich die Fehler zu korrigieren, die Node.js nicht mehr loswurde.

Ich hielt Deno damals vor allem für heiße Luft, und im Oktober 2024 habe ich rückblickend darüber geschrieben:

„Außerdem wirkte die ganze vorgeschobene Reue auf mich wie ein Vorwand, um im Hintergrund ein Unternehmen aufzubauen – was natürlich völlig legitim ist, aber für meinen Geschmack nicht transparent genug kommuniziert wurde.“

Dann kam Deno 2, und es überzeugte mich so sehr, dass ich den Beitrag mit „Danke, Deno 2!“ beendet und meinen Eindruck von damals beiseitegelegt habe.

Von diesen Idealen ist mit den Jahren einiges auf der Strecke geblieben. Deno 2 unterstützte npm und die package.json, also genau das, was 2018 noch als Fehler galt. Ich fand das damals richtig und habe geschrieben, Deno breche damit zwar mit vielen ehemaligen Idealen, werde dadurch aber erst massentauglich. Massentauglichkeit heißt allerdings auch, dass Menschen anfangen, auf eine Plattform zu bauen, und zwar nicht mehr nur für Experimente, sondern für Produkte.

Zurück zur Chronologie: Der zweite Akt folgte im März 2021 mit der Gründung der Deno Company. Dahl und Belder verkündeten 4,9 Millionen US-Dollar Startkapital und machten dabei Zusagen, die an Deutlichkeit nichts zu wünschen übrig ließen:

„We will ensure that issues are addressed, bugs are fixed, timely releases are made; we will ensure Deno is a platform others can build on with trust.“

Und weiter:

„Rest assured that Deno will remain MIT licensed.“

Auch das Verhältnis zwischen Unternehmen und Projekt beschrieb die Ankündigung klar:

„Our business will build on the open source project, not attempt to monetize it directly.“

Unter den kommerziellen Anwendungen, die das Unternehmen verfolgen wollte, nannte sie übrigens auch „Cloudflare Worker-style Serverless Functions“. Wer das heute liest, kommt um eine gewisse Ironie nicht herum.

Im Juni 2022 sammelte das Unternehmen in einer Series A, angeführt von Sequoia, weitere 21 Millionen US-Dollar ein, insgesamt waren es damit 26 Millionen. Das Geld sollte laut damaliger Berichterstattung unter anderem in den Ausbau von Deno Deploy fließen, also in genau den Dienst, der nun innerhalb weniger Monate abgeschaltet wird.

Der Kampf um JavaScript

Der dritte Akt reichte über Deno selbst hinaus. Im September 2024 machte Deno den Kampf gegen Oracles Marke JavaScript zur Unternehmenssache, zunächst mit einem offenen Brief auf javascript.tm, den mehr als 27.000 Entwicklerinnen und Entwickler unterzeichneten. Oracle hat die Marke mit der Übernahme von Sun geerbt. Wer das Wort für ein Produkt oder eine Konferenz verwendet, geht laut dem Brief ein rechtliches Risiko ein, und deshalb ist mitunter vom sperrigen ECMAScript die Rede, wo eigentlich alle JavaScript meinen.

Im November 2024 folgte der Antrag auf Löschung der Marke beim US-amerikanischen Patent- und Markenamt USPTO. In der Begründung hieß es, der Begriff sei generisch, Oracle nutze die Marke nicht, und bei ihrer letzten Verlängerung habe Oracle getäuscht. Als Nutzungsnachweis hatte Oracle 2019 ausgerechnet Screenshots der Website von Node.js eingereicht. Den Vorwurf der Täuschung wies das zuständige Gremium im Juni 2025 als unzureichend dargelegt ab, die beiden anderen Gründe blieben.

Im September 2025 rief Deno schließlich zu Spenden für das Verfahren auf. 200.000 US-Dollar sollten die Beweisphase finanzieren, etwa Umfragen und Sachverständige. Der Aufruf hielt ausdrücklich fest:

„None of the funds will go to Deno.“

Was übrig bleibe, gehe an die OpenJS Foundation.

Damit trat Deno nicht mehr nur als Anbieter einer Runtime auf, sondern als selbst ernannter Anwalt der gesamten JavaScript-Community. Diese Community hat mit Unterschriften, Aufmerksamkeit und Geld geantwortet. Umso auffälliger ist, dass weder die Ankündigung von Cloudflare noch die von Deno das Verfahren mit einem einzigen Wort erwähnt. Antragsteller war Deno Land, das Unternehmen hinter Deno, und das gehört nun zu Cloudflare. Was aus dem Verfahren wird, ist öffentlich nicht bekannt. Ende August hatte Oracle mit Zustimmung von Deno beantragt, es wegen Vergleichsverhandlungen auszusetzen.

Damit kein falscher Eindruck entsteht: Ich unterstelle niemandem, das gespendete Geld falsch verwendet zu haben. Es war zweckgebunden, und der Aufruf hat Deno als Empfänger ausdrücklich ausgeschlossen. Mir geht es um etwas anderes, nämlich um die Rolle, die Deno damit eingenommen hat, und um die Frage, wer diese Rolle jetzt noch ausfüllt.

Eine Registry, die keine Deno-Sache sein sollte

Ähnlich verhält es sich mit JSR. 2018 hatte Dahl unter anderem kritisiert, dass das gesamte Ökosystem von Node.js an npm hänge, also an einem zentralen Anbieter. Seit 2020 gehört npm zu GitHub und damit zu Microsoft. Deno setzte zunächst auf Importe per URL, ganz ohne zentrale Registry. 2024 kam mit JSR dann doch eine eigene Paket-Registry hinzu, die nach dem Willen ihrer Macher aber gerade keine Sache eines einzelnen Unternehmens sein sollte.

Im Februar 2025 gab sich JSR einen unabhängigen Vorstand, und die Ankündigung formulierte den Anspruch unmissverständlich:

„Although the Deno team built JSR, the open source registry is intended not to be a Deno project, but rather an openly governed community service that benefits the greater JavaScript and TypeScript ecosystem.“

Eines der Hauptziele des Vorstands sollte sein, JSR eine rechtliche Heimat zu geben, etwa in einer bestehenden Stiftung.

Nun zieht die Infrastruktur von JSR zu Cloudflare um. Ob der Vorstand weiter besteht und ob es bei den Plänen für eine Stiftung bleibt, sagt die Ankündigung nicht. Die Registry, die ausdrücklich kein Projekt eines einzelnen Unternehmens sein sollte, läuft künftig auf der Infrastruktur eines Konzerns.