Web browser as GUI, with your preferred language in the backend

Original Article ↗ Hacker News Discussion ↗

Using the system’s existing web browser as a desktop GUI layer, rather than bundling a full runtime like Electron, promises smaller binaries and language-agnostic backends, as shown by the WebUI project. Commenters weigh this against significant trade-offs: reliance on whatever browser and engine version happens to be installed, performance and complexity issues with DOM‑based UIs, uneven native look‑and‑feel, and tricky aspects of browser detection, security, and long‑term compatibility. Many see the approach as attractive for simple, local-first apps, but less convincing for complex, high‑reliability software.

Project approach & capabilities

  • WebUI exposes the local browser as a GUI front-end, with backends in many languages (C, C++, Zig, Python, Go, etc.).
  • It runs an embedded HTTP server (civetweb) and communicates with the browser via WebSockets.
  • Positioned as lighter than Electron: ~200 KB library, no bundled browser, works with user-installed browsers (Chrome, Edge, Firefox, etc.).
  • Several commenters like the idea of leveraging the existing browser rather than shipping a runtime.

Comparisons: Electron, Tauri, platform webviews

  • Electron: bundles Chromium, gives full window control, consistent environment, but large binaries and resource-heavy. Seen as necessary for complex, feature‑rich apps using cutting‑edge Web APIs and needing guaranteed compatibility.
  • Tauri: uses system webview for smaller footprint; can in some cases use other runtimes; issues mentioned with Linux WebKit performance and serialization overhead between frontend and backend.
  • WebUI: unlike Tauri, talks to standalone browsers instead of OS webview; unlike Electron, doesn’t control the window, so customization and native integration are limited. Some see it as best suited for simpler tools and rapid development.

Performance & DOM / layout debate

  • One side argues the browser offers the most powerful layout and rendering system and that JS/DOM are “fast enough” for most apps; performance problems are blamed mainly on developer misuse and excessive abstraction.
  • The other side calls DOM/layout “glacially slow” compared to native or game engines, citing benchmarks where modest DOM workloads take tens of milliseconds, and pointing to expensive reflows, repainting, and animation limits.
  • There is extended disagreement over benchmark validity (micro vs. “real world”) and what “fast enough” means, but no consensus.

Native vs web GUIs & UX

  • Some argue native toolkits (WinForms, Qt, JavaFX, etc.) can be much snappier and simpler to develop with, especially for traditional desktop apps.
  • Others emphasize the browser’s cross‑platform reach, responsive layouts, and unified stack across desktop and mobile, accepting non‑native look and higher overhead as trade‑offs.
  • Several note that cross‑platform consistency and a single codebase often matter more to businesses than perfect native look‑and‑feel.

Browser dependency, compatibility & longevity

  • Supporters think browsers’ strong backward compatibility makes 5–10‑year viability realistic if apps stick to common features.
  • Skeptics worry about:
    • Reliance on “whatever browser is installed,” with unknown engine versions and missing features.
    • Fragility of discovering/launching browsers and needing kiosk mode flags.
    • Inability to target a fixed engine version, unlike Electron.

Security & architecture concerns

  • Questions raised about the security model (WebSocket + localhost), comparisons to other projects that use one‑time tokens, and the risk profile similar to past localhost-based issues (e.g., Zoom).
  • The project’s main site briefly had an expired TLS certificate, which some see as a bad look for tooling that underpins applications.

Miscellaneous discussion

  • Side debates on:
    • Zig syntax highlighting on GitHub and custom CSS fixes.
    • Similarity of the WebUI logo to the Waterfox logo and the risks of using icon marketplaces.
    • Alternative patterns like “just run a local webserver and open http://localhost:PORT”.
    • Comparisons to prior “browser-as-GUI” efforts (CLOG, GNOGA) and to Java applets/Flash era approaches.