I Measured Whether Rune and Tauri Are Really Lighter Than Electron

I nearly picked a desktop framework on vibes.

I'm building a phone app, and I started thinking about a desktop version. My first instinct was "not Electron. Use Rune or Tauri, they're lighter and faster." Everyone says that. I'd never measured it.

So I did. The same tiny app in three frameworks, on one Mac, with my guesses written down before the first run.

The three contenders

Electron bundles a full copy of Chromium and Node.js into every app. That's why the downloads are big, and also why an Electron app looks and behaves the same on every OS.

Tauri skips the bundled browser. Your HTML runs in the webview the OS already ships (WebKit on macOS), and the native side is written in Rust.

Rune is the new one. It's a Rust UI framework from Anomaly, and it doesn't use a webview at all. It draws everything itself on the GPU, with its own text and layout engine. The repo was created on 22 October 2026, so it was three weeks old when I tested it, with no tagged release yet.

What I built

I used Rune's own hello example: a 320 by 200 window showing "Lights off", with a switch that springs across when you click it. Then I rebuilt the same thing in Tauri and Electron, with identical HTML and CSS in both.

Each framework kept its defaults. I didn't hand-tune anything. They were release builds, native arm64, on an M4 MacBook Pro with 16 GB running macOS 27.

I measured four things:

• Size on disk of the built app.
• Download size, with all three zipped the same way.
• Idle memory, 5 seconds after launch, added up across every process the app runs.
• Time to window, from launch until the window is on screen. That's 20 launches per app, interleaved so any background noise hits all three equally.

The results

Memory is the median of 10 launches, and time to window is the median of 20.

Tauri's download is tiny. Its memory isn't.

Tauri zips to 1.7 MB, against Electron's 113.8 MB. That's 1.5% of the size. This part of the pitch is completely true.

Memory is a different story. Open Activity Monitor and the Tauri app shows about 31 MB. That's the number people screenshot. But the page doesn't run in that process. macOS runs it in three separate WebKit processes, each with its own row in Activity Monitor: WebContent at 14.0 MB, GPU at 13.5 MB and Networking at 6.9 MB.

Add those up and Tauri uses 65 MB. Electron uses 89 MB. That's a 1.4x gap, not the order of magnitude I had in my head.

Electron is lighter than I thought

I guessed Electron would sit at 150 to 250 MB idle. It measured 89 MB, spread across a main process and three helpers. This was my worst guess of the whole exercise.

On this test, Electron's real cost is the download and the 252 MB on disk. Memory and startup are a long way down the list.

Rune is the lightest when running, not the smallest download

Rune runs as one process at 36 MB, with no browser engine anywhere. It also had the fastest window, at a 272 ms median.

But it zips to 12.2 MB, seven times Tauri's size. Rune carries its own renderer and text engine inside the binary. Tauri gets to be 1.7 MB because macOS already ships the browser engine it borrows.

"Faster" means about 100 milliseconds

Median time to window was 272 ms for Rune, 372 ms for Tauri and 449 ms for Electron. The order is real, but all three opened in under half a second.

Midway through my run, something else on the Mac slowed rounds 11 to 16 by up to two seconds, for all three apps at once. I didn't throw those rounds out or re-run them. That noise was bigger than any gap between the frameworks, which tells you how much the startup difference is worth on a hello world.

My guesses against what I measured

Before the first run, I wrote down a predicted range for every cell of that table, and what result would prove each of my claims wrong.

Five of my twelve predictions landed in range. Tauri came out smaller on disk than I expected (3.9 MB, against my 8 to 12). Electron used far less memory, and Rune a little less too. Rune and Tauri both opened a little slower than I guessed.

All four claims held up:

• Tauri's download is under 10% of Electron's. It's 1.5%.
• Tauri uses less memory, but the gap is under 3x. It's 1.4x.
• Tauri opens faster than Electron. It does, by 77 ms at the median. That's the narrowest result of the four.
• Rune is lighter than Electron on disk, download and memory. It is, on all three.

What I'd actually pick

If download size matters most (installers, auto-updates, users on slow connections), pick Tauri. Nothing else here comes close.

If running memory and a fully native renderer matter, and you're happy writing your UI in Rust, Rune is the one to watch. It's three weeks old, has no tagged release, and doesn't accept pull requests. I'd follow it, not ship a product on it yet.

If you need identical rendering on every OS, or the Node ecosystem, Electron is still a reasonable choice. 89 MB idle isn't the problem. The 114 MB download is.

For the app I'm building, none of this is the hard part anyway. It does speech recognition on the device, and a local speech model alone is roughly 75 to 150 MB. That outweighs every number in the table above.

What this doesn't tell you

• It's a hello world, so it measures the floor. A real app's memory is mostly whatever the app does: the DOM, the JavaScript heap, images. The shell is a small part of that.
• It's one machine, macOS only. On Windows, Tauri uses a Chromium-based webview, and on Linux it uses WebKitGTK. The numbers there will be different.
• They're warm starts. I couldn't flush the disk cache without sudo.
• A window on screen isn't the same as content painted. A webview can show an empty window for a few frames before the page draws.
• Memory is the physical footprint, the number Activity Monitor's Memory column shows. Resident memory (RSS) would give bigger numbers for all three, especially the apps with several processes.

Method

• Versions: Rune at commit ab5e284 of its dev branch (11 November 2026), Tauri 2.12.5 with CLI 2.12.4, and Electron 45.3.0 packaged with @electron/packager 20.3.0. Rust 1.99.1.
• Time to window: a small Swift helper starts the binary, then checks CGWindowListCopyWindowInfo every 2 ms for the first on-screen window owned by that process. Each app got one warm-up launch, then 20 rounds, rotating which app went first.
• Memory: footprint, summed over the app's own processes plus the WebKit processes that appeared when it launched. I checked that every counted process exited when its app did, so nothing that belonged to something else got counted.
• Size: du of the .app, and a zip made with ditto. Rune doesn't produce an app bundle, so its numbers are for the binary. lsof showed it loads nothing else.

I had Claude Code do the builds and write the measurement harness. The method, my guesses and the pass conditions were all written down before the first measured launch.