Deno Desktop

Overview of Deno Desktop

• Provides a way to build desktop apps with Deno using web technologies (HTML/CSS/JS/TS).
• Supports multiple backends: system WebView (default in design), bundled Chromium via CEF, and a low-level “raw” backend aimed at custom rendering (e.g., WebGPU).
• Integrates with Deno’s existing features: compilation to single binaries, cross-compilation, Node compatibility, auto-updates, and the npm ecosystem.

Comparisons with Electron, Tauri, and Others

• Positioned as “like Tauri, but can also be like Electron”:
  • WebView backend for small binaries using the OS engine.
  • Optional CEF backend for consistent, modern rendering across platforms.
• Compared to Electron: easier setup, potential for smaller bundles, TS-first, Deno API instead of Node, and built-in tooling.
• Compared to Tauri: Tauri is Rust-based backend and system WebView only (CEF coming), while Deno Desktop is JS/TS-based and already ships CEF.
• Other alternatives mentioned: Wails (Go), Dioxus/Blitz (Rust, custom engine), Sciter, Java/Qt/GTK, WASM-based approaches (Jumpjet).

Binary Size, Performance, and WebViews vs CEF

• Some users report a “hello world” build at ~440 MB on Windows due to CEF; disappointment given expectations of sub-20 MB apps.
• Maintainers indicate WebView + compression can reach ~15 MB, but the default/backend behavior is currently confusing and docs need correction.
• System WebViews:
  • Pros: smaller binaries, reuse existing browser engine.
  • Cons: platform-specific bugs and age (especially WebKitGTK on Linux, older macOS Safari/WebView).
• CEF:
  • Pros: predictable, evergreen rendering and APIs across OSes.
  • Cons: large binaries; questions about shared runtime/versioning and whether it meaningfully avoids “Electron-per-app browser” duplication.

Native vs Web UI and UX Consistency

• Long, heated debate on whether “web UI slop” is acceptable versus native toolkits.
• Arguments for web UIs:
  • Cross-platform consistency across OSes.
  • Huge developer familiarity with HTML/CSS/JS.
  • Native toolkits are fragmented, inconsistent, or painful (Win toolkits churn, GTK vs Qt, SwiftUI issues, Linux diversity).
• Arguments for native UIs:
  • OS-level consistency and patterns aid usability, discoverability, and accessibility.
  • Many web/electron apps ignore platform conventions, produce “pixel soup,” and have weak a11y.
  • Some say users do complain about inconsistent behavior, even if they don’t use the term “native UI.”
• General sense that OSs themselves have grown less consistent, which weakens the “must look native” argument for many developers.

Security, Permissions, and IPC Model

• Questions about how Deno’s permission system applies to compiled desktop binaries.
  • Current docs: desktop apps don’t yet provide runtime permission prompts; permissions are baked in at compile time.
  • Some worry permission prompts would be misleading if you don’t control the bundled runtime.
• Suggestions: run downloaded apps via a trusted local Deno (deno run) or in containers/VMs if you care about enforcing permissions.
• IPC/architecture:
  • Backend and UI run in the same process (CEF) or a tightly coordinated process group (WebView), using in-process C ABI bindings rather than socket-based IPC.
  • This is seen as lower overhead than traditional Electron-style IPC; security implications are debated but not resolved in the thread.

Platform Support, Tooling, and Use Cases

• Currently canary-only (Deno v2.9); some users hit early bugs (blank windows) and were asked to file issues.
• Mobile (iOS/Android) support is “planned/being investigated” but not available; docs hint at future support.
• Use cases discussed: internal tools, kiosk apps, packaging web games for Steam/desktop, shipping Deno-based CLIs with optional GUIs.
• Some are enthusiastic about Deno overall (TS-first, integrated tooling, compilation, Node compat); others are weary of “yet another way to ship bloated JavaScript desktop apps.”