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, whoseDepends: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.
Top comments (0)