Electrobun: Cross-platform desktop applications written in TypeScript

Original Article ↗ Hacker News Discussion ↗

Architecture & Goals

  • Electrobun targets Electron/Tauri’s space:
    • Uses the system webview (like Tauri), not bundled Chromium (option to bundle Chromium is “coming soon”).
    • Bundles Bun instead of Node for the main process; TypeScript is used for both main and browser contexts.
    • Native bindings are in C/Objective‑C, wrapped by a Zig binary spawned by Bun; Zig is the actual native “main” process on macOS.
  • Additional features mentioned:
    • Custom encrypted RPC between Bun and browser; originally slower pipe-based RPC was replaced with a socket-based approach.
    • Custom protocol (views://) to load files from sandboxed locations.
    • Custom Zig-based bsdiff for very small update patches and a self-extracting, zstd-compressed installer.
    • Support for isolated embedded webviews (OOPIF-like) via a custom HTML element.

Platform Support & “Cross‑Platform” Claims

  • Current state: macOS arm64 only; Intel macOS, Windows, and Linux are on the roadmap for later versions.
  • Building is intended to remain Mac-only long-term, while produced apps should eventually run cross‑platform.
  • Some commenters argue “cross‑platform” marketing is premature or confusing; others note the site says it “aims to be” cross‑platform and is clearly early-stage.
  • Debate on choosing macOS vs Linux as the primary build platform:
    • Critics highlight limited access to Macs, weaker VM/CI story, and likely reduced adoption.
    • Defenders point out it’s a one-person project targeting their own daily OS; macOS-only is seen as acceptable at this stage.
    • CI discussion: macOS runners exist, but Linux is still seen as the de facto CI platform.

Performance, IPC, and Webview Choice

  • Concern: process isolation and IPC may hinder high-throughput use cases (e.g., video decoding) compared with shared memory.
  • Author reports major RPC speedups using encrypted sockets, but commenters note IPC will still be slower than shared memory for extreme workloads.
  • Many see this as acceptable for typical desktop UI apps.
  • Strong support for using system webviews to avoid Chromium bloat and security update burden.
  • Counterpoint: system webviews mean dealing with multiple rendering engines across OSes; some teams prefer a bundled Chromium for consistency.

Docs, UX, and Communication

  • Multiple comments criticize:
    • Lack of screenshots or ELI5-style overview, despite being a UI framework.
    • Typos and unclear messaging around compatibility.
  • Others argue screenshots can drift out of date, but many still see at least one or two example images as low-effort, high-value.

Comparisons & Alternatives

  • Repeated comparisons to:
    • Tauri (system webview + Rust backend).
    • Electron (bundled Chromium + Node).
    • Other webview-based frameworks (Neutralino, Electrino, DeskGap).
    • Native GUI stacks (Qt/QML, GTK, wxWidgets, FLTK, Slint).
  • Some argue native toolkits are better for truly lightweight apps; others claim modern UIs often push them to embed a webview anyway.

Security & Other Concerns

  • One commenter flags that docs encourage innerHTML usage without XSS warnings.
  • Response: frameworks can’t fully prevent XSS; developers must handle escaping.
  • Side notes:
    • Curiosity about which specific webview implementation is used on each OS (not fully answered).
    • Mixed anecdotal impressions of Bun’s raw JS performance versus Node.