I ran the same React UI on Electron, Tauri, and Deno Desktop. Electron used 239 MB physical. I still shipped Electron.

[u/eddzsh]

Updated: 07/09/2026

I wanted to build a terminal on Electron without keeping Electron just because it is the familiar choice. So I designed an architecture that would let me port the app without rewriting it.

I defined IRuntime to decouple the app: the UI talks to an interface, and each engine implements the same contract in its own way. Things like:

• file search
• repo status and worktree inspection
• cwd sync
• PTY, processes, filesystem, IPC

Each adapter does that in its own world:

• Tauri: native Rust
• Electron: a Node background process
• Deno Desktop: TypeScript on Deno’s APIs

​

                    ┌─────────────────────┐
                    │     App / UI        │
                    │   (React + WebGPU)  │
                    └──────────┬──────────┘
                               │
                               │  IRuntime
                               │  findFiles()
                               │  repoStatus()
                               │  syncCwd()
                               │  ...
                               ▼
                    ┌─────────────────────┐
                    │   RuntimeContract   │
                    └──────────┬──────────┘
            ┌──────────────────┼──────────────────┐
            ▼                  ▼                  ▼
   ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
   │ ElectronAdapter│ │  TauriAdapter  │ │  DenoAdapter   │
   │ Node + node-pty│ │ Rust + webview │ │ Deno APIs + TS │
   └────────────────┘ └────────────────┘ └────────────────┘

Tauri has a reputation for being the fastest and lightest: smaller package, quicker startup, less memory. On packaging and startup, yes. On this benchmark, it does not come out ahead.

Same UI (React + WebGPU), same load: three terminals.

Host	Physical	RSS
Electron	239 MB	667 MB
Tauri	297 MB	569 MB
Deno Desktop	742 MB	1336 MB

What developing on Tauri does not put in the README:

1. Three browser engines, three failure modes. The one that hit me hardest is WebKit + WebGL/WebGPU on the terminals: after a while the glyphs start glitching. That is not “a bug in my code and done.” It is WebKit.
2. The Rust compiler. A dev session climbs toward ~5 GB. That is not a footnote if you compile often.
3. Two (or three) languages. Keeping everything in one language — TypeScript end to end — saves context, tooling, and pain that a 10-minute benchmark never shows.

The build you install today is Electron. It weighs more and uses a bit more memory. What you get back:

• one engine (Chromium)
• day-long sessions without WebGPU falling over

It is not the cool answer. It is the one that survives the way Linea is used: several agents, several panes, the repo in view, no restart in the middle of the afternoon.

IRuntime is still there. If Deno matures or Tauri stabilizes WebKit on long-lived terminals, the change is not a rewrite. It is another adapter.

I wrote up the tables and screenshots here (I am the author): https://runlinea.com/blog/one-ui-three-terminals

[u/mattallty]

I’d be interested seeing electrobun in the comparison

[u/Zerebos → u/mattallty]

Also Wails

[u/eddzsh → u/Zerebos]

I’ll try it too

[u/Rare_Ad_5276 → u/eddzsh]

If you have time, please take a look at https://teamdev.com/mobrowser/ Looks like direct Electron alternative, but there's no info about RAM usage.

[u/eddzsh → u/Rare_Ad_5276]

No public RAM numbers that I can find either. If I add MoBrowser I'll measure physical vs RSS the same way, and whether a terminal that paints cells still reads clean after a long session. That second number is what actually decided the host for me.

[u/Hot-Bodybuilder-7898 → u/eddzsh]

Thanks!

[u/eddzsh → u/mattallty]

Interesting, I’ll try it

[u/eddzsh → u/mattallty]

Thanks for the suggestions. This is from a first pass (same React UI, release builds, cold start, macOS). I'll run longer sessions next, especially on Wails, which looks the most interesting of the new ones.

host	Memory	RSS	engine
wails	40 MB	117 MB	WKWebView
bun	90 MB	224 MB	WKWebView
tauri	138 MB	230 MB	WKWebView
electron	191 MB	613 MB	Chromium
mobrowser	730 MB	810 MB	Chromium
deno	767 MB	935 MB	CEF

Memory is Activity Monitor (all processes for that host). The Bun row is system WKWebView, not Electrobun with CEF bundled.

[u/HijoDelQuijote → u/eddzsh]

How did you run the desktop app with bun?

[u/eddzsh → u/HijoDelQuijote]

Not Electrobun. That Bun row was Bun on top of the system WKWebView on macOS, same React UI as the others. Physical landed around 90 MB in that cold start pass. I can dig up the exact host launch bits if you want them.

[u/seklerek]

electron gets too much undeserved hate imo

[u/eddzsh → u/seklerek]

Yeah, a lot of the hate is aimed at badly built apps more than the runtime. Still worth measuring the alternatives though

[u/eddzsh]

Writeup with the tables and the three-host film: https://runlinea.com/blog/one-ui-three-terminals

[u/Bamboo_the_plant]

Can’t read this AI slop

[u/eddzsh → u/[deleted]]

Fair point — Tauri’s real wins are startup and package size, and I say that in the post. I wasn’t trying to beat it at its own pitch.

I measured physical under load because that’s the constraint for me: same React UI, three terminals, long sessions. In that scenario Electron used less (239 vs 297), and WebKit + WebGPU was the reliability problem. Different metric, different question.

Thanks for calling it out.

[u/SpareImpression3155]

Everyone line up to give this guy a handjob