Deno 2.8

• deno add und deno install behandeln paketnamen ohne Präfix in der CLI standardmäßig als npm:-Pakete, wodurch sie sich in bestehenden Node-Projekten leichter anstelle von npm install, yarn oder pnpm install verwenden lassen
• deno audit fix aktualisiert anfällige npm-Abhängigkeiten automatisch auf die nächstgelegene Patch-Version, die die Versionsbeschränkungen erfüllt, und zeigt Einträge, die einen Major-Version-Wechsel erfordern, separat an
• Mit den neuen Unterbefehlen deno ci, deno pack, deno transpile, deno why und deno bump-version werden reproduzierbare Installationen, die Erstellung von Tarballs für die npm-Veröffentlichung, TS→JS-Umwandlung, Nachverfolgung von Abhängigkeitspfaden und die Aktualisierung von Workspace-Versionen unterstützt
• Die Node.js-API-Kompatibilität stieg gemessen an der eigenen Node-Test-Suite von etwa 42 % in Deno 2.7 auf 76,4 % (3.405/4.457) in Deno 2.8, und viele node:-Module werden verzögert geladen, wodurch Programme schneller starten, die diese Module nicht verwenden
• Bei der Performance wurde die kalte npm-Installation gegenüber Deno 2.7.1 von 3.319 ms auf 906 ms verbessert und ist damit 3,66-mal schneller; node:buffer base64 ist 3,07-mal schneller, der node:http-Durchsatz 2,21-mal höher und node:crypto scrypt 2,12-mal schneller
• Als Kompatibilitätsänderung geben das globale setTimeout und setInterval nun statt Zahlen ein Node-Timeout-Objekt zurück; Code, der den Rückgabewert als number speicherte oder für Typprüfungen bzw. Arithmetik verwendete, muss etwa auf NodeJS.Timeout angepasst werden
• TypeScript 6.0.3 ist integriert, und deno check sowie LSP schließen standardmäßig lib.node ein, sodass Node-Typen wie NodeJS.*, Buffer und process ohne zusätzliche Konfiguration aufgelöst werden
• Beim Debugging zeigt der Network-Tab der Chrome DevTools den Deno-Datenverkehr von fetch(), node:http/node:https und WebSocket an, und mit --cpu-prof, --cpu-prof-flamegraph und --cpu-prof-md lassen sich V8-Profile, SVG-Flamegraphs und Markdown-Berichte erzeugen
• Für Paket- und Workspace-Verwaltung kommen das catalog:-Protokoll, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", min-release-age in .npmrc und --package-json hinzu, um die Versionseinheit in Monorepos, plattformübergreifende Installationen, Produktionsinstallationen und die Migration bestehender Node-Projekte zu unterstützen
• deno compile erkennt Next.js-, Astro-, Fresh-, Remix-, SvelteKit-, Nuxt-, SolidStart-, TanStack Start- und Vite-SSR-Projekte, führt deno task build aus und erzeugt passende Einstiegspunkte; außerdem wird beim Verarbeiten großer npm-Abhängigkeitsbäume der Fortschritt angezeigt
• Bei Tests und Web APIs wurden die Standardwerte von sanitizeOps und sanitizeResources in Deno.test() auf false geändert, ein testweises timeout und Coverage auf Funktionsebene hinzugefügt sowie OffscreenCanvas, übertragbare Headers, Request, Response und Streams, SHA3-Digest und P-521-Web-Crypto-Unterstützung ergänzt
• Bei Upgrades und der Runtime-Basis reduziert deno upgrade den Download wenn möglich per Delta-Update von etwa 48 MB auf 3–6 MB, mit deno upgrade pr <number> lassen sich PR-Builds installieren, und V8 wurde von 14.6 auf 14.9 angehoben

[GN⁺]

Hacker-News-Kommentare

• Deno ist dank seines standardmäßigen Berechtigungsmodells nützlich, in Rust geschrieben und unterstützt TypeScript nativ
  Ich bin nicht tief im Ökosystem von Webentwicklung/Node/Bun drin, aber ich habe Deno über mehrere Jahre hinweg zufrieden für kleine Services genutzt. Ich frage mich, warum Bun scheinbar so schnell wächst. Vielleicht wird es vor allem als Bundler verwendet und seltener als JavaScript-Laufzeit, ich weiß es nicht
  Allein das Berechtigungssystem macht Deno attraktiv, und ich verstehe nicht ganz, warum Leute von Node zu Bun wechseln, aber nicht zu Deno

  • Deno und Bun hatten beim Start ziemlich unterschiedliche Schwerpunkte. Deno war Ryans Versuch, vieles zu korrigieren, was aus seiner Sicht bei Node schiefgelaufen war, während Bun von Anfang an auf Node-Kompatibilität und das Ausführen populärer Frameworks wie Next.js fokussiert war
    Lange Zeit liefen viele Abhängigkeiten und Frameworks unter Deno nicht richtig, und anfangs gab es nicht einmal die Möglichkeit, Abhängigkeiten aus npm zu installieren. Wenn man sich die Angriffe auf die npm-Lieferkette anschaut, hatte Ryan mit seiner Einschätzung vielleicht recht
    Deshalb wirkte Bun wie ein besseres Node mit viel weniger Konfigurationsaufwand und mehr Komfortfunktionen, das einfach sofort funktioniert. Das Deno-Team scheint erkannt zu haben, dass man für Erfolg Node-Kompatibilität braucht, und hat sich in den letzten Jahren darauf konzentriert. Inzwischen halte ich Deno für Node-kompatibler als Bun
  • Wenn man ein kleines TypeScript-Side-Project startet, kann man einfach nur Bun verwenden, statt in einem Meer aus npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime unterzugehen
    Zur Einordnung: Nur einige davon sind Pokémon-Attacken, der Rest sind echte Tools aus dem JS/TS-Ökosystem
  • Ich nutze und mag beide. Bun kommt einem Drop-in-Ersatz für Node näher
    Wenn ich mich nicht mit Test-Setup, tsconfig oder ES-Modulen beschäftigen will, funktioniert es meistens einfach. Deno hat eine gute Standardbibliothek und hervorragende CLI-Unterstützung, und früher mochte ich auch deno deploy, aber inzwischen ist es ziemlich umständlich geworden
  • Ich bin hauptsächlich Backend-Entwickler, aber wenn ich in privaten Projekten ein wenig Frontend anfasse, wirkt Deno wie die vernünftigste Wahl
    Es arbeitet sich wirklich gut damit, und ich finde es schade, dass es sich unter JS-Leuten nicht stärker verbreitet hat
  • Ich habe Deno etwa ein Jahr lang genutzt und mochte es wegen der genannten Vorteile, aber es gab zu viele Kompatibilitätsprobleme mit Paketen wie Astro, Prisma und Vite
    Deshalb bin ich zu Bun gewechselt, und damit lief alles deutlich reibungsloser

• Ich frage mich, wie Deno derzeit eigentlich dasteht
  Node ist die stabile Lösung und wird auch in Zukunft bleiben. Man kann inzwischen auch TypeScript verwenden, und bald wird man Apps wohl sogar als einzelne ausführbare Datei bauen können, inklusive nativer Abhängigkeiten
  Bun ist verwirrend, aber schnell, und der Ansatz, alles in die Standardbibliothek aufzunehmen, ist interessant. Außerdem wurde es von Anthropic übernommen
  Deno hatte diese starke Geschichte mit Sandboxing und dem einfachen Einbinden von Drittanbieter-Abhängigkeiten, aber Sandboxing wirkt inzwischen ziemlich allgemein geworden, und ich bin nicht sicher, ob die Import-Methode am Ende wirklich so viel besser war als npm add

  • Deno hat vor etwa 2 Monaten ungefähr die Hälfte seiner Firma entlassen: https://news.ycombinator.com/item?id=47467746
  • Wer betrachtet eine Übernahme durch Anthropic denn als etwas Positives?
  • Damit das Ökosystem nicht stagniert, ist es gut, mehrere Optionen zu haben
  • Bereitstellung als einzelne ausführbare Datei ist schon jetzt möglich. Die CLI meines Produkts ist eine Node-Single-Executable-Anwendung
  • Ich wusste nicht, dass Builds als einzelne ausführbare Datei inklusive nativer Abhängigkeiten möglich werden. Das ist eine starke Funktion

• Deno ist großartig. Ich schreibe kleine und mittelgroße Webservices in Deno
  Es läuft wie ein Schweizer Uhrwerk, und die Projektphilosophie passt gut zum Unix-Geist
  Persönlich finde ich, dass die Leute hinter Deno etwas zu bescheiden sind. Selbst wenn dankbare Nutzer dem Projekt Spenden anbieten, lehnen sie höflich ab. Ich verstehe warum, aber langfristig könnte das unnötigen finanziellen Druck auf das Projekt erzeugen
  Eine Art monatliches „Bitte nehmt mein Geld“-Abo für Nutzer, die vom langfristigen Erfolg des Projekts abhängen, könnte ziemlich gut passen

  • Die Nutzung macht wirklich Freude. Es fühlt sich fast wie eine Mischung aus JavaScript und Go an
    Es ist schnell und flexibel, bietet ein etwas vernünftigeres Paketmanagement mit stärkeren Funktionen als andere JS/TS-Alternativen, ein besseres Sicherheitsmodell, eine bessere Standardbibliothek. Und es ist sehr schnell

• Für alle, denen der Name Deno nichts sagt: Deno ist eine JavaScript- und TypeScript-Laufzeit
  Es gibt einen Testbericht, der Deno 2.6 mit dem Konkurrenten Bun 1.3 und Node.js 25 vergleicht: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Es überrascht mich, dass Bun bei der Verarbeitung von Webanfragen so viel schneller ist. Im Artikel wird Zig als Faktor genannt, aber ich frage mich, ob feingranulare Speicherverwaltung allein wirklich mehr als den doppelten Vorteil gegenüber Node bringen kann
    Ähnlich dazu wird es nicht klar gesagt, aber Bun scheint mit warmem Paket-Cache gelaufen zu sein. Ich frage mich, ob die anderen Laufzeiten ebenfalls einen Cache hatten

• Der konstante Release-Rhythmus von Deno ist beeindruckend. Ich bin gespannt, welche Performance-Verbesserungen in dieser Version stecken

• Der neue Befehl deno pack ist eine gute Ergänzung für sicheres und einfaches Packaging
  Wer Node.js nutzt, kann etwas Ähnliches per Ein-Kommando-Lösung mit https://www.npmjs.com/package/ts-node-pack erreichen
  Da Node.js nun das Importieren von .ts-Modulen unterstützt, können mehr Repositories das nutzen, ohne einen Build-Schritt oder Build-Artefakte im Checkout zu benötigen

  • Beim Lesen dieses Blogposts musste ich sofort darüber nachdenken. deno pack könnte den bestehenden npm publish-Ablauf meines Open-Source-Pakets ersetzen und hilfreich sein, um meine Arbeit weiter Deno-first/Deno-zentriert auszurichten
    Andererseits wächst die TypeScript-Unterstützung in Node, daher wäre auch der Wechsel zu einem reinen TypeScript-npm-Paket ein winziges Signal an das Ökosystem
    Trotzdem freut es mich, dass JSR als vergleichsweise saubereres Ökosystem existiert
  • Das klingt ziemlich ähnlich wie das schon lange existierende DNT(https://github.com/denoland/dnt)
    Wenn es aber direkt in die Deno-CLI aufgenommen wird, steigt die Sichtbarkeit stark

• Wenn Deno etwas länger an seinem ursprünglichen Wertversprechen festgehalten hätte, wäre der Druck hin zu Node-Kompatibilität vielleicht teilweise durch KI-Agenten abgefedert worden
  Ein großer Teil dieses Drucks kommt nämlich von Vertrautheit. Wenn man nur weiß, wie man etwas mit express.js konfiguriert, hat man danach das Gefühl, dass jedes weitere Tool oder jede Laufzeit dieselbe Abstraktion für einen „reibungslosen“ Wechsel bereitstellen muss. Unabhängig davon, wie schlecht die erste Lösung ursprünglich war
  Heute kann man zusammen mit dem Produkt das nötige Technikpaket ausliefern und Entwickler so an neue Technologien heranführen; das ersetzt tatsächlich manchmal Dokumentation und ist oft ziemlich gut geeignet, bessere alternative Ansätze zu zeigen

  • Wenn ein JS/TS-SDK eines SaaS-Anbieters nicht ohne Änderungen unter Deno läuft, würde ich keine einzige Sekunde darauf verwenden, das zu beheben

• Nachdem ich Deno in mehreren Hobbyprojekten verwendet habe, bin ich überzeugt, dass Deno die Richtung ist, in die sich das JS-Ökosystem bewegen sollte
  Für den Arbeitseinsatz ist eine Empfehlung außerhalb bestimmter und meist enger Anwendungsfälle allerdings kompliziert. Irgendwann ändert ein Projekt aus geschäftlichen Gründen seine Richtung, und dann braucht man am Ende doch Node

• Seit der Veröffentlichung von Edge.js [1] ist es gut zu sehen, dass Deno Node.js-Kompatibilität ernster nimmt
  In nur etwa 2 Monaten ging es von etwas über 40 % auf ungefähr 75 %, also ist das, ob Zufall oder nicht, ein klarer Schritt in die richtige Richtung
  Gute Arbeit an das ganze Deno-Team
  [1] https://edgejs.org/

  • Wird dir Eigenwerbung nicht irgendwann langweilig?

• Ich verpacke die meisten Node-artigen Konventionen und nutze Deno als Laufzeit. Das funktioniert gut
  Wenn ein Projekt pures TypeScript ist, führe ich es einfach mit Deno aus. Die zusätzlichen Optionen für Sicherheit sind gut, und dass Installationsskripte standardmäßig deaktiviert sind, gefällt mir ebenfalls
  Wenn du Node direkt verwendest, solltest du damit aufhören. Selbst Bun ist meiner Meinung nach die bessere Wahl
  Für agentenbasierte Arbeit gibt es fast keinen Grund, etwas anderes als Rust und TypeScript zu verwenden. Man kann anderer Meinung sein, aber Typsicherheit, Speichersicherheit und ein großer Arbeitskorpus sind wichtig. Agenten kommen mit kniffligen Fehlern und eingebauten Mustern leichter zurecht. Für UI ist TypeScript am plausibelsten, weil es so viele Designbeispiele gibt