Why Voiden Is Built on Electron

This isn't a defense of Electron. It's an explanation of a decision, including the uncomfortable parts.

We chose Electron for Voiden very intentionally.

Footprint matters. Electron has real tradeoffs. Both things are true, and we knew both going in. But in the discussions we've had with the community, one line stuck with us: too much of this debate is about vibes, not reality.

Every framework has tradeoffs. The real question is whether those tradeoffs fit the product you're building.

What we're actually building

Voiden is closer to an IDE for APIs than an API client. It's an offline-first, Git-native workspace where requests, docs, tests, and mocks live together in plain .void Markdown files, stored in your repo like any other code.

That means richer editing, local workflows, real desktop behavior, extensibility, and a much bigger product surface than a form-based request sender. We needed a stack that let us build deeply customized interfaces, move fast, and ship the same experience across macOS, Windows, and Linux.

Maturity was the deciding factor

Before Voiden was open source, we prototyped with different frameworks. What we kept running into wasn't just feature gaps. It was questions of ecosystem maturity, edge-case behavior, and how much risk we'd be carrying across operating systems and versions.

We didn't want to spend our days chasing obscure OS-specific problems, weird runtime behavior, or framework limitations that users would experience as product bugs. Users don't care whether a bug came from your app code, a runtime quirk, or a framework edge case. They just know the app broke.

Stability is part of the UX. Reliability is part of the UX. Compatibility is part of the product, full stop. Picking a mature, battle-tested platform was part of taking the product seriously.

The Activity Monitor conversation

Here's the part where I stop sounding reasonable and start sounding like every Electron developer you've ever argued with. So let me be careful.

As Voiden's adoption grew, the memory questions started. Our app-side usage in normal work is often around 50–60 MB. We even surface it inside the app so people can check for themselves. But then someone opens Activity Monitor, sees the full set of Chromium and Electron processes, and the conversation immediately becomes "yeah but Tauri would use way less."

I asked about this openly on Lemmy, and got an answer I still think about. Someone who openly dislikes Electron wrote, roughly: your app doesn't use 50 to 60 MB, it uses 500 MB-ish on idle because of your choice. And that's okay, as long as you as the developer say that it is.

They were right. Pointing only at the app-side number, while skipping the full process footprint, sounds disingenuous to exactly the people you're trying to convince. The full footprint is real. Chromium is not free. Pretending otherwise would be foolish.

The comparison is real. It's also flattened.

The published numbers aren't controversial. Comparisons of the two frameworks typically report Tauri apps idling around 30–40 MB with installers under 10 MB, while Electron apps commonly idle in the 200–300 MB range with installers over 100 MB, because every Electron app ships its own Chromium and Node runtime. Tauri uses the operating system's built-in WebView instead, with a Rust core for system access.

If the comparison ended there, the choice would be obvious. It doesn't end there.

What those comparisons usually leave out:

• Development speed. "Why would a user care about development speed?" someone asked me, fairly. Because the tool keeps evolving. We ship 2–3 releases a month, and the people filing tickets are developers who expect them to be tackled. The ability to deliver at that pace is something users feel directly.
• Cross-platform consistency. Our users are dev and QA teams. We didn't want a scenario where a team can't adopt Voiden because some devs are on Macs, others on Linux, and QA is on Windows, and the app behaves differently on each. With the system WebView approach, your UI renders on whatever WebView each OS ships. Bundling Chromium means it renders on one.
• Ecosystem maturity. Years of production use, thousands of packages, and known answers to known problems. Electron's own rationale is exactly this: bundling Chromium, V8, and Node gives developers control over stability, security, and updates, instead of depending on whatever WebView an OS happens to provide.
• What the app is actually doing. Some apps do much more than others. Comparing a full IDE-like tool's process footprint against the smallest possible Tauri mental model isn't a like-for-like comparison.

None of this makes the footprint gap disappear. It just puts the gap next to the things it's usually compared without.

Electron's reputation was earned. Just not always by Electron.

A lot of Electron's bad reputation was earned indirectly, by bad product decisions rather than by the framework itself. Too many poorly built desktop tools have trained people to see "Electron" and immediately think "bloated." In API tooling especially, Postman shaped that perception so strongly that other Electron-based tools inherit the blame by association, deserved or not.

The concern is real, though. It's the diagnosis that's often too shallow. A badly designed app can be heavy in any stack. The framework decides your floor, not your ceiling. Electron just makes the blame more visible.

Transparency instead of excuses

Our answer to the footprint question is visibility.

Resource consumption should never be a hidden implementation detail users are expected to tolerate. If Voiden is eating too much memory, you should be able to see that clearly, in the app, and call us out. We'd rather be open about the current footprint, keep shrinking it where we can, and get told when something is clearly off, than win an argument in a comment thread.

Would we ever switch?

We're not religious about this. Ecosystems mature, new options get better, and there are concrete conditions under which we'd reconsider: if the pace of releases becomes less critical to the product, or if an alternative demonstrably delivers the same cross-platform consistency and UI depth we depend on, a change would be on the table. Same reasoning that led us to Electron, applied forward.

But when we made the decision, and looking at it now, we believe it was the right one. We'd rather stand on a mature, reliable foundation and build the product properly than chase optimizations that look good in a comparison chart and create instability where users actually feel it.

Electron gave us the most dependable foundation for building Voiden well. And we'll take stability and real-world product quality over a better benchmark screenshot every single time.

If you want to see what we've built on our choice, Voiden is free to download at voiden.md/download, and the code is at github.com/VoidenHQ/voiden.