Electron ships a full copy of Chromium with every app. That's not a metaphor. Every time someone downloads your "lightweight" desktop tool, they're pulling down a browser engine whether they want one or not. A hello-world Electron app sits around 120–150 MB on disk before you've written a single line of business logic. That fact alone explains why developers hate Electron — and why the conversation keeps restarting every two or three years.
But the hatred is more layered than just disk size. It's about what Electron represents: a shortcut that became a standard, a pragmatic compromise that calcified into an industry default. If you've ever watched Activity Monitor while Slack, VS Code, Figma, and Discord are all open, you've felt it in your RAM.
This post is about that feeling — where it comes from, whether it's fair, and what the actual trade-offs are.
The Memory Problem Is Real, Not Imagined
Let's be precise. Electron bundles Chromium (the rendering engine) and Node.js (the JS runtime) into a single executable. As of Electron 28 (released December 2023), that baseline overhead is roughly 60–80 MB of RAM before your app does anything. Add a moderately complex UI and you're past 200 MB easily.
Slack on macOS regularly sits at 300–500 MB in normal use. On a machine with 8 GB of RAM — still common in enterprise environments — running four Electron apps simultaneously eats a meaningful chunk of available memory. This isn't FUD. Open top or Task Manager and count.
The counterargument is that modern machines have plenty of RAM. That's true for a developer's personal MacBook Pro. It's less true for the locked-down corporate laptop running Windows 10 with 8 GB, or the Linux workstation in a university lab. Electron's defenders tend to benchmark on their own hardware. That's a selection bias worth naming.
Startup Time: The Tax You Pay Every Morning
Memory is the slow bleed. Startup time is the paper cut you notice every single day.
A native macOS app written in Swift can cold-start in under 200ms. A comparable Electron app takes 1–3 seconds, sometimes longer on spinning-disk machines or underpowered hardware. That's because Electron has to spin up a Chromium instance, initialize Node.js, parse your JavaScript bundle, and then render your UI.
For a tool you open once a week, this is tolerable. For a chat client or a code editor — something you open every morning and restart periodically — it compounds. VS Code has done heroic work optimizing its startup path, but it still can't match a truly native editor like Zed, which is written in Rust and starts near-instantly.
The reason this matters psychologically isn't just the seconds. It's the signal. A slow startup says: this app doesn't respect your time. Whether that's fair to the developers who shipped it is a separate question.
Why It Became the Default Anyway
Here's where I'll defend Electron, briefly and with caveats.
Cross-platform desktop development is genuinely hard. Before Electron, your options were roughly: ship a web app and call it done, write three separate native codebases (Swift/Obj-C, C++/Win32 or WPF, and GTK or Qt on Linux), or use Qt and accept its licensing complexity and non-native look.
Electron — originally released by GitHub in 2013 as Atom Shell — offered a third path: write once in HTML/CSS/JavaScript, ship everywhere. For a startup with two frontend engineers and no budget for platform-specific work, that's not a bad deal. The trade-off is real, but so is the value.
The problem is that Electron became the default even when the trade-off wasn't worth it. Tools that genuinely needed to be native shipped as Electron apps because it was faster to build. That's how we ended up with Electron-based apps for things like simple note-taking or basic markdown editors, where the entire feature set could have been a 2 MB native app.
The Alternatives Have Mostly Disappointed
Every few years, something arrives promising to fix why developers hate Electron. The track record is mixed.
Tauri (Rust-based, uses the OS's native WebView instead of bundling Chromium) is the most credible current alternative. A Tauri app can be under 10 MB. Startup is faster. Memory use is lower. I've shipped a small internal tool with Tauri 1.5 and it was genuinely pleasant. But Tauri's WebView story is messy — you're at the mercy of WKWebView on macOS, WebView2 on Windows, and WebKitGTK on Linux, which means subtle rendering differences across platforms. The "write once" promise gets leaky.
Flutter Desktop is interesting for teams already in the Flutter ecosystem, but it brings its own rendering engine (Skia/Impeller), which sidesteps the "native look" problem in a different way — by not trying to look native at all.
NW.js is basically Electron's older sibling and shares most of the same problems.
Native frameworks (SwiftUI, WinUI 3, GTK4) remain the right answer when you can afford three codebases or when your app is platform-specific by nature.
| Framework | Bundle Size | Memory Baseline | Cross-Platform | Native Look |
|---|---|---|---|---|
| Electron 28 | ~120–150 MB | 60–80 MB | Yes | No |
| Tauri 1.x | ~5–15 MB | ~20–30 MB | Yes (with caveats) | Partial |
| Flutter Desktop | ~20–30 MB | ~40–60 MB | Yes | No |
| Native (per platform) | ~2–10 MB | ~5–15 MB | No | Yes |
These are rough figures from my own testing and community benchmarks — treat them as order-of-magnitude, not spec sheet.
The Deeper Complaint: It's a Values Problem
When developers say they hate Electron, they're often expressing something beyond performance numbers. They're saying: this doesn't feel right.
There's a craft argument here. Native apps integrate with the OS — they respect system fonts, respond to accessibility settings, support platform-specific gestures, and behave predictably within the platform's UI conventions. Electron apps frequently don't. They bring their own scrollbars, their own font rendering, their own context menus. They're islands.
This matters more to some users than others. Power users notice. Accessibility users notice most acutely — screen reader support in Electron apps has historically been inconsistent, though it's improved. The developer community's frustration with Electron is partly frustration on behalf of users who deserve better.
That said, VS Code exists. It's an Electron app and it's probably the best code editor available right now for most developers. So the framework isn't incompatible with quality. It just requires more effort to get there — effort that most teams don't invest.
What Should You Actually Do?
If you're deciding whether to use Electron for a new project, here's my honest take:
Use Electron if your team is JavaScript-first, you need cross-platform support on day one, and you're willing to do the work to optimize startup and memory. Don't use it for a simple utility that doesn't need a full browser engine.
Look seriously at Tauri if your team has any Rust tolerance and your UI requirements are straightforward. The bundle size and memory wins are real. Budget extra time for WebView inconsistencies.
Go native if your app is genuinely platform-specific or if you have the engineering capacity. The user experience payoff is real and long-lasting.
The reason why developers hate Electron isn't irrational. It's the accumulated frustration of watching a pragmatic shortcut become a lazy default — and watching users pay the price in RAM, battery life, and startup delays. The framework is a tool, not a villain. But tools can be misapplied, and Electron has been misapplied at scale.
Tomorrow: open the app you're currently building or maintaining and check its actual memory footprint and cold-start time on a mid-range machine. If the numbers embarrass you, that's information worth acting on.