Why Build Desktop Apps with GPUI Instead of Electron?

Why build desktop apps with GPUI instead of Electron?

Because for small, personal desktop software the browser engine costs more than it buys, argues Syntax co-host Scott Tolinski — and GPUI, the Rust UI framework behind the Zed editor, lets a web developer keep a React-shaped mental model while dropping the browser entirely. He opens the episode with a goodbye to Electron, Tauri, and desktop apps built on web views. GPUI is, in his description, a GPU-accelerated, cross-platform UI framework. The package he actually ships is one Rust program with no embedded browser, a component library called GPUI Kit, and utilities that update in megabytes. He accepts real trade-offs for this: no native UI controls, a WASM-only web story, and a young ecosystem — none of which, in his use cases, outweigh the weight being shed.

Where the web-view road ends

Tolinski's complaint is not that Electron is slow — he is explicit that VS Code shows the framework can be fast, and that sluggishness there usually traces to third-party extensions. His complaint is structural: every Electron app ships an instance of Chromium with the app. Tauri's alternative — Rust on the back end, the operating system's native web view in front — fails for him on macOS specifically. There, WKWebView is in his words not feature-rich, not good for desktop applications, and unpredictable in terms of who has which features, because no specific engine version ships with the app. Electron's counter-advantage is exactly the one Tauri gives up: you ship a chosen Chrome version and know every user has the same features.

A React-shaped API, with the rough edges visible

What makes the switch survivable for a web developer, Tolinski says, is that GPUI keeps the React mental model. He calls it a very web — "dare I say" — React-like experience. Components are structs with typed props; there is a render function; state updates are requested through an explicit notify call, which co-host Wes Bos likens to Remix's manual update model. The styling layer is method chaining on individual elements, which he compares to Tailwind-class bloat intensified, and which he tolerates largely because AI agents write most of that code for him.

Two concrete limits came up when Bos pressed on capabilities. First, layout: searching the framework's docs live, the hosts found "just flex everywhere" and no CSS grid. Programmatic layout in Rust is the workaround, and both note the web itself worked that way before CSS grid existed. Second, architecture — and here the news is good. Because UI and logic live in one Rust program, Tolinski points out you are eliminating the RPC layer an Electron app needs between its processes. GPUI is only the UI layer; how the application around it is structured is left to the developer.

GPUI Kit, and the fork the library refuses to support

The piece that made GPUI practical for Tolinski is GPUI Kit, a component library with the expected inventory — accordions, dialogs, popovers, combo boxes — plus a data table with virtualization and sorting that he singles out. "It feels very like shadcn of GPUI," he says. That library sits at the center of the episode's one piece of community friction. GPUI's community is fragmented, Tolinski reports, because community members feel the Zed team — the team that created GPUI — only adds things to GPUI that serve them. A fork, GPUI CE, offers features mainline GPUI lacks, per a community post he cites: declarative style transitions, corner smoothing, blur, and gradient borders. But the GPUI Kit maintainer has declined to support the fork, and Tolinski quotes the reasoning: only projects validated by real-world applications will generate continuous real-world demand and drive the framework's improvement. Tolinski takes no side; he uses GPUI and GPUI Kit.

Eight megabytes against 267

The argument that carries the episode is size. DaisyDisk, a Mac disk-space utility Tolinski uses, updated itself at eight megabytes. Bos's counterpoint: there is probably some Electron version of DaisyDisk that is 267 megabytes — sitting on the disk through every update, with a Chromium instance running in the background besides. For always-on personal utilities — file automation in the manner of Hazel, duplicate checkers, a multi-machine project monitor, a window-placement tool — Tolinski wants thin, light, and fast, and Bos agrees without reservation: he is rewriting his own video recorder to be as lean as possible, precisely because he does not want a separate Chromium instance for every small idea.

The honest costs, and the verdict

Tolinski is unusually direct about what adopting GPUI costs. The biggest downside, he says, is the non-native UI element. A Mac-native Liquid Glass look, or Windows-native styling, would have to be reimplemented in GPUI itself — a cost he flips into control over the application's appearance. The web target compiles to WASM, and he does not believe it will use the real DOM at all. The ecosystem is young, resources are thin, and the framework is not write-once-deploy-everywhere: no React Native-style simultaneous native, web, and desktop targets, and in practice he stays on native desktop. Even AI-driven testing changes shape — browser automation does not apply — though he notes these apps expose a full accessibility tree, which his own early Jev-driven testing project uses to click through GPUI applications without screenshots. Mobile exists only as an experimental Metal-over-WGPU target, and Bos imagines a long list of native bridges — maps, NFC, the file picker — before it would be practical.

The verdict is scoped, not evangelical. Tolinski would not use GPUI for a native mobile app or a web app. For personal desktop software — the category where he does not want yet another large Electron install — his position is plain: "GPUI is the way to go, if you're talking to me."