Gerüchte über Denos Niedergang sind stark übertrieben

• Zuletzt gab es Kritik und Bedenken zu Deno Deploy, KV, Fresh sowie zum allgemeinen Momentum des Unternehmens und der Projekte
• Ein Teil der Kritik ist berechtigt, und wir haben die Verwirrung auch selbst vergrößert, indem wir über den Fortschritt nicht ausreichend offen kommuniziert haben. Viele dieser Gerüchte und Kritikpunkte sind jedoch unbegründete Spekulationen oder sachlich falsch
• Seit dem Release von Deno 2 (seit Oktober 2023) hat sich die Akzeptanz gemessen an den monatlich aktiven Nutzern mehr als verdoppelt
• Die starke Node-Kompatibilität von Deno 2 hat in der Praxis eine große Hürde beseitigt, und die Plattform ist schneller, leistungsfähiger und einfacher geworden

Veränderungen und Weiterentwicklung von Deno Deploy

• Eine der häufigsten Fragen betrifft die jüngste Reduzierung der verfügbaren Regionen bei Deno Deploy
• Hinter dieser Reduzierung stehen neben den Kosten auch Veränderungen bei den tatsächlichen Nutzungsmustern und Anforderungen
  • Für die meisten Apps sind nicht alle Regionen wichtig, sondern Geschwindigkeit, Debugging und Compliance in der Nähe der Daten
• Seit dem Start von Deploy hat sich die Zahl der Regionen von 25 auf 35 und inzwischen auf 6 verändert
• Viele Regionen wurden tatsächlich kaum genutzt; eine zu starke Verteilung führte vielmehr zu Leistungseinbußen wie Latenz- und Kapazitätsproblemen
• Man arbeitet daran, eine praktische „Edge“-Vision neu aufzubauen, die zu den Anforderungen der Nutzer passt
• Eine neue Version von Deploy ist in Entwicklung, und die Plattform entwickelt sich in Richtung Hosting kompletter Anwendungen
  • Geplant ist Unterstützung für Subprozesse, Hintergrundjobs, OpenTelemetry, Build-Pipelines, selbst gehostete Regionen usw.
• In Kürze sollen Funktionen kommen, mit denen Apps an Regionen gebunden oder in der eigenen Cloud ausgeführt werden können

Ausrichtung von KV (Key-Value-Store)

• Deno KV ist ein Store mit einfacher API, der keine Konfiguration erfordert, globale Konsistenz garantiert und Echtzeitfunktionen bietet
• Er eignet sich für Session-Daten, Feature Flags, kollaborative Zustände usw., ist jedoch nicht für allgemeine Datenbanken gedacht
• Für umfassendere Anforderungen an das Datenmanagement laufen zwei Initiativen
  • Stärkere Integration bestehender relationaler Datenbanken in Deno Deploy
  • Ein neues Projekt zur Vereinfachung der Verknüpfung von Compute und State (inspiriert von Cloudflare Durable Objects)
• Entsprechend dieser Ausrichtung bleibt KV in der Beta, und es werden weiterhin nur schwerwiegende Bugs und Sicherheitsprobleme adressiert
• Die zentrale oder weiterentwickelte Rolle in einer umfassenden State-Management-Lösung wird künftig voraussichtlich ein anderes Projekt übernehmen

Aktueller Stand des Fresh-Frameworks

• Fresh ist weiterhin die Grundlage aller internen Apps und Websites und wird aktiv gepflegt und verbessert
• Man ist sich der hohen Erwartungen an Fresh 2 und der langen Wartezeit bewusst
• Statt einer überstürzten Veröffentlichung hat die Verbesserung von Basisqualität und Struktur Priorität
• Siehe dazu den kürzlich veröffentlichten Blogbeitrag zu den detaillierten Verbesserungen
• Eine stabile Auslieferung von Fresh 2 ist noch in diesem Jahr geplant

Deno, eine Plattform über die Runtime hinaus

• Deno ist mehr als nur eine Runtime, nämlich eine vollständige JavaScript-Systemplattform
• Mit einem einzigen Toolset lassen sich schreiben, ausführen, testen, deployen und überwachen integriert erledigen
• Integration, Standardkonfigurationen, Flags und die Verbindungen zwischen Tools werden kontinuierlich verbessert
• Ziel ist nicht bloß funktionale Gleichwertigkeit, sondern der Aufbau eines integrierten Ökosystems
• Man will die grundlegende Qualität der JavaScript-Entwicklung verbessern und wagt dafür eine Ausweitung des Anspruchs

Ziel und Motivation dieser Plattform

• Skriptsprachen spielen eine unverzichtbare Rolle in der schnellen praktischen Entwicklung
• Für JavaScript sieht die Zukunft in Bezug auf Standardisierung, großes Ökosystem und allgemeine Skalierbarkeit noch heller aus
• Es braucht eine Plattform mit „Batteries included“, und Deno verfolgt genau das (mit Berechtigungsverwaltung, Webserver, Observability, Linting, Type Checking usw. ab Werk)
• Statt fragmentierter Werkzeuge bietet Deno eine vereinheitlichte Erfahrung

Zukunftspläne und stärkere Kommunikation

• Deno befindet sich nicht in einer Schrumpfungsphase, sondern in einer Phase der Expansion
• Geschwindigkeit, Kompatibilität und Reifegrad der Plattform werden kontinuierlich verbessert, und auch die unabhängige Governance von JSR wächst
• Parallel dazu laufen Community-Kooperationen wie TC39/WinterTC sowie verschiedene Aktivitäten für das JavaScript-Ökosystem
• Auf Basis der Erfahrungen mit Deploy und KV wird an nachhaltigen und verteilten neuen Produkten gearbeitet; weitere Neuigkeiten sollen bald folgen
• Um Kontroversen und Misstrauen zu verringern, soll die Kommunikation verbessert und das Vertrauen der Entwickler besonders wichtig genommen werden

[yangeok]

Ist Bun vielleicht besser als Deno?

[xguru]

Die Gerüchte über Deno im Niedergang sind stark übertrieben: Die weltweiten Regionen wurden auf 6 reduziert
Sieht so aus, als wäre das eine Reaktion auf diesen Beitrag.

Ich habe auch separat etwas dazu gepostet, warum sich das Fresh-Update verzögert: Fresh 2-Update von Denos Web-Framework

[GN⁺]

Hacker-News-Kommentar

• Es schien von Anfang an klar, dass die meisten Entwickler nicht nur einfache zustandslose Funktionen deployen, sondern in der Regel echte Anwendungen bauen, die wie Full-Stack-Apps mit Datenbanken kommunizieren. Dass man das erst jetzt erkannt hat, wirkt fast selbstverständlich.

• Es wird die Wahrnehmung geteilt, dass es zuletzt kritische Stimmen zu Deno, Deploy, KV, Fresh und dem allgemeinen Wachstumstrend gab. Zu der Kritik am Wachstum habe man keine besondere Erwähnung oder Antwort gesehen und frage sich, ob das Absicht war. Da gesagt wurde, ein Teil der Kritik sei berechtigt, hätte es das Vertrauen eher gestärkt, wenn offengelegt worden wäre, welche Kritikpunkte berechtigt sind und wie man sie lösen will. Wenn ein Unternehmen ehrlich auch seine Schwächen zugibt, ist das aus dieser Sicht eher ein positiver Faktor bei der Auswahl. Es wird die Erfahrung geteilt, dass einem transparente Vor- und Nachteile wie auf der Pro/Con-Seite von Migadu gefallen.

  • Die jüngste Aussage von Deno zum Wachstum war, dass sich die monatlich aktiven Nutzer seit dem Launch innerhalb von gut sechs Monaten mehr als verdoppelt hätten. Es wurde jedoch nicht offengelegt, worauf sich diese Verdopplung genau bezieht oder welche Zahlen gemeint sind. Anfangs wurde das Unternehmen noch positiv bewertet, getragen von vagen Erwartungen und Vertrauen in einen neuen Dienst. Inzwischen scheine aber Enttäuschung aus der Lücke zwischen unkonkreten Wachstumserwartungen ohne Zahlen oder Belege und der Realität zu entstehen.

• Der Grund für die anfänglichen Erwartungen an Deno war, dass es ohne Fixierung auf Kompatibilität mit dem Bestehenden mit geringer Komplexität sauber neu anfangen konnte. Im Vergleich zu Node gab es zwar neue Unannehmlichkeiten, aber sie wirkten verkraftbar. Dann begann man jedoch, sich statt auf eigene Lösungen immer stärker an Node-Kompatibilität zu klammern, und jetzt sei daraus eher eine doppelte Struktur geworden, die sich sogar komplexer als Node anfühlt. Natürlich sollten Node-Pakete in Deno funktionieren, aber wegen einiger nicht implementierter APIs oder Bugs gebe es viele Edge Cases, in denen das nicht klappt. Selbst das bevorzugte Test-Framework AVA werde weiterhin nicht unterstützt. Früher habe man die npm-Kompatibilitätsschicht ignoriert und nur Deno selbst genutzt, aber inzwischen werde das zunehmend lästig. Schon die Command-Line-Optionen seien in wenigen Jahren enorm komplex geworden, und da die meisten für die npm-Integration gedacht seien, seien sie für einen selbst nur unnötige Information. Das, was man sich bei der Node-Kompatibilität am meisten gewünscht habe, sei Unterstützung für ESLint-Konfigurationen im Deno-Linter gewesen, doch daran scheine kein Interesse zu bestehen. Trotzdem wünsche man sich, dass Deno erfolgreich ist, weil es Verbesserungen bei Node anstößt. Nur wirke die aktuelle Richtung von Deno nicht konsistent mit dem ursprünglichen Ziel.

  • Es wird gefragt, ob kürzlich geprüft wurde, ob AVA und ESLint-Konfigurationen inzwischen unterstützt werden. Laut offizieller Dokumentation werde AVA-Unterstützung erwähnt, und die meisten Deno-Entwickler nutzten wohl eher die eingebaute Testfunktion. In der offiziellen Dokumentation stehe außerdem, dass benutzerdefinierte Regeln, Plugins und Setups mit ESLint unterstützt werden. Nach etwa sechs Jahren mit Deno sei der Eindruck, dass die mitgelieferten Standardfunktionen ohne zusätzliches Test-/Lint-Setup zufriedenstellend seien.

• Es entsteht der Eindruck, dass Deno die Richtung verloren hat. Anfangs war die Positionierung simpel: eine sichere und schnelle JS/TS-Runtime, geschrieben in Rust. Jetzt seien im Dropdown „Products“ auf der Website mehrere Produkte unübersichtlich hinzugekommen. Es wirke, als habe man versucht, dem Weg von Vercel zu folgen, das nach NextJS auch eine Deploy-Plattform gebaut hat.

  • Es wird die Ansicht geäußert, dass diese Veränderung weniger an Deno selbst liege, sondern auch daran, dass sich die JavaScript- und Node-Community schneller weiterentwickelt und aufgeholt habe. Anfangs hätten sich die Innovationen von Deno besonders spannend angefühlt, doch weil sich auch JS/Node schnell verbessert habe, sei das Differenzierungsmerkmal kleiner geworden.

• Die Erwartungen an Deno seien ab dem Zeitpunkt verschwunden, als man mit der Node-Kompatibilität die ursprünglichen Versprechen aufgegeben habe. Der zentrale Reiz von Deno habe darin bestanden, unerwünschte Komplexität und Altlasten von Node zu entfernen. Jetzt bleibe gegenüber Node kaum mehr als ein paar kleine Unterschiede wie eingebautes TypeScript und Berechtigungen. Auch bun.sh biete Node-Kompatibilität. Es wird gefragt, ob jemand eine serverseitige TypeScript-Scripting-Engine kennt, die keine Node-Kompatibilität anstrebt.

  • npm-Kompatibilität sei eine zusätzliche Funktion, deshalb müsse man dadurch nicht unbedingt etwas verlieren. Man müsse Node-APIs nicht verwenden und könne stattdessen einfach die gewünschten Bibliotheken von jsr.io nutzen. Tatsächlich könne man in Deno weiterhin eine von Node unterschiedliche Developer Experience genießen. Allerdings wollten nicht viele eine vollständige „Reinheit“, daher sei es eher gut, dass man Popularität und Pragmatismus gewählt habe.

  • Es wird infrage gestellt, warum man überhaupt nach einer TypeScript-Runtime sucht, die keine Node-Kompatibilität anstrebt. Node habe zwar viele Probleme, sei aber trotzdem praktisch genug, um sich breit durchgesetzt zu haben. Um eine praktikable Alternative zu schaffen, brauche es entweder (1) so starke Vorteile, dass sich eine große Migration lohnt, oder (2) minimale Migrationskosten plus klare Verbesserungen bei Performance, Zuverlässigkeit oder Usability. Deno verfehle jedoch beides etwas. Es könne bestehenden Node-Code nicht ausführen, biete aber zugleich keine ausreichend revolutionären Vorteile und ziehe damit nur „Idealisten“ oder „Hobbyentwickler“ an.

  • Als TypeScript-Runtime ohne Fokus auf Node-Kompatibilität komme einem Cloudflare Workers workerd in den Sinn, allerdings sei das grundsätzlich keine allgemeine Backend-Runtime und habe praktisch kaum mitgelieferte Pakete oder eingebaute Funktionen.

  • Man selbst bevorzuge JSDoc. Das sei unabhängig von Node und biete ähnliche Vorteile ohne die Komplexität einer Compile-Chain.

  • Wenn man im Backend nicht an JS gebunden sei, sei es vernünftig, statt TypeScript lieber bessere Alternativen in Betracht zu ziehen. Wenn man den gesamten Stack kontrollieren könne, gebe es keinen besonderen Grund, bei einer Compile-to-JS-Sprache zu bleiben.

• Es besteht der Eindruck, dass der jüngste Artikel eine Reaktion auf den früheren Beitrag https://news.ycombinator.com/item?id=43863937 ist.

• Es ist zwar ein vom CEO geschriebener Beitrag, konzentriert sich aber eher auf die Rechtfertigung interner Entscheidungen als auf konkrete Kritik an Deno. Trotzdem entsteht der Eindruck, dass die Deno-Produktpalette innerhalb der Deno-Umgebung recht gut funktioniert.

  • Es wird erneut gefragt, welche Kritik an Deno denn konkret als ungelöst angesehen wird.

• Es gibt weiterhin kein wirkliches Vertrauen oder keine Überzeugung. Wie Deploy sich entwickeln wird, werde man wohl bald sehen, aber KV habe für neue Projekte überhaupt keinen Grund zur Nutzung, wenn über die Beta-Phase hinaus kein weiterer Ausbau vorgesehen ist. Fresh soll gegen Ende von Q3 als Alpha refaktoriert werden, war aber faktisch ein Framework, das nur die Grundlagen bot. Selbst die auffällige Struktur ohne Build/Kompilierung werde damit verschwinden. Die Runtime werde zwar weiterentwickelt, aber interessant sei, dass sich die Release Notes so stark auf Node-/NPM-Kompatibilität konzentrieren, obwohl man gleichzeitig erklärt, keine Feature-Gleichheit mit anderen Runtimes anzustreben.

  • Die Entscheidung, die kontinuierliche Weiterentwicklung von KV zu stoppen, sei wirklich sehr schlecht. Unternehmen nutzten KV nicht deshalb nicht, weil die Funktionen schlecht wären, sondern wegen des Beta-Labels. Man selbst habe Cloudflare Workers KV häufig verwendet und sich wenig für Durable Objects interessiert, daher sei Deno KV vielversprechend gewesen, müsse nun aber wohl aus den Überlegungen gestrichen werden. Der Eindruck, ein neues Produkt anzukündigen und es dann sofort liegen zu lassen, sehe auch strategisch sehr schlecht aus.

  • Es wird offen geschildert, dass man KV in Betracht gezogen hatte, dann aber wegen fehlender Perspektive nach Alternativen sucht.

• Es wird gefragt, ob die Aussage, dass die meisten Entwickler nicht einfache zustandslose Funktionen, sondern Full-Stack-Apps mit enger Datenbankanbindung deployen, tatsächlich für das gesamte Serverless-Lager gilt. Falls ja, stelle sich die Frage, ob das überhaupt der ursprünglichen Absicht der Serverless-Bewegung entspricht oder ob man es einfach wählt, um komplexe Infrastruktur wie Docker oder Kubernetes zu vermeiden.

  • Das Gefühl sei, dass viele Leute eine Art modernisiertes Heroku-Erlebnis wollen, also ein gemanagtes RDBMS und eine automatisch skalierbare Server-Flotte. Die meisten Unternehmen bräuchten schließlich keine extremen Größenordnungen.

• Es wird erklärt, dass man bei Deno Deploy häufig nach der Reduzierung der Zahl von Regionen gefragt werde. Deno erkläre die Optimierungsrichtung damit, dass die meisten Apps nicht überall auf der Welt laufen müssten, sondern vor allem schnell in Datennähe sein, leicht zu debuggen und nur mit lokalen Regulierungen kompatibel sein sollten. Man selbst habe Deno Deploy jedoch gerade deshalb nicht genutzt, weil die Standorte der Regionen in der Praxis nicht nah genug gewesen seien und Performance-Probleme befürchtet wurden. Da es bereits viele Optionen näher an Daten und Nutzern gibt und regulatorische Anforderungen in den meisten Fällen auf Länderebene ausreichen, wirke diese Optimierungsrichtung nicht überzeugend.