Deno Desktop

Original Article ↗ Hacker News Discussion ↗

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.”