Every comparison of desktop frameworks opens with installer size, because it is the most quotable number: Electron ships around 120MB, Tauri ships around 5MB, and the conclusion writes itself.
It is the wrong place to start. Bundle size is a one-time cost you pay on download. Webview fragmentation is a cost you pay on every bug report for the life of the product, and it is barely mentioned in the comparisons people actually read.
Here is the version I would want before starting a project.
The actual difference
There are two architectures here, not three.
Electron ships its own browser. Chromium and Node.js are bundled into your application. Every user on every platform runs the exact engine you tested against.
Tauri and Wails use the system webview. The OS already has a browser engine, so they borrow it and add a compiled backend — Rust for Tauri, Go for Wails. Your binary contains your app and not much else.
Everything else follows from that one decision.
What the system webview actually costs
You are no longer targeting one engine. You are targeting three:
| Platform | Engine | Reality |
|---|---|---|
| macOS | WKWebView | Safari-family. Tied to the OS version. |
| Windows | WebView2 | Chromium. The comfortable one. |
| Linux | WebKitGTK | Lags well behind, varies wildly by distro. |
If you have done web work, you know what “supporting Safari” means — the feature that landed in Chrome eighteen months ago, the flexbox gap bug, the date input that renders differently. Now apply that to a desktop app where you also cannot ask the user to update their browser, because their browser is their operating system.
Linux is the sharp edge. WebKitGTK is where the modern web goes to disappoint you, and its version depends on the user’s distro and release. Shipping a Linux build means either constraining yourself to a conservative feature set or accepting that a slice of your users get a degraded experience you cannot reproduce locally.
None of this is a reason to avoid Tauri or Wails. It is a reason to price it in. Teams that pick a system-webview framework for the 5MB binary and then discover they need three test environments have made a trade they did not know they were making.
Electron’s proposition is precisely the inverse: you pay 120MB and a fat memory baseline, and in exchange rendering is a solved problem forever. For an internal tool at a company that will never count megabytes, that is often just the correct trade.
Choosing between Tauri and Wails
If you have decided on a system webview, this decision is smaller than it looks, and mostly comes down to your team.
Tauri has the larger community, better documentation, more plugins, and a more developed security model — a permissions/capability system for what the frontend may call, which matters if you are shipping to customers rather than to colleagues. Tauri v2 also extends to mobile, though I would not choose it for a mobile-first product over the React Native path.
The cost is Rust. If nobody on your team writes Rust, the backend becomes the bottleneck. Straightforward things — spawning a process, watching files, talking to a database — take longer than they should while someone fights the borrow checker on a Thursday afternoon.
Wails is the pragmatic pick for a Go team, and the binding model is genuinely pleasant: expose a Go struct, get typed methods in JavaScript, done. If you already run Go services, you are sharing types and libraries with your backend rather than maintaining a second ecosystem. Go’s concurrency story also fits desktop work well — background sync, file watching, local servers.
The trade is a smaller community and fewer prebuilt answers. When you hit something unusual, there is a decent chance nobody has written it down.
My rule: pick the one whose language your team already writes. The framework differences are small enough that language fluency dominates. A Go team on Wails will out-ship a Go team learning Rust for Tauri, and the reverse is equally true.
The numbers, with the caveats attached
Approximate, and they vary with what you build:
- Installer: Electron 80–150MB. Tauri/Wails 3–15MB.
- Idle memory: Electron 80–150MB. Tauri/Wails 40–90MB.
- Cold start: Electron noticeably slower — it is booting a browser. Tauri/Wails attach to a warm system webview.
The memory gap is real but smaller than the marketing suggests, because the system webview is not free either — it is just accounted for somewhere you cannot see. What you genuinely save is the second copy of Chromium.
And a caveat that matters more than any of these: your frontend dominates all of it. A React app that ships 4MB of JavaScript and re-renders the world on every keystroke will feel sluggish in all three shells. The framework sets the floor; your architecture sets what the user actually experiences.
The parts nobody compares
These decide whether shipping is pleasant, and they rarely appear in the benchmarks.
Auto-update. Electron has electron-updater, which is mature and boring in the best sense. Tauri’s updater is good. Wails expects you to bring your own. Silent background updates are table stakes for desktop software, so find out what you are signing up for before you commit.
Signing and notarization. Identical pain in all three, and it is the single most underestimated part of shipping desktop software. Apple notarization, Windows certificates, the hardened runtime, the entitlements file nobody understands. Budget a week the first time, and expect to rediscover it every time a certificate expires.
Debugging the native layer. In Electron you are debugging JavaScript, which your team already knows how to do. In Tauri and Wails, a backend bug means Rust or Go — genuinely better languages for the job, but a context switch, and the tooling across the boundary is less polished than DevTools.
Native module access. Electron gives you the whole Node ecosystem, and for hardware-adjacent work — serial, USB, Bluetooth — that ecosystem is deep. Rust and Go have good libraries too, but “there’s an npm package for that printer” is a real advantage on a deadline.
How I actually decide
- Internal tool, distribution size irrelevant, team writes TypeScript → Electron. The consistency and ecosystem win, and nobody cares about 120MB on a corporate laptop.
- Consumer product where download size and memory are visible → Tauri or Wails, chosen by team language, with Linux support scoped honestly up front.
- Hardware integration, deep OS APIs, or heavy media → Electron, or genuinely native. Do not fight three webviews for a camera pipeline.
- Existing Go backend, desktop client on top → Wails, comfortably.
- Shipping to security-conscious customers → Tauri, for the capability model and the smaller attack surface.
The pattern underneath: the shell is a smaller decision than it feels like while you are making it. What determines whether the project goes well is the frontend architecture, the update story, and whether you understood the platform constraints before you committed — the same shape as most framework debates, where the loud argument is about tooling and the expensive mistakes are architectural.
We build desktop applications in all three, and the recommendation genuinely changes per project. If you are weighing this and want an opinion grounded in your constraints rather than a benchmark table, that is a short conversation — and worth having before the first commit rather than after the first Linux bug report.