What is Glyx?

Glyx is a desktop application framework that lets you build native, cross-platform apps in React and TypeScript, rendered directly by the framework — no embedded browser engine, no DOM, no HTML/CSS layout pipeline in between.

The problem

Electron and Tauri both solved a real problem: they let web developers ship desktop apps using skills and tooling they already had. That's a genuine, valuable trade — and the ecosystem, docs, and maturity both projects have built up reflect it.

• Electron bundles a full Chromium instance per app. That buys complete web-platform compatibility, at the cost of shipping (and running) an entire browser alongside your app.
• Tauri uses the OS's own WebView (WebView2, WKWebView, WebKitGTK) instead of bundling Chromium — a real binary-size win — but your UI still renders through that WebView's DOM/CSS layout engine and a JS↔native bridge, with whatever per-platform WebView quirks and version drift that implies.
• Native (Swift/C++/C#) avoids both costs entirely, at the cost of writing and maintaining separate UI code per platform, in a language most web teams don't already know.

The Glyx approach

Glyx renders your React tree directly — no WebView, no DOM, no HTML/CSS engine sitting between your components and the pixels on screen:

• No WebView, on any platform. Your <View>/<Text>/<Image> tree is laid out with Taffy (a Rust flexbox engine) and drawn by one of Glyx's own 2D renderers.
• Real measured memory, not marketing numbers. TinySkia (the default backend on integrated/no GPU, which covers most laptops) held flat ~27–40 MB RSS on a real app, both idle and under a sustained interaction stress test — no WebView process, no browser-engine memory floor.
• A real desktop binary, not a browser distribution. The V8 engine path produces a lean runner around ~58–60 MB; the optional QuickJS engine (same binding surface, JS-engine swap only) brings that down to ~19.6 MB, for apps that don't need V8's JIT.
• Startup measured in tens of milliseconds, not seconds. A V8 snapshot restores in ~50ms plus ~200ms app eval — no browser-engine cold start.

Architecture, briefly

• Layout: Taffy (opens in a new tab), a Rust flexbox implementation — the same box model web developers already know, no DOM underneath it.
• 2D rendering: TinySkia (CPU, default), Vello (GPU compute, for genuinely GPU-throughput-bound 2D scenes), or Direct2D (Windows, experimental) — see Renderer & Engine Selection for when each applies and the real memory numbers behind the choice.
• 3D: Canvas3D/@glyx-dev/three, always GPU-accelerated via wgpu directly, independent of which 2D backend is active.
• JS engine: V8 (default, JIT, snapshot fast-start) or QuickJS (opt-in, no JIT, smaller binary) — mutually exclusive at compile time, not a runtime toggle. See JS Engine Selection.
• React bridge: a custom react-reconciler host config drives the native layout/render tree directly — the same React mental model (components, hooks, state), a different target than the DOM.
• Capabilities: filesystem, database, dialogs, notifications, and other OS access are explicit, scoped grants in glyx.config — not ambient Node.js/Electron-style access from every script.

When to use Glyx

• You're building a desktop app in React and want native rendering performance/memory characteristics without giving up React's component model.
• Your app is UI-and-data-driven (productivity tools, dashboards, internal tools, settings/utility apps) rather than needing arbitrary web-platform compatibility (a specific CSS feature, an existing complex web app you're porting as-is, heavy reliance on browser-only APIs).
• You care about idle memory footprint and cold-start time as real product requirements, not just nice-to-haves.
• You want an escape hatch to full native rendering quality (Vello) or embedded web content (WebView/@glyx-dev/webview, when you do need a real browser engine for a specific surface) without committing your whole app to either.

If your app's value is largely "it's a website, packaged" — reusing an existing complex web app as-is, needing broad CSS/web-API coverage, or leaning heavily on the web ecosystem's UI libraries — Electron or Tauri are likely still the better fit; that's exactly the case they're built for.

Next steps

• Installation — install options and platform notes
• Your First App — walkthrough of the default project
• Renderer & Engine Selection — the full backend decision matrix and memory numbers
• Core Concepts — how Glyx works under the hood