Denos Niedergang: Globale Regionen auf 6 reduziert

• Das globale Edge-Hosting von Deno Deploy ist von 35 Regionen auf derzeit nur noch 6 geschrumpft, wodurch der Anspruch auf „weltweite Skalierbarkeit“ faktisch entwertet wird
• Wichtige Regionen wie Tokio, Frankfurt und Sydney wurden gestrichen, wodurch sich die Latenz für Nutzer deutlich erhöht
• Auch andere zentrale Projekte wie das Fresh-Framework, Deno KV und JSR befinden sich bei Updates in einer Stagnation oder sind faktisch eingestellt
• Deno ist keine innovative JavaScript-Plattform mehr, sondern beschränkt sich auf Node.js-Kompatibilität und darauf, hinterherzulaufen
• Der Autor äußert Enttäuschung darüber, entgegen den anfänglichen Erwartungen von Deno enttäuscht worden zu sein, und zeigt neue Erwartungen an Bun

---

Schrumpfung der Regionen bei Deno Deploy

• Deno Deploy betrieb einst 35 Regionen, doch Stand Januar 2025 sind nur noch 6 Regionen übrig
  • Verbleibende Regionen: Singapur, London, Frankfurt, São Paulo, North Virginia, Kalifornien
• Mit der Schließung der Region Tokio wird ganz Ostasien nur noch von Singapur aus bedient, was zu langsameren Antwortzeiten führt
• In der offiziellen Dokumentation wurde die Formulierung „weitere Regionen werden hinzugefügt“ in „spiegelt die aktuelle Liste wider“ geändert, ein Signal für den Rückzug von Expansionsplänen

Zweifel am Anspruch des Edge-Hostings

• Deno betont „Edge Computing“ und „globale Services mit niedriger Latenz“, doch der tatsächliche Rückgang der Regionen zeigt eine deutliche Diskrepanz zur Realität
• Konkurrenten wie Cloudflare betreiben Infrastruktur in 335 Städten in 125 Ländern, Bunny an 119 Standorten in 77 Ländern
• Netlify nutzt zwar die Deno-Runtime, stellt ein leistungsfähiges Edge-Netzwerk aber nur in individuellen Tarifen bereit

Andere Produktlinien von Deno: Stagnation und Verwirrung

• Für das Web-Framework Fresh gab es seit Oktober 2024 kein Release mehr, auch die Commit-Aktivität ist stark zurückgegangen
• Deno KV ist faktisch im Wartemodus, die letzte offizielle Veröffentlichung stammt aus Dezember 2023
• JSR (JavaScript Registry) wird wegen eines verwirrenden Packaging-Systems und fehlender klarer Philosophie kritisiert
• Die Deno-Runtime selbst ist vor allem damit beschäftigt, die Node.js-Kompatibilität aufrechtzuerhalten, Innovation ist kaum noch erkennbar
  • Das markanteste Feature von Deno 2.2 ist die Einführung von Nutzer-Telemetrie, die Reaktion der Nutzer fiel kühl aus

Enttäuschung in der Community und Suche nach Alternativen

• Der Autor sagt, er habe stark in Deno investiert und sei enttäuscht worden, und beschreibt es als „Rug Pull“
• Deno, einst als Alternative zum frühen Node.js gedacht, hat heute eine unklare Richtung und kaum noch Differenzierungsmerkmale
• Aktuell richtet sich das Interesse auf Bun, verbunden mit der Hoffnung auf eine neue Herausforderung

Fazit

• Deno befindet sich derzeit bei Regionsgröße, Produkt-Updates und technischer Ausrichtung gleichermaßen in einem Zustand von Rückzug und Stagnation
• Marketingbegriffe wie „weltweite Skalierbarkeit und Edge-Hosting“ wirken in der Praxis übertrieben oder beinahe irreführend
• Ohne die Wiederherstellung des Community-Vertrauens und echte Innovationen dürfte die Zukunft von Deno noch ungewisser werden

[tested]

bun arbeitet auch noch daran, die Node.js-Kompatibilität herzustellen.
> https://x.com/bunjavascript/status/1915633844155527208

[jeiea]

Ich nutze auch das kürzlich hinzugefügte opentelemetry und bin mit der Runtime zufrieden, aber da ich Deno Deploy nur kostenlos verwendet habe, wusste ich nicht, dass so etwas passiert.
Als Alternative auf bun zu schauen, finde ich persönlich schwer nachvollziehbar. Ich bräuchte mehr Informationen dazu, welche Art von kostenlosem Mittagessen man sich da erwartet.

[tujuc]

Bei Deno Deploy kann man das wohl noch so sehen ...
Beim Rest, hm ... da muss ich mir mehr Gedanken machen.

Sollte ich die als Service bereitgestellten Dinge vielleicht umziehen ...

[GN⁺]

Hacker-News-Kommentare

• Ich nutze Deno häufig. Es ist nützlich für Daten-ETL oder JSON-Transformationen.

  • Man kann ein neues Verzeichnis anlegen und ohne Konfiguration oder Vorbereitung direkt loslegen.
  • Viele Funktionen von Deno sind weiterhin nützlich, und auch zuletzt gab es aktive Updates.
  • Interne und Community-Bibliotheken wie Postgres und Redis werden ebenfalls aktiv aktualisiert.

• Ich würde Deno gern mögen, nutze wegen Kompatibilitätsproblemen aber am Ende Bun.

  • Bun bietet bei TypeScript-Arbeiten die bessere Erfahrung.
  • Einige Funktionen von Deno wirken unfertig.
  • Die Meinungen zu Fresh und dem K/V store kann ich nachvollziehen.
  • Bei der Wahl eines Backend-Frameworks ist es schwer, eine klare Antwort zu finden.
  • Die Schließung von Rechenzentren ist kein positives Zeichen.

• Sorge über Sicherheitsprobleme bei Deno.

  • Es gibt keine SBOM/SCA-Tools mit Unterstützung für Deno.lock.
  • Es ist schwer, CVE-Warnungen zu erhalten.
  • Es ist belastend, sich nur auf npm-kompatible Pakete verlassen zu müssen.

• Enttäuschung über Deno.

  • Ich hatte große Erwartungen an Deno, aber im Wettbewerb mit dem Konkurrenten Bun tut es sich schwer.
  • Die Reduzierung der Regionen könnte helfen, Kunden zu halten.

• In Rust implementierte Node-Module sind interessant.

  • Buns Zig-Implementierung ignoriert viele Edge Cases.

• Für Deno könnte es eine schwierige Zeit sein.

  • Es könnte Teil des Weges sein, den neue kreative Projekte durchlaufen.
  • Ryan Dahl arbeitet daran, Verbesserungen zu erreichen.

• Es ist fraglich, ob Deno jemals wirklich Aufmerksamkeit bekommen hat.

  • Es ist schwer, das als Abwärtstrend zu beschreiben.

• Die Kontroverse um Oracle und die JavaScript-Marke bei Deno.

  • Das wirkt wie eine Strategie, um Aufmerksamkeit zu erzeugen.
  • Das passt nicht dazu, wie der Markt Kaufentscheidungen trifft.

• Die Entscheidung von Supabase, von Deno abhängig zu sein, verursacht Unannehmlichkeiten für Entwickler.

  • Das Finden oder Laden benötigter Pakete kostet Zeit.
  • Deno 2.0 ist zwar mit Node kompatibel, aber sein Zweck ist unklar.