DEV Community: Quinn Millican

The UI frameworks local AI desktop apps actually ship

Quinn Millican — Mon, 21 Sep 2026 14:29:40 +0000

Every local AI tool with a GUI has to answer the same question: what do you wrap the UI in? The answers are not what I expected, and you do not have to take anyone's word for them. The answer is sitting in the installer.

The method

You can identify a desktop app's UI framework from its Linux package without installing it, and usually without downloading the whole thing.

A .deb is an ar archive with three members in a fixed order: debian-binary, control.tar.*, then data.tar.*. The control archive is small and sits near the front, so an HTTP range request for the first megabyte is normally enough to get all of it:

curl -sL -r 0-1048575 "$URL" -o head.bin
ar t head.bin

Inside control.tar.xz are two files that answer the question outright:

control, whose Depends: line names the runtime libraries
md5sums, which lists every file in the package

An Electron app built with electron-builder declares a distinctive dependency set:

Depends: libgtk-3-0, libnotify4, libnss3, libxtst6, xdg-utils, libatspi2.0-0, libuuid1, libsecret-1-0
Recommends: libappindicator3-1

libnss3 is Chromium's Network Security Services. A Tauri app declares libwebkit2gtk-4.1-0 instead, which is a different and famously painful dependency. The file list confirms it either way: Electron ships LICENSE.electron.txt, resources/app.asar, chrome-sandbox, icudtl.dat, v8_context_snapshot.bin and libffmpeg.so. Tauri ships none of those.

For open source projects you can skip all of this and just look: src-tauri/ in the repo root means Tauri, an app.asar in the packaged output means Electron.

An .rpm is even better if you want sizes, because its header carries per-file sizes and also sits at the front of the file. That is where the size split below comes from.

The results

Tool	UI shell	How it was confirmed
LM Studio 0.4.25	Electron	Package metadata
Docker Desktop	Electron	Vendor roadmap issue
Cosmonic Desktop 0.5.29	Electron	Package metadata
Jan	Tauri, migrated off Electron	Repository layout
Ollama	Native Go plus the system webview	Repository layout

LM Studio

The .deb is 732 MB and the AppImage is 965 MB. Installed-Size: 2275411 KB works out to about 2.17 GiB on disk. The control file carries the electron-builder dependency set verbatim, and the package contains LICENSE.electron.txt, chrome-sandbox, icudtl.dat, v8_context_snapshot.bin and libffmpeg.so.

Before anyone reads 2.17 GiB as a Chromium number: it is not. The package also contains 51 llama.cpp backend files, one per CPU variant. Most of that size is inference engines, not UI.

Docker Desktop

Not a local AI tool, but it is the reference case for how this happens. Docker tracked the move publicly in docker/roadmap#31, opened in March 2020 and marked "Shipped!". The stated reason is the honest one that applies to every app on this list:

Reduces engineering cost of maintaining 2 UIs and reduces ongoing cost to add/change features as we
have a single cost base for UI

Cosmonic Desktop

Cosmonic builds WebAssembly infrastructure. They created wasmCloud and donated it to the CNCF. Cosmonic Desktop is their local sandbox for running AI-generated code and MCP servers as capability-scoped WebAssembly components.

It is Electron as well. The .deb carries the same dependency fingerprint, plus LICENSE.electron.txt, resources/app.asar, chrome-sandbox and v8_context_snapshot.bin.

Installed-Size comes to about 637 MiB, of which roughly 265 MiB is the Electron and Chromium runtime. The rest is their own application code, a wasmtime daemon, and a bundled compiler toolchain so a coding agent can build components locally. As with LM Studio, the headline number is not a measurement of UI overhead.

Jan

Jan is the interesting counterexample. janhq/jan has a src-tauri/ directory and no electron/ directory. They moved. Their own stated reasons were that the Electron app size had become "really big", and that bundling Chromium and Node was not viable for scaling to mobile.

Ollama

Ollama is neither. There is no package.json in the desktop app, no Electron, and no Tauri. The app is a Go program (go run ./cmd/app) that binds the system webview directly through a vendored copy of webview_go, with a native Windows tray in app/wintray/, native macOS code in app/darwin/, and an Inno Setup installer. Four files under app/webview/ do the work: webview.go, webview.cc, glue.c and Microsoft's WebView2.h.

They built their own shell rather than take a framework dependency.

The pattern is not "everyone ships Electron"

That was my assumption going in and it is wrong. The pattern is that this category is actively leaving Electron, and there are already two established exits:

Tauri, which swaps bundled Chromium for the system webview. Jan took this route.
Hand-rolling, which is the same trade with no framework in between. Ollama took this route.

Both exits still land on a system webview, and that has a cost people underrate. Tauri runs three different engines depending on platform: WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux. Different rendering behavior, different CSS support, different JavaScript engine versions.

The clearest evidence of what that costs is Ollama itself. Its desktop app README is titled "Ollama for macOS and Windows" and offers only a .dmg and an .exe. There is no Linux GUI. WebKitGTK is the engine everybody skips.

Caveats

Installed sizes include everything in the package. For LM Studio that means inference engines, and for Cosmonic Desktop that means a wasmtime runtime and a compiler toolchain. Neither number is a measure of UI overhead, and I have tried to separate them above rather than quote the headline.
Docker Desktop was confirmed from a vendor roadmap issue rather than package metadata.
I checked what these tools ship today. Any of them may change.
Two AI-generated sources were wrong when I checked them against the actual repositories: one claimed Ollama was Electron, and one gave a specific date for Jan's Tauri migration that the repository does not support. Both are cited confidently in places. Check the package.

I built a leaner alternative to Electron. Then I found it was burning 90% CPU at idle.

Quinn Millican — Tue, 15 Sep 2026 17:20:08 +0000

I've been building Natyv, a native desktop app runtime with no bundled browser engine. Your app logic runs as a WebAssembly guest module (via Extism) inside a native host; the host owns the window and render loop, your guest code declares UI and handles events through a small set of capability-scoped host functions. No Chromium, no DOM, no JS runtime unless your app logic happens to be written in JS.

The whole point was to be leaner than Electron. So before claiming that, I decided to actually prove it: I built the same real app three ways, Natyv, Electron, and Tauri, a working IMAP/SMTP mail client with send, read, delete, and paginate, and benchmarked all three back to back, same machine, same workload.

Disk size and idle memory came back exactly how I'd hoped:

Natyv:    27MB disk, 58MB idle RAM
Electron: 244MB disk, 331MB idle RAM
Tauri:    11MB disk, 69MB idle RAM

Idle CPU did not.

The number I didn't want to see

Electron and Tauri both settled to 0% CPU at idle, completely unsurprising, both have mature, heavily optimized event loops. Natyv was sustaining 70 to 93% CPU doing absolutely nothing.

That's not a rounding error. That's a fundamental problem, and it's the kind of thing you only find by actually comparing against real alternatives instead of profiling your own thing in isolation and calling it good.

Root cause: a main loop with no brakes

The real cause was almost embarrassingly simple once I found it. The event loop looked roughly like this:

while (running) {
    while (SDL_PollEvent(&event)) {
        handleEvent(event);
    }
    drawWindow();
}

SDL_PollEvent is non-blocking. With nothing to throttle it, that loop ran as fast as the CPU would let it, thousands of times a second, forever, whether or not anything on screen had actually changed. And drawWindow() did a full unconditional clear and redraw every single iteration regardless.

Two real problems stacked on top of each other: the loop itself never slept, and the draw call never checked whether it needed to run at all.

The fix, in two real stages

Stage 1 replaced the busy poll with SDL_WaitEventTimeout(&event, 16), waking at most 60 times a second (matching a 60Hz vsync interval) instead of continuously, plus SDL_SetRenderVSync on the renderer. Tested in isolation first: idle CPU dropped from 70 to 93% down to about 22 to 24%, with zero behavior change since drawing was still unconditional every wake.

Stage 2 added a real draw-level dirty check to the draw pass, skipping the redraw entirely unless something had actually changed since the last frame. The tricky part: "something changed" isn't just one flag. A Button's click-flash and a Spinner's animation are both driven by wall-clock time, not by any state change that bumps a generation counter, so the gate had to explicitly account for those as standing exceptions rather than relying on one dirty bit. Alongside that, a worker thread doing a widget mutation now pushes a real SDL event to wake the main thread immediately, instead of waiting out the timeout.

That combination got idle CPU down to roughly 8 to 16%. Still not 0%, but the trajectory was right.

The part that actually made it fun to debug: what an unthrottled loop had been quietly hiding

Once the loop stopped iterating continuously, a handful of real, pre-existing bugs became visible for the first time, simply because they'd always been there, just invisible when the next iteration arrived microseconds later.

A freshly created window's first present call isn't reliably guaranteed to actually display by the OS compositor, a real, known graphics-programming gotcha that a busy-spinning loop papers over automatically (the next redraw a fraction of a second later just fixes it). Once the loop only redrew on demand, that first frame sometimes genuinely never showed. Fixed with a short forced-redraw window on every newly created window.

More interesting: several pieces of per-frame state, a widget snapshot used for hit-testing and drawing, a layout pass, text sync, were all computed exactly once per loop iteration, before that same iteration's own input events were processed. That was always true. It was invisible under the old loop because the next iteration, arriving instantly, would already reflect whatever the previous iteration's events had just changed. Once the loop only woke on a real event, "the next iteration" became "the next keystroke," and it showed up as real, reproducible bugs: text input lagging by exactly one character, a refresh action not rendering every row until some unrelated later click, a freshly created widget not appearing on screen until something else happened to trigger another layout pass.

None of these were regressions from the throttling fix itself. They were real, pre-existing architectural gaps that an unthrottled loop had been silently hiding through brute force. That's a genuinely useful, general lesson: performance work that reduces how often a loop iterates is also a real regression-risk surface for exactly this class of bug, and it deserves live interactive testing (typing, clicking, scrolling), not just an idle CPU measurement and a passing test suite.

Getting the rest of the way to 0.0%

The last stretch was chasing down every remaining case where something kept the loop waking more often than it needed to: a text-sync and layout-rebuild pass that was running unconditionally on every wake instead of only when a real recompute had happened, and a fixed 16ms timeout that kept the loop polling roughly 60 times a second even at genuine idle, just to recheck that nothing had changed.

Fixed by threading a real "did this actually recompute" signal through instead of approximating it from a generation counter, and by switching to a blocking wait (genuine 0% CPU) whenever nothing needs frequent waking, with a real audit of every wall-clock-driven UI state (a fading toast, a hover-delayed tooltip) to make sure nothing silently needed a wake it wasn't going to get.

Final, measured result: 0.0% idle CPU, confirmed via ps, matching Electron and Tauri exactly, with idle RSS unaffected by any of it.

Why I'm writing this up instead of just fixing it quietly

It would've been easy to just ship the final numbers and let the benchmark table speak for itself. But the actual value here, to me, isn't "look how good our numbers are." It's that benchmarking honestly against real competitors, instead of only profiling in isolation, is what surfaced a genuine, serious bug that would have otherwise shipped. I'd rather show that process than hide it.

Natyv is v0.1.0 and early. Go is the only guest SDK today, published on pkg.go.dev: SDK, and you can find the org's repo here.

One more honest note: I used Claude Code for a lot of the actual implementation and for the live debugging instrumentation described above, but the architecture, the fix strategy, and every real design decision along the way are mine. Wanted to say that plainly rather than have it come up later.