- Deno-Projekte, die aus Web-Apps und TypeScript-Code bestehen, lassen sich als plattformspezifische, weiterverteilbare Desktop-App-Binärdateien bündeln
- Das Ergebnis enthält den Anwendungscode, die Deno-Laufzeit und die Web-Rendering-Engine zusammen; die Funktion ist in Deno v2.9.0 enthalten, aber noch kein stabiles Release
- Das standardmäßige WebView-Backend nutzt das im Betriebssystem integrierte WebView und zielt auf kleine Binärdateien; wenn konsistentes Rendering nötig ist, kann das Chromium-(CEF)-Backend gewählt werden
- Next.js-, Astro-, Fresh-, Remix-, Nuxt-, SvelteKit-, SolidStart-, TanStack Start- und Vite-SSR-Projekte werden erkannt und der Server passend für den Release-Modus bzw. den Entwicklungsmodus mit
--hmr gestartet
- Für die Kommunikation zwischen Deno-Code und WebView werden statt socket-basierter IPC In-Process-Kanäle verwendet; auch Cross-Compilation und automatische Updates auf Basis von bsdiff gehören zum Umfang
Rolle und aktueller Status von deno desktop
deno desktop wandelt Deno-Projekte in selbstenthaltende Desktop-Anwendungen um
- Als Eingabe ist alles von einer einzelnen TypeScript-Datei bis zu einer Next.js-App möglich
- Die Ausgabe ist eine plattformspezifische, weiterverteilbare Binärdatei
- Die Binärdatei enthält Anwendungscode, Deno-Laufzeit und Web-Rendering-Engine
- Die Funktion ist in Deno v2.9.0 enthalten, aber noch kein stabiles Release
- Zum Testen muss derzeit ein
canary-Build mit deno upgrade canary installiert werden
- Befehle, Konfigurationsschlüssel und die TypeScript-API können sich bis zur Stabilisierung noch ändern
Backend-Auswahl und Ausführung von Webprojekten
- Webtechnologien werden als Desktop-UI-Toolkit genutzt, mit dem Ziel, die Trade-offs bestehender Tools für Desktop-Apps auf Basis des Web-Stacks zu verringern
- Tools wie Electron, Tauri und Electrobun können Trade-offs wie große Binärdateien, Lücken bei der Plattformunterstützung, fehlendes JavaScript-Ökosystem, fehlende integrierte Updates oder fehlende Framework-Integration haben
- Das standardmäßige WebView-Backend verwendet das WebView des Betriebssystems und zielt auf kleine Binärdateien ab
- Über Denos Node-Kompatibilitätsschicht kann das npm-Ökosystem genutzt werden
- Wenn auf macOS, Windows und Linux identisches Rendering erforderlich ist, kann das gebündelte Chromium, also das CEF-Backend, gewählt werden
- Die automatische Framework-Erkennung ermöglicht es, bestehende Webprojekte ohne Codeänderungen als Desktop-App auszuführen
- Dazu zählen Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR und weitere
- Im Release-Modus wird der Produktionsserver ausgeführt
- Mit
--hmr wird ein Entwicklungsserver mit Hot Reload gestartet
Laufzeitkommunikation, Build und Updates
- Für die Kommunikation zwischen Backend und UI werden In-Process-Kanäle verwendet
- Werte werden beim Überschreiten der Aufrufgrenze kodiert
- Zwischen Deno-Code und WebView gibt es keine Cross-Process-Roundtrips
- Auf einer Maschine kann für macOS, Windows und Linux crosskompiliert werden
- Backends werden nicht lokal gebaut, sondern bei Bedarf heruntergeladen
- Automatische Updates erfolgen über integrierte binäre Delta-Updates mit einem
latest.json-Manifest und bsdiff-Patches
- Die Laufzeit übernimmt Polling, Anwendung und Rollback bei fehlgeschlagenen Starts
Einfaches Beispiel und Aufbau der Dokumentation
- Eine Desktop-App aus nur einer Datei kann erstellt werden, indem man eine
main.ts anlegt, die mit Deno.serve() eine HTML-Antwort zurückgibt, und dann deno desktop main.ts ausführt
Deno.serve(() =>
new Response("Hello, desktop
", {
headers: { "content-type": "text/html" },
})
);
deno desktop main.ts
- Die kompilierte Binärdatei öffnet ein Fenster, das auf einen lokalen HTTP-Server zeigt, der an den
Deno.serve()-Handler gebunden ist
- Unter macOS/Linux wird sie mit
./main ausgeführt
- Unter Windows mit
.\\main.exe
Deno.serve() wird automatisch an die Adresse gebunden, zu der das WebView navigiert; Port oder Hostname müssen daher nicht übergeben werden- Die zugehörige Dokumentation ist in die Bereiche Konfiguration, Backends, HTTP-Serving, Frameworks, Fensterverwaltung, Bindings, Menüs, Tray und Dock, Dialoge, Benachrichtigungen, HMR, DevTools, automatische Updates, Fehlerberichterstattung, Deployment, Vergleich und CLI-Referenz gegliedert
Deno.BrowserWindow behandelt Fensterlebenszyklus, mehrere Fenster und EreignisseDeno.autoUpdate() behandelt Manifest, bsdiff und Rollbackbindings.() ist der Binding-Mechanismus, mit dem aus dem WebView Deno-Code aufgerufen wird
1 Kommentare
Hacker-News-Kommentare
Deno Desktop scheint einen ziemlich meinungsstarken Kompromiss festzulegen: „Standardmäßig klein, Node-Kompatibilität vollständig“
Ich habe das 5-zeilige Hello World aus dem Artikel mit
deno desktop index.tsausprobiert, und unter Windows 10 war das Ergebnis 442 MB großIch hatte erwartet, dass es kleiner als ein Electron-Build wäre, und war überrascht, dass es viel größer ausfiel;
libcef.dllwar 247 MB groß unddeno-test.dllmit dem Hello World darin 78 MBIch frage mich, ob ich etwas falsch gemacht habe
Deshalb hatte ich gehofft, dass durch Wiederverwendung einer OS-WebView o. Ä. eine Lösung mit unter 20 MB möglich wäre, aber über 400 MB wirkt schon etwas irreführend
Vielleicht habe ich etwas falsch konfiguriert; ich frage mich, ob man außer
deno desktop test.tsnoch etwas tun mussDer Teil „Wenn man statt eines separaten CEF-Bundles pro App eine gemeinsam genutzte CEF-Runtime verwaltet, kann sich die Binärgröße pro App auf wenige MB reduzieren, und das steht auf der Roadmap“ ist interessant
Ich kenne mich mit CEF nicht gut aus und frage mich, wie dann das Versionsmanagement funktioniert
Wenn verschiedene Apps am Ende unterschiedliche CEF-Versionen benötigen, landet man dann nicht doch wieder bei einem Modell wie Electron, in dem jede App ihren eigenen Browser mitbringt, oder bleibt der Vorteil einer geteilten Runtime auch dann erhalten?
https://docs.deno.com/runtime/desktop/comparison/
https://github.com/chromiumembedded/cef
Das Ergebnis war nicht besonders gut, aber ich weiß nicht, ob das an CEF selbst lag oder an anderen Komponenten bzw. Prozessen
https://www.riotgames.com/en/news/architecture-league-client...
Praktisch alle Electron-Apps auf dem Desktop verwenden faktisch unterschiedliche Chromium-Versionen, und manche bleiben wegen des Risikos von Brüchen bei Upgrades lange auf älteren Versionen
Unter Windows wäre das so etwas wie WebView2
Deno bleibt weiterhin beeindruckend
Es ist schon eine ganze Weile her, dass ich ein neues Projekt ohne Deno begonnen habe, und ich unterstütze das Deno-Ökosystem inzwischen voll und ganz statt Node.js
Ich weiß nicht, wie oft ich diese Funktion nutzen werde, aber es ist wirklich gut, diese Option zu haben
Beeindruckende Arbeit
Für Desktop-Apps mit Vibe-Coding könnte das ziemlich interessant sein
Werkzeuge wie Lovable, Bolt und v0 verwenden beim Erstellen von Web-Apps standardmäßig TypeScript, daher scheint das gut dazu zu passen
Für kleine Desktop-Apps habe ich bisher Go/Wails verwendet, statt Chromium und Node zu bündeln, und Electron hat seine Aufgabe zwar gut erfüllt, aber diese großen Bundles waren für mich immer ein deutlicher Abschreckungsfaktor
Ich habe mich gefragt, wie das mit dem Berechtigungssystem integriert wird, einem der größten Stärken von Deno
Gerade wenn man Agenten frei auf dem eigenen Gerät herumlaufen lässt, ist das wichtig
In der CLI-Referenz steht, dass „die beim Kompilieren gewährten Berechtigungen in die kompilierte Binärdatei eingebrannt werden“
Es wäre gut, wenn das so sichtbar gemacht würde, dass Nutzer erkennen und entscheiden können, welche Berechtigungen sie geben wollen
https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
Wenn dort Deno-Berechtigungsabfragen angezeigt würden, könnte das meiner Meinung nach eher irreführend sein, weil es keine Integritätsgarantie für diese Berechtigungen gäbe
Also eine Anwendung des Deno-Berechtigungssystems auf Desktop-Sandboxing, bei der für jeden Dateisystem- oder Netzwerkzugriff eine Berechtigungsabfrage erscheint
Eine kluge Funktion zum Veröffentlichen
Wenn man entscheidet, welche Plattform man verwenden soll, wäre das für mich definitiv etwas, das ernsthaft in Betracht käme
Mit kleiner Installationsgröße und Cross-Plattform wirkt es wie eine brauchbare Alternative zu Electron oder Tauri
Ich halte die Formulierung „Web-Technologien sind das weltweit bekannteste UI-Toolkit“ für nicht besonders passend.
Electron-Apps werden gerade deshalb oft kritisiert, weil sie dem Gegenteil eines UI-Toolkits ziemlich nahekommen.
Häufig folgen sie den UI-Mustern des Host-OS nicht richtig.
Web-Technologien sind einfach Web-Technologien; man kann damit zwar Buttons rendern, aber selbst bei einem ungestylten Button ist nicht garantiert, dass er wie ein natives OS-Element aussieht, und je nach Browser sieht er anders aus.
Das Ziel war nie einfach nur ein „UI-Toolkit“ oder „den UI-Mustern des Host-OS zu folgen“.
Chromium bringt extrem viele Funktionen mit, und Electron übernimmt diese Utilitys unverändert, was ein Vorteil ist.
Wer schon einmal mit Video gearbeitet hat, weiß, dass es ein echter Gamechanger ist, in einer Desktop-App die vollen Fähigkeiten moderner Browser nutzen zu können.
Nicht nur Videowiedergabe, sondern auch Transcoding mit allem, was modernes Web und WebCodecs ermöglichen, selbst zu implementieren, ist ein riesiger Aufwand – erst recht für eine Desktop-App, die unter Windows/macOS/Linux laufen soll.
Ich habe eine App mit Electron in wenigen Dutzend Stunden gebaut; auf anderem Weg hätte das wohl viele Dutzend Tage gedauert, und selbst mit AI wäre es ohne Video-Expertise schwierig gewesen.
Es wurde nie behauptet, die UI sei „nativ“.
Die native UI unter Linux sah für mich schon immer ziemlich hässlich aus, und ich hatte stets das Gefühl, dass ein gut gemachtes HTML+CSS-Layout viel besser ist.
Meiner Erfahrung nach wird Electron vor allem dafür kritisiert, aufgebläht und langsam zu sein; dass es nicht nativ ist, wird von den Leuten eher noch zusätzlich angeführt.
Ich wollte schon lange Layouts mit HTML+CSS verwenden, aber ohne dafür eine JavaScript-Runtime zu brauchen, also mit direkter Browser-Integration.
Ich weiß nicht, wie leichtgewichtig Servo ist, aber ich hoffe, dass so eine Idee irgendwann Realität wird.
Als Nutzer bin ich sehr zufrieden, auch wenn grundlegende Funktionen wie Accessibility noch fehlen, aber ich denke, das wird bald umgesetzt.
Aus Entwicklersicht ist mir abgesehen von Rust nicht ganz klar, wo die Einstiegshürde liegen soll, und gleichzeitig ist Rust auch das Alleinstellungsmerkmal.
Das war vielleicht vor etwa 25 Jahren ein Thema, und seit selbst Microsoft aufgehört hat, sich darum zu kümmern, ist es den meisten Leuten egal.
Ich will nicht, dass meine App auf verschiedenen Betriebssystemen unterschiedlich aussieht.
Ich habe nicht die Ressourcen, um auf allen Geräten zu testen, und dass ein Screen, den ich auf einem System getestet habe, auf einem anderen genauso aussieht, ist ein enormer Vorteil.
Ich freue mich, dass es in diesem Bereich Konkurrenz gibt.
Gerade bei Deno gefällt mir, dass es im Gegensatz zur aktuellen Node-Implementierung nicht nur Typen entfernt, sondern echtes TypeScript direkt ausführen kann.
Allerdings dürfte das Tauri ziemlich viel Markt abnehmen.
Warum sollte man jetzt noch Tauri verwenden?
Bei den meisten Internetverbindungen bedeuten 150 MB mehr Bundle-Größe nur 1 bis 10 Sekunden zusätzliche Download-Zeit, dafür bekommt man aber eine zuverlässige Rendering-Engine.
Für Type-Checking muss man entweder
deno run --checkverwenden oder den separaten Unterbefehldeno checkausführen.Während der Entwicklung ist das normalerweise kein großes Problem, weil die IDE Type-Checking und Linting meist automatisch übernimmt.
Eigentlich muss man nicht einmal JavaScript verwenden.
Und wir haben schon gesehen, wie mehrere Startup-Frameworks für Entwickler wie Astro, Nuxt, UV, Bun und Vite übernommen wurden.
Für Software, die über Jahre hinweg gepflegt und unterstützt werden muss, schafft so ein Trend nicht gerade Vertrauen.
Verwenden Deno Desktop und Tauri nicht beide System-Webviews?
Warum sollte man das hier nutzen, aber nicht Electron?
Von den Materialien, die Deno veröffentlicht hat, fand ich den Vergleichsabschnitt am besten.
In der letzten Zeile steht bei der iOS/Android-Unterstützung für Electron „no“ und für Deno „not yet“ – wenn sie das tatsächlich hinbekommen, wäre das deutlich größer.
Das scheint wirklich gut dafür zu sein, Webspiele als Steam-App oder als App für Online-Käufe zu vertreiben.
Ich denke, ich werde es ausprobieren.