Choosing a desktop framework

First, credit where it's due. Electron proved that web developers could ship serious desktop software — VS Code, Slack, Figma's desktop shell, and thousands of other apps exist because of it. Tauri did the hard work of showing the same model could be dramatically lighter. Every framework on this page made real engineering trade-offs to solve real problems, and Glyx builds on lessons all of them paid for.

Rendering model

This is the most fundamental difference between the frameworks.

Electron and Electrobun bundle or use a browser engine (Chromium or WebKit). Your UI is HTML and CSS rendered by the browser. All web APIs work. All browser quirks apply.

Tauri uses the OS WebView — WKWebView on macOS, WebView2 on Windows, WebKitGTK on Linux. Smallest binary size (no bundled browser), but rendering consistency varies by platform. What looks right on macOS may look different on Windows.

Glyx uses purpose-built native 2D renderers — no browser lineage, no HTML, no DOM. UI components are native element structs rendered directly, not markup. The default 2D backend (TinySkia) is a pure CPU rasterizer with no GPU device at all — measured flat at ~27–40 MB RSS, idle and under sustained interaction load, with no browser-engine memory floor. A GPU-compute backend (Vello) is available for scenes that are genuinely GPU-throughput-bound (dense paths/text, large canvases); an experimental Windows-only backend (Direct2D) trades Vello's GPU-parallel throughput for OS-managed memory behavior instead. See Renderer & Engine Selection for the full picture and real numbers — the honest version is more interesting than a single flat "it's GPU-accelerated" claim.

The Glyx trade-off: you can't use HTML/CSS or browser-dependent libraries. The gain: a real choice between flat, low memory (the default) and GPU throughput (opt-in), plus fast startup and a small binary.

3D is handled separately from whichever 2D backend is active: Canvas3D always renders through its own wgpu device, independent of the 2D choice. With Vello as the 2D backend, that device is already resident and 3D content composites into the same frame directly. With TinySkia (the default), no wgpu device exists until a Canvas3D node actually appears — it's lazily created on first use and released again after a period of 3D inactivity, so 2D-only screens never pay the 3D GPU cost. In a WebView-based framework, 3D means WebGL/WebGPU running inside a browser compositor with its own context boundary; here it's a direct native path either way, just with different device-lifecycle behavior depending on the 2D backend.

Developer experience

Electron

The most mature ecosystem, refined over a decade of production use. Any web library works, the tooling is excellent, and the docs are battle-tested. The main/renderer process split requires IPC for native API access, which adds boilerplate — a deliberate security boundary, not an accident. Cold startup is the slowest of the group at 600–800ms, the cost of initializing a full browser engine.

Best for: apps that need to reuse web code directly, large teams where every hire knows web development, apps that use complex web-only libraries (rich text editors, maps, etc.).

Tauri

Excellent binary size (~6MB). The Rust backend is required for native functionality, which is a barrier for teams without Rust experience. The WebView rendering inconsistency is a real issue for pixel-perfect UIs — test on all three platforms.

Best for: security-conscious apps, apps where binary size matters (enterprise deployments), teams comfortable with Rust.

Electrobun

Uses Bun as the JavaScript runtime instead of Node.js. Faster than Electron but in the same architectural category (WebView-based). Early stage.

Best for: teams coming from Electron who want the same model with better performance.

Glyx

No browser engine, no Rust required. The rendering model is different from web — you write React components with a React Native-like style API, rendered natively (CPU by default, GPU where it counts). Libraries that depend on the DOM won't work. The capability system is an explicit trade-off: more secure by default, slightly more configuration.

Best for: apps built from scratch that want maximum performance and minimum size, teams comfortable with JavaScript and React Native-style development, apps where startup time matters.

Ecosystem comparison

¹ <WebView> embeds the real OS browser control (WebView2/WKWebView/WebKitGTK — the same engines Tauri uses). It's optional, and using it comes with a real cost: while it's open, that window pays the same per-platform rendering differences and extra process memory that the rest of this page credits Glyx for avoiding. It exists for cases that genuinely need a browser (PDF rendering, maps, a full rich-text editor) — reach for it only when nothing else fits, not as a default. See WebView & Browser Embedding.

The honest answer

Use Electron if you have a large existing web codebase to port, need browser-only libraries, or your team is entirely web-focused and startup time isn't a concern.

Use Tauri if binary size is the top priority and you have Rust expertise, or you're willing to learn it.

Use Glyx if you're building from scratch, want the best startup time and smallest binary without Rust, and your UI can be built with React + the Glyx component set.

Glyx is pre-release. If you need stability guarantees today, Tauri or Electron are safer choices — they earned that stability the hard way. If you're building something new and the numbers above matter to your users, Glyx is worth evaluating.