When the Hoppscotch team moved their desktop client off Electron and onto Tauri, the bundle dropped from 165MB to 8MB and memory use fell by roughly 70 percent. That is a 25x shrink, and the internet adores it. Electron apps idle at 200 to 300MB and ship installers in the 80 to 150MB range; Tauri apps idle around 30 to 50MB and ship under 10MB. The numbers are real, repeatable, and on the surface they settle the argument. They are also, for most of the people quoting them, the wrong number to be staring at.
Cross-platform desktop app development has a consensus take, and the consensus take is lazy. It goes like this: native is better, Electron is bloated, web-tech-in-a-window is a compromise you make when you're cheap, and the serious move is to pick whichever framework wins the benchmark this quarter. Every part of that is either wrong or beside the point. I'll say where I stand up front so there's no suspense: for the overwhelming majority of business desktop software, cross-platform built on web technology is the correct default, and the framework benchmark war is a distraction from the one cost that actually kills these projects.
The benchmark everyone quotes measures a problem most apps don't have
Start with the bloat complaint, because it's the loudest. Yes, every Electron window is effectively its own Chromium tab with the memory bill to match, and yes, a note-taking app has no business weighing 200MB. As an aesthetic objection it's correct. As a decision input it's mostly vanity. RAM-at-idle is a number that matters enormously for a tool that runs on a developer's already-saturated laptop next to Docker and an IDE — which is exactly why Sourcegraph's Cody and Spacedrive reach for Tauri — and matters almost not at all for the internal claims-processing app that one department opens once and leaves running on a machine with 16GB of RAM. Most line-of-business desktop software is the second kind. People optimizing the first kind's metric for the second kind's app are solving a problem they don't have.
The 'native is better' camp is making a more respectable version of the same mistake. Native is better — at the things native is better at: tight OS integration, the last 10 percent of UI polish, latency-critical rendering. The catch is that 'better' here means 'three codebases.' A native Windows app, a native macOS app, and a native Linux app are three separate things to write, three to test, three to debug, and three to keep alive every time an OS ships a breaking update. That is a tax, and it compounds annually. The write-once crowd gets mocked for the compromise; the write-three crowd rarely gets asked whether they can actually afford to pay the bill they just signed up for. Usually they can't.
The cost that sinks the project shows up at year three
Here is the thing the benchmark can't measure, and it's the whole ballgame: a desktop app is not a thing you ship, it's a thing you maintain. The expensive part of cross-platform desktop development is not the megabytes at startup or the milliseconds to first paint. It's the slow grind of OS updates breaking your packaging, code-signing and notarization regimes tightening every year, a WebView engine changing behavior on one platform and not the others, and an auto-updater that has to work flawlessly on machines you will never see. None of that appears in a 'Tauri vs Electron' table. All of it appears on your calendar, forever.
This is the lens I cut the topic with. At EltexSoft, the boutique studio I run, our entire model is built on keeping the same engineers on the same product for years — annual turnover under 5 percent against an industry norm north of 20, and an average client engagement of around four years. That's not a recruiting brag; it's the reason I distrust any framework decision justified purely on day-one numbers. We've been on the maintenance side of these choices long enough to watch the bill arrive. The framework that 'won' on a benchmark in year one is routinely the more expensive one by year three — because the person who understood the clever native shim has moved on, and at a shop with normal churn, nobody who's left can safely touch it.
So Tauri obviously wins, right? Not so fast
Watch how fast the obvious answer dissolves once you price years instead of milliseconds. Tauri genuinely wins the benchmark — roughly 25x smaller bundles, 50 to 75 percent less memory, faster startup — and if you're starting fresh and your UI is simple, that's a real argument for making it the default. But Tauri buys those wins with two things that land precisely where the maintenance cost lives. First, it renders through the operating system's own WebView — WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux — which means your app runs on three different browser engines and can look or behave subtly differently on each. Second, anything beyond its plugin ecosystem requires Rust. Electron, meanwhile, bundles the same Chromium everywhere, which is exactly why it's heavy and exactly why it renders identically on every machine — and it's the proven foundation under VS Code, Slack, and Discord, with something like 5 million weekly downloads to Tauri's roughly 500 thousand.
Read what that trade actually is. Tauri moves cost off the user's RAM meter and onto your team: more per-OS rendering edge cases to chase, and a Rust requirement for native integration that shrinks the set of people who can maintain the thing. Electron does the reverse — it spends the user's memory to buy you uniformity and a hiring pool the size of 'every JavaScript developer alive.' Neither is free. The benchmark only shows you the side of the ledger that helps Tauri. The side it hides — who can keep this alive in three years — is the side that decides whether your project survives.
The question almost nobody asks first
Before any of this, the question that should be asked and usually isn't: does this even need to be a desktop app? A large share of things shipped as desktop apps are web apps wearing a costume, bundled into a window so they can have a dock icon and feel 'real.' If you're not using the filesystem hard, not going offline, not touching specific hardware, not fighting for latency the browser can't give you, you may have just volunteered for code-signing, auto-update, and per-OS packaging in exchange for an icon. A desktop app should earn its existence with a concrete reason — Spacedrive needs Rust-grade filesystem performance, a remote-control tool needs native screen capture — and that one reason, not the framework leaderboard, is the thing that should drive every technical choice downstream.
If the model itself is still fuzzy, start with our full breakdown of when staff augmentation is worth it. And when you want to see how we structure engagements around retention, our staffing services lay it out.
How to actually decide
Commit to cross-platform as your default for desktop business software — three native codebases is a tax you will resent paying by the second OS release. Then make the framework choice on two questions the benchmarks won't ask. One: what is the single reason this is a desktop app, and which framework serves that reason without a fight? If it's filesystem and performance, Tauri's Rust core is a feature, not a tax; if it's a rich, render-heavy UI that must look identical everywhere and ship fast, Electron's bundled Chromium is the boring correct answer. Two: who maintains this in three years, and can you actually keep them? If your team lives in JavaScript and React and you can't reliably retain a Rust engineer, the 'lighter' framework is heavier where it counts. We staff cross-platform work with the same people month after month and put every change through a senior review precisely because the multi-year maintenance path is where these apps live or die — and most shops underprice that path to zero.
The honest answer to 'what's the best way to build a cross-platform desktop app' is not a framework. It's a discipline: pick the default that doesn't ask you to maintain three codebases, justify the desktop app's existence with one real reason, and choose the runtime that the team you can actually keep will still understand after the people who wrote it are gone. Anyone settling the question with a memory-at-idle chart is selling you a number that won't be on the invoice when it actually hurts.