OpenAI just dropped their new Codex desktop app. It's Electron. Hacker News lost its mind.
The usual debate erupted: "How can a company with billions of dollars not build a native app?" vs "Electron is perfectly fine, stop complaining." I've seen this fight a hundred times. But this time, I actually read through 500+ comments to understand both sides.
Here's what I learned.
The Developer Complaint
The frustration is real. Every time a big tech company releases a new desktop app, it's wrapped in Electron. Slack, Discord, Teams, Spotify, Notion, VS Code, and now OpenAI's Codex. It's everywhere.
And developers notice things regular users don't. They see Task Manager showing 8 separate Chrome processes eating RAM. They feel the slight input lag when typing. They notice their laptop fans spinning up just to run what is essentially a chat app.
One comment from the thread put it bluntly:
"8GB of RAM usage for Codex App is clown-level ridiculous."
The argument is simple: these companies have resources. They have some of the smartest engineers in the world. They literally build AI that can write code. Yet they ship apps that bundle an entire Chrome browser just to display a text input field?
To developers who care about efficiency, it feels lazy. It feels like the company doesn't respect the user's machine.
The Business Reality
But here's the thing. These companies aren't stupid. They're making a deliberate tradeoff.
An OpenAI engineer actually responded in the thread:
"Electron lets us iterate faster and makes it possible to bring the Codex app to Windows and Linux very soon."
That word keeps coming up: faster.
Building native apps for Windows, Mac, and Linux means maintaining three completely different codebases. Three different UI frameworks. Three different sets of bugs. Three times the testing. Three times the coordination between teams.
With Electron? Write once, ship everywhere. The same JavaScript and CSS works on all platforms. You can reuse your existing web developers instead of hiring expensive native specialists.
One comment framed it perfectly:
"Do you want to move slower to get 'native feel', or do you want to ship fast and get N times as much feature dev done? In a competitive race while the new features are flowing, development speed always wins."
In the AI space right now, companies are racing to ship features. Claude Code, Codex, Cursor, Windsurf - everyone is fighting for market share. Taking 6 extra months to build a "proper" native app means your competitor has already captured your users.
Here's Where It Gets Messy
Here's what made me uncomfortable reading this debate. Both sides are right.
Developers are right that Electron apps are wasteful. They consume more memory, more CPU, and more disk space than necessary. When every app does this, your computer gets slower even though the hardware keeps getting better.
But companies are also right that speed-to-market matters more than technical purity. If customers are buying the product, if usage is growing, if revenue is increasing - the engineering decision is justified.
This is where it gets philosophical. One developer wrote:
"Customers simply don't care. I don't recall a single complaint about RAM or disk usage of my Electron-based app in the past 10 years."
And another responded:
"A good software developer cares. It's wrong to assume customers don't care simply because they don't know what's going on under the hood."
This is the real tension. Should software be built to the standard developers know is possible? Or to the standard customers are willing to accept?
The Enterprise Problem
There's another angle that came up multiple times in the discussion, and it's cynical but probably true:
"The people that USE the software are not the people BUYING the software. It's why all enterprise software has trash UX."
When the person making the purchasing decision doesn't use the product daily, they don't feel the pain of slow loading times and high memory usage. They care about feature checkboxes, security certifications, and pricing.
Microsoft Teams is a perfect example. Everyone I know complains about Teams being slow and clunky. But it keeps winning enterprise contracts because it checks all the boxes that IT departments care about.
The people complaining about Electron on Hacker News are a tiny, vocal minority. They're not representative of the broader market that these companies are serving.
Alternatives Do Exist
The discussion wasn't all doom and gloom. People mentioned several alternatives that try to offer the best of both worlds:
- Tauri - Uses the system's native WebView instead of bundling Chrome. Apps are much smaller (10MB vs 140MB+).
- Wails - Similar to Tauri but for Go developers. One developer in the thread said they built a full app at just 10MB.
- Flutter - Google's cross-platform framework with custom rendering. Not web-based.
- Qt/QML - The old reliable. Cross-platform native UI, but requires C++ knowledge.
But each has tradeoffs. Tauri and Wails rely on the system WebView, which means different browser versions on different machines. Qt requires C++ developers, who are harder to find than JavaScript developers. Flutter still feels slightly "off" on desktop.
There's no perfect solution. If there was, everyone would use it.
The VS Code Exception
One thing that came up repeatedly: VS Code is also Electron, and people love it.
VS Code proves that Electron apps can be performant and well-made. Microsoft invested heavily in optimization. The app feels responsive despite being web technology under the hood.
So the problem isn't Electron itself. It's that most companies don't put in the same level of effort to optimize their Electron apps. They ship the default configuration and call it done.
VS Code is the exception. Most Electron apps are the rule.
My Take
I've used various coding tools - both terminal-based CLIs and Electron apps like VS Code and Cursor. Honestly? The UX difference is noticeable. Terminal apps feel snappier. Native apps feel more integrated with my system.
But I also understand why companies make the choice they do. Web development won because it standardized everything. Same language, same rendering engine, same accessibility features across every platform. That's a massive win for development velocity.
The problem isn't Electron. The problem is that Electron makes it too easy to skip optimization. Why spend weeks profiling memory usage when the app already works? Most teams ship the default config and move on to the next feature. VS Code got fast because Microsoft actually put in the work. Most companies don't.
Maybe AI will change this. Ironic, isn't it? We're using AI coding tools to argue about why those same AI coding tools are built with Electron. Maybe someday an AI will generate optimized native code for each platform automatically.
Until then, the debate continues. And I think that's okay. The developers complaining are pushing the industry toward better standards. The companies shipping Electron are serving users who need features today, not perfection tomorrow.
Both are doing their jobs.
What Do You Think?
I'm genuinely curious. Does app performance matter to you? Have you switched away from a product because it was too slow or bloated? Or do you just care whether it works?
There's no wrong answer. But I'd love to hear where you stand.
Top comments (0)