Why We Chose Wails Over Electron
Electron powers many popular desktop apps, but comes with a 150 MB overhead and significant memory consumption. We chose Wails to build Clusterfudge — here’s how we got a native experience at 1/10th the size with the same Go backend powering our Kubernetes API interactions.
The Problem with Electron for DevTools
When you’re building a developer tool that people keep open alongside their IDE, terminal, and browser, every megabyte of RAM matters. Electron bundles an entire Chromium instance per application — that’s roughly 150 MB on disk and often 300+ MB of RAM before you write a single line of application code.
For a Kubernetes client that may need to maintain multiple long-lived connections to cluster APIs and watch resources in real-time, layering that on top of Electron’s baseline would be a non-starter for many developer machines.
Why Wails?
Wails takes a fundamentally different approach. Instead of bundling Chromium, it uses the platform’s native webview — WebKit on macOS, WebView2 on Windows, and WebKitGTK on Linux. The Go backend communicates with the frontend via a bridge, giving you the same architecture as Electron but without the bloat.
The results speak for themselves:
| Metric | Electron | Wails |
|---|---|---|
| Binary size | ~180 MB | ~15 MB |
| Idle RAM usage | ~350 MB | ~80 MB |
| Startup time | ~3s | <1s |
| Backend language | Node.js | Go |
Go + Kubernetes = Natural Fit
Kubernetes itself is written in Go, and the official client-go library is the most battle-tested way to interact with the API. With Wails, our backend is pure Go — we use client-go directly with no FFI, no process spawning, and no serialization overhead between languages.
This means we get the same informers, watch semantics, and connection pooling that kubectl uses. When you see a pod status change in Clusterfudge, it’s coming through the exact same code path it would in any production Kubernetes controller.
The Tradeoffs
Wails isn’t without downsides. The ecosystem is smaller than Electron’s — there are fewer plugins, fewer examples, and you’ll occasionally hit platform-specific webview quirks. The native webview also means you can’t guarantee pixel-identical rendering across all platforms the way you can with Chromium.
For our use case, these tradeoffs were well worth it. Our users are developers who care about performance and resource consumption. A tool that’s fast and lightweight earns a permanent spot in their workflow; one that isn’t gets closed after a demo.
Conclusion
If you’re building a developer tool and considering desktop frameworks, give Wails a serious look. The combination of Go’s performance, native webview efficiency, and a React frontend gives you the best of all worlds — without asking your users to donate 300 MB of RAM for the privilege.