Everyone Hates Electron—So Why Won’t It Die?

Electron’s core problem is simple: every app brings its own browser. It bundles web technologies (HTML, CSS, JavaScript) with Node.js.js for system interaction, then wraps it all in a dedicated Chromium runtime. This architecture means each Electron app is a self-contained web environment, independent of the operating system's native browser.

This design exacts a heavy toll on system resources. Consider Claude on macOS: the Electron Framework alone consumes 286 MB of the app’s 618 MB total. On one Mac, 22 Electron apps collectively accounted for 6.5 GB of duplicated Chromium copies. Each instance of Chromium also demands memory; Claude, while merely open, utilized roughly 600 MB of RAM across 11 processes.

These figures, drawn from a Better Stack video, illustrate the burden. It’s crucial to note these are specific examples, not universal benchmarks. An app’s final size and memory footprint fluctuate significantly based on bundled tools, specific libraries, and active workload, but the underlying inefficiency of isolated Chromium instances remains.

Electron’s critics often tout native development as the obvious counter, yet that path is paved with multiplying effort. Building with SwiftUI for Mac, for instance, offers a pixel-perfect experience but necessitates entirely separate implementations for Windows and Linux, dramatically increasing engineering and maintenance overhead. One company, 1Password, once needed four distinct teams before consolidating on Electron.

Alternatives like Tauri and Wails address Electron’s bloat by leveraging the operating system’s existing webview—WebKit on macOS, WebView2 on Windows, WebKitGTK on Linux—with Rust or Go handling native system interactions. This approach yields significantly lighter apps: an empty Tauri app weighs roughly 5 MB on Mac, compared to Electron’s typical 268 MB baseline runtime.

However, this efficiency introduces a critical trade-off: compatibility. Relying on system webviews means your app’s rendering can vary across platforms, inheriting OS-level bugs or inconsistencies that are beyond your control. Slack, for example, originally used macOS’s built-in Safari engine but switched to Electron after encountering unfixable rendering issues in older macOS versions.

Ultimately, the apparent "free win" of lighter alternatives comes at the cost of consistency and control. While Tauri and Wails offer impressive size reductions, they reintroduce the very fragmentation Electron was designed to overcome, forcing developers to balance performance with predictable user experience.

Electron’s true genius, and its most aggravating flaw, lies in its self-contained nature. While native apps gamble on unpredictable system webviews—like Safari’s engine on macOS or Edge’s on Windows—Electron bundles its own Chromium runtime. This guarantees a consistent rendering environment across Windows, macOS, and Linux, eliminating platform-specific surprises for developers.

This control comes at a cost, however. When Slack initially relied on macOS’s built-in Safari engine, older OS versions with Safari bugs left them powerless. Switching to Electron gave them a unified codebase and the autonomy to ship fixes themselves. This trade-off is why even newer frameworks like Tauri are considering bundling Chromium, acknowledging Electron’s core strength. Learn more about its capabilities at Electron: Build Cross-Platform Desktop Apps.

However, this autonomy creates a sprawling update problem. Every Electron app carries its own Chromium copy, meaning a fix to Electron or Chromium itself only reaches users after each individual app vendor releases an update. For instance, a macOS update last year caused system-wide lag in Electron apps due to an Electron bug overriding private Apple UI code. The fix had to be propagated by every single affected app, illustrating the sheer inefficiency of this distributed update model. This consistency-over-elegance approach, while simplifying development, fragments the user experience.

For fast-moving AI products, Electron’s appeal is undeniable. Shared web and desktop code allows teams to carry features across Mac, Windows, and Linux with less duplicated effort, streamlining development for products like Anthropic’s Claude and OpenAI’s Codex. These are engineering trade-offs, not universal endorsements of Electron.

OpenAI, for instance, replaced its native ChatGPT Mac app with an Electron-based Codex client. While the original native app was 159 MB, the new Electron version expanded to 1.7 GB—though a significant portion bundles Codex tools. This illustrates the resource cost of a unified codebase.

Even with advanced AI coding tools, the burden of native clients isn't erased. Coding agents excel at generating initial implementations, but testing, fixing, and supporting several platform-specific apps remains a significant challenge, multiplying bug count and maintenance work. As one Claude Code creator stated, "three apps, they're three times as many bugs to fix and support."

The practical rule of thumb remains: for small utilities where footprint matters, consider Tauri or Wails, which can produce apps as small as 5 MB on macOS. For complex, cross-platform products prioritizing consistent behavior and rapid releases across Mac, Windows, and Linux, Electron remains the safer, more predictable bet.

Why do Electron apps use so much memory?

Each Electron app bundles Chromium and runs its own processes, adding overhead even when the app is idle.

Why do companies still choose Electron?

It offers a consistent Chromium environment and lets teams share code across Mac, Windows, Linux, and often the web.

Is Tauri always smaller than Electron?

Its app bundles can be much smaller because Tauri usually uses the operating system’s webview, but rendering can vary by platform.

When should a team choose native development?

Native can be a strong fit when platform-specific performance and user experience justify maintaining separate implementations.