Benchmarks Don't Ship Software: The Real Cost of Desktop Framework Hype

I wrote this draft last night and published it at noon today. Right before publishing, I stumbled upon another mindless article... I can't even be bothered to rant anymore.

Yesterday I came across yet another article, with a title along the lines of "Electron and Tauri2 should be history; Zero-Native is the future."

The accompanying graphic was familiar: a memory usage comparison chart, a cold-start bar chart. Red bars high, blue bars low, followed by a bold conclusion—Zero-Native is the future. The comments section quickly heated up, all echoing the same sentiment: finally, we don't have to put up with Electron on the desktop anymore.

I can't join the applause.

Not because the charts are necessarily fake. Zero-Native is a recently open-sourced, Zig-based cross-platform desktop framework from Vercel, and it does look impressive in some benchmarks. Tauri2 has indeed solved the problems Electron is most often criticized for: large bundle size, slow startup, high memory usage.

The problem is, that article treated the input as the conclusion.

It didn't ask what your product actually is. It didn't ask whether your team has anyone who can maintain Rust or Zig long-term. It didn't ask who will handle the differences between WebViews on three platforms, how to collect logs after a crash, how to handle code signing and notarization, how to roll back an auto-update, or who will take over this pile of code five years from now. It only compared two things: whose package is smaller, and whose cold start is faster.

This is certainly useful information. But packaging one or two benchmark metrics as engineering judgment is a different matter entirely.

What They're Actually Good At

To be fair: the direction Tauri2 and Zero-Native are taking is not wrong.

Tauri2's model is clean: a Rust backend, the interface handed off to the system's built-in WebView, connected via IPC. Zero-Native swaps Rust for Zig, but the general direction is similar—a native backend plus the system WebView. Their advantage is straightforward: by not bundling a full Chromium, the installation package is naturally smaller, and the process model is lighter.

If you're building a settings panel, a small backend utility, or a lightweight client that doesn't demand high rendering consistency, this choice could be very appealing. Users download it quickly, the machine's load is low, and the team doesn't have to bear the cost of a full Chromium instance for a simple interface.

But "how much smaller" is not a number you can write into a conclusion without context.

Even Tauri's official documentation only describes its output as "tiny binaries," refusing to give a universally applicable MB figure. It inherently fluctuates based on the scenario: which dependencies you've bundled, whether the WebView runtime exists on the target machine, whether you need to include patches, how the installer is built—every single factor rewrites the result. Package size is a tangible advantage, but it's a range, not the fixed "domination" figure found in marketing articles.

More critically, the cost saved by omitting Chromium doesn't just vanish. It returns to your engineering system in a different form.

"Opening a WebView" Isn't the Hard Part

The cost of a system WebView is that you no longer fully own the rendering engine.

On Windows, it's WebView2; on macOS, it's WKWebView; on Linux, it's commonly WebKitGTK. The moment your product has any requirements for rendering consistency, input methods, keyboard shortcuts, clipboard behavior, window behavior, or font rendering, the differences will surface. A piece of CSS works fine on one platform, jitters on another. A keyboard shortcut works normally in a browser, but conflicts with the system once wrapped in a desktop shell. A WebView runtime version mismatch turns your online users into part of a test matrix.

These problems aren't unsolvable. Tauri2 can produce excellent products, and Zero-Native is worth watching. But you have to acknowledge there's a cost here. What you save by not bundling Chromium, you trade for cross-platform WebView discrepancies, runtime dependencies, and more client-side environmental variables.

And "opening a WebView" was never the hardest part of desktop development in the first place.

The hard part is delivering the product to the user's computer and keeping it delivered reliably over the long term: code signing, notarization, installers, auto-updates, rollbacks, crash collection, system trays, global shortcuts, multi-window management, multi-process architecture, plugin systems. Looking further ahead, there's the team's knowledge structure, upstream activity, debugging tools, build chain stability, and who will still be able to maintain it five years from now.

Whether a solution is superior on a specific metric, and whether it can support a long-evolving desktop product, are two different questions. A benchmark chart can only answer the first.

The Two Choices I Truly Respect

So what I truly respect isn't "which framework has prettier benchmarks," but two very down-to-earth engineering postures.

The first is VSCode.

It's built on Electron, and it never hides that fact. But it doesn't use Electron as a universal excuse for performance problems. In 2024, the VSCode official blog published two long articles explaining how they use Rust to write WebAssembly modules and inject them into extensions. For performance-sensitive tasks, like text processing and language services, they compile them into WASM, throw them into a worker, and keep them off the main thread.

This is the way of using Electron that I approve of: first locate the bottleneck, then reinforce that specific segment within the existing tech stack. Not blaming the framework the moment something is slow, and certainly not swapping out the shell just to step on every desktop development landmine all over again.

The second is Zed.

Zed's team wrote a long article recalling the pain of building Atom back in the day: a GC pause, dropped frames; a DOM reflow, dropped frames; the frame rate couldn't stabilize, and many causes were outside their control. The goal of that article was clear: use Rust and the GPU to render the editor interface at a stable 120 FPS.

So they treated the editor like a video game, building GPUI from scratch—a Rust-written, GPU-accelerated UI framework. When announcing 1.0, Zed's logic was equally direct: if you want to break through borrowed abstraction layers, you have to hold more of the stack in your own hands.

The bill for this path is also laid out on the table. They later tore down and rewrote the entire framework, specifically writing about why the big rewrite was necessary, and then about the launch of GPUI 2 on preview. When you build your own foundation and discover it's crooked, the only people who can redo the work are yourselves. There's no upstream to take that hit for you.

They Are Actually the Same Kind of People

One didn't change frameworks; the other built an entire UI framework from scratch. Placed side-by-side, they look like two extremes.

But in my view, VSCode and Zed are the same kind of people.

Both sides first ran into a concrete product problem, then went looking for a technical answer. VSCode knew it had performance bottlenecks, so it used Rust and WASM within Electron to reinforce the critical paths. Zed judged that existing solutions couldn't reach the frame rate and control it demanded, so it accepted the cost of a self-built framework, along with the subsequent cost of rewriting it.

This is fundamentally different from "first pick a trendy language, wrap it in a cross-platform shell, then wave performance charts around shouting 'domination'." The former puts the problem first and the technology second; the latter puts the technology first and invents the justification afterward.

What Engineering Capability Really Is

In desktop technology selection, the most easily underestimated capability isn't knowing which framework is newer, or which benchmark looks better.

It's being able to articulate exactly where your product is stuck: does slow startup genuinely hurt your users, or do they only open it once a week? Is memory usage the core conflict, or are stable updates and a plugin ecosystem more important? Is your team willing to pay the bill for Rust, Zig, WebView discrepancies, code signing, notarization, and crash diagnostics? Will the package size you save today turn into maintenance costs next year?

Electron doesn't automatically become obsolete just because its benchmarks are poor. Tauri2 and Zero-Native don't automatically become the answer just because their benchmarks are good. They are all tools, and the value of a tool must be calculated within the context of the product problem.

Anyone can read a benchmark chart. What's truly difficult is knowing what that chart isn't telling you.

(End)