Stop Shipping Browsers Disguised as Apps

Something is broken in the way major software companies think about desktop apps. We're talking about companies pulling in tens or hundreds of billions in revenue per year, and they're shipping desktop applications that are, under the hood, a full web browser rendering a glorified webpage. That's what Electron is. That's what you're running when you open Slack, Discord, Teams, or a dozen other apps you probably use every day.

When a scrappy five-person startup picks Electron to ship on three platforms with one codebase - fine. That's pragmatism. When Microsoftslop does it, that's something else entirely. That's a company with effectively unlimited engineering resources choosing to give you a worse product because it's organizationally convenient.

Applications from big tech companies should be native. Built with Swift and AppKit on macOS. Built with WinUI or Win32 on Windows. Built with GTK or Qt on Linux. And I don't think this is some niche opinion or retro-computing nostalgia. The arguments are practical, and they stack up fast.

Discord: why I dread opening it

Let me get personal here. I don't enjoy using Discord. And it's almost entirely because of Electron.

Which is frustrating, because as a product, Discord is great. Voice channels, threading, communities, screen sharing, bots, integrations - it's a really well-designed platform. But every single time I open it, I'm reminded that it's a website in a window. It eats 500+ MB of RAM doing nothing. It takes seconds to launch. The scrolling is just slightly off - not broken, just... not right. Not the smooth, weighted feel of a native scroll view. Text input feels like a browser form field. Keyboard shortcuts conflict with my OS. Context menus are clearly custom web elements that look out of place next to everything else on my screen.

And here's the thing that really gets me: Discord is built for real-time communication. Voice. Video. Low-latency interaction. And they chose the heaviest, most overhead-laden application framework they could have picked. Staying on Electron isn't a constraint. It's a choice. And it makes the product worse every single day I use it.

What Electron actually is - and what it costs

For those who haven't dug into this: Electron was originally built by GitHub for the Atom text editor (now discontinued - draw your own conclusions). It lets you build desktop apps with HTML, CSS, and JavaScript. Sounds great until you realize that every Electron app bundles an entire copy of Chromium - Chrome's engine - plus a Node.js runtime. Every single app. Its own private Chrome.

A bare-minimum Electron app, one that just puts "Hello World" on screen, weighs around 150–200 MB. A native macOS app doing the same thing? A few hundred kilobytes. That's not a rounding error. That's a 500x to 1000x overhead for doing literally nothing.

At runtime it gets worse. An idle Electron app sits at 150–300 MB of RAM. A native equivalent: maybe 10–30 MB. Now think about how many Electron apps you have running right now. Slack. Discord. Maybe VS Code. Maybe Notion or Figma. Each one is its own copy of Chromium. I've seen machines with five separate Chromium instances running, eating 4+ GB of RAM, and the user hasn't even started working yet.

And then there's CPU. Chromium was designed for the open web - it sandboxes everything, runs multiple processes, does garbage collection on a schedule that makes sense for a browser. None of that overhead makes sense for a chat client. But you're paying for it anyway, in CPU cycles, in fan noise, in heat.

"Just buy more RAM" is not an argument

The most common pushback you hear is that hardware is fast enough now, so who cares? This falls apart pretty quickly.

Nobody runs one Electron app. You run three, four, five of them at once. The overhead isn't just additive - once you start hitting memory pressure, the OS starts swapping, and everything slows down. Your native apps get dragged down too. One badly behaved Electron app can make your whole machine feel sluggish.

Laptops exist. Most professionals work on laptops. Every wasted CPU cycle is battery life you don't get back. Benchmarks consistently show Electron apps using 2–5x more energy than native equivalents for the same tasks. Ditching Slack + Notion + Figma + VSCode for native alternatives can buy you an extra 30–60 minutes of battery per charge. That's not trivial when you're on a flight or in a coffee shop without an outlet.

Not everyone has a nice machine. Students, people in developing countries, employees at companies that refresh hardware every five years - they all feel Electron's bloat way more than someone on a brand-new M4 MacBook Pro. Well, such situation was before 2025-26. Now we're all fucked. When Teams needs a gig of RAM just to show you some text messages, that's effectively raising the hardware requirements for basic office communication. It's software-driven planned obsolescence, and big companies are the ones doing it.

It wastes the hardware you already paid for. You bought 32 GB of RAM to run VMs, or edit video, or handle big datasets. Not so that five chat apps could comfortably lounge around in memory. Electron eats headroom that you purchased for your own work.

The UX gap is real, even if you can't name it

Performance aside, there's a qualitative difference between native apps and Electron apps that most people feel but struggle to articulate.

Platform conventions matter more than you think

macOS has its own way of doing things. Text fields support Emacs keybindings. Windows have specific resize and snap behaviors. The Services menu exists. Handoff works. Windows has its own patterns too - Jump Lists, Snap Layouts, proper taskbar integration.

Electron apps violate all of this. They draw their own title bars. Their own context menus. Their own scrolling. You end up with an app that's almost native-looking, which is somehow worse than if it looked completely foreign - it sets up expectations it can't deliver on. You can't always put your finger on why an app feels off, but your brain notices. Every mismatched animation, every slightly-wrong scroll deceleration curve, every context menu that doesn't match the rest of your OS - it adds up into a vague sense that something isn't right.

Accessibility is worse. Period.

Native frameworks - AppKit, UIKit, WinUI - have decades of accessibility work baked in. VoiceOver, Narrator, Orca: they all work well with native controls because the OS vendors built them together. Electron's accessibility story has improved, sure, but it's still a second-tier experience. Screen readers stumble. Keyboard navigation has gaps. High-contrast modes don't always work right. For companies that put "accessibility" and "inclusion" in their corporate values, shipping Electron is a quiet contradiction.

Text looks wrong

This one is subtle but it drives me nuts. macOS renders text through Core Text, which prioritizes the shape of the letters. Windows uses DirectWrite, which prioritizes sharp edges on lower-DPI screens. Both are carefully tuned for their platform. Electron uses Chromium's Skia renderer, which was tuned for neither. Text in Electron apps looks a little too blurry on Windows, a little too crisp on macOS. It's never quite right. You might not notice it in isolation, but put an Electron app next to a native one and the difference is obvious.

Startup time

Open a native app: it's there, basically instantly. The binary is already compiled, the UI framework is loaded by the OS, there's almost nothing to do. Open an Electron app: it boots Chromium, spins up V8, parses a JavaScript bundle, renders a DOM, and then maybe you see a usable window. That's 2–8 seconds. For something like a messaging app that you open and close throughout the day, those seconds add up to real time lost.

The economics don't actually favor electron (at Scale)

The pitch for Electron is simple: one codebase, three platforms, ship it with your existing web team. For a startup, the math checks out. For Microsoft or Salesforce? Not so much.

These companies already have native expertise

Google has massive native teams for Android and Chrome OS. Apple obviously builds native everything. Microsoft... well, they also can build native apps between fixing vulnerabilities in new Windows updates. Salesforce acquired Slack for $27.7 billion. The idea that these companies "can't afford" to build native apps is laughable. They choose Electron because it's organizationally simpler - one team, one codebase, less coordination. That's a management preference, not an engineering constraint.

"Write once, run everywhere" quietly becomes "write once, patch everywhere"

Any Electron app of real complexity ends up with a ton of platform-specific code anyway. Auto-updates work differently on each OS. Native menus, system tray, notifications, file system access, credential storage - all of it needs platform-specific handling. The Electron team has said that something like 30–40% of bugs filed against the framework are platform-specific. The cross-platform promise erodes fast.

There are better cross-platform options

It's not Electron or three separate native codebases. Qt, Flutter, Kotlin Multiplatform, .NET MAUI - these all let you share significant amounts of code while still rendering with native or near-native performance. They require more skill than Electron, but we're talking about companies with billions in revenue. The incremental cost is a rounding error against the improvement in user experience.

The Security Problem

Here's something that doesn't get enough attention: every Electron app ships its own copy of Chromium, and Chromium has over 35 million lines of code. It's one of the largest and most complex software projects in existence, which means it has a huge attack surface. Security vulnerabilities in Chromium are found regularly.

Chrome itself handles this through fast, automatic updates. But Electron apps update on their own schedule - and that schedule is often weeks or months behind the latest Chromium patches. So you might be diligent about keeping Chrome updated, but you're still running three or four older, unpatched copies of Chromium inside your Electron apps without even knowing it.

Native apps don't have this problem. They use the OS's own UI framework, which gets patched through the system update mechanism. One update channel, managed by the OS vendor. Much simpler, much safer.

The counter-arguments

I want to be fair about these.

"Web developers are easier to hire." True in general. Irrelevant for companies with tens of thousands of engineers and the resources to recruit literally anyone. This is a startup argument, not a big-tech argument.

"Electron lets you iterate faster." Somewhat true early on. Less true over time as platform-specific patches pile up. And speed of iteration only matters if you're converging on something good. Electron puts a ceiling on how good the product can be.

"Users don't actually care." Users care about speed. They care about battery. They care about things "feeling right." They just don't express those preferences in terms of UI frameworks. Every user satisfaction survey I've seen shows people prefer apps that feel native. They care about the outcomes of this decision even if they've never heard the word "Electron."

"PWAs will fix this eventually." Maybe. Someday. But they can't access half the system APIs desktop apps need, they perform worse than native, and "it'll be better in the future" is not a justification for shipping bloatware today.

The bottom line

Companies that have the money and the people to build native apps should build native apps. It's that simple. Respect your users enough to not waste their hardware. Take your sustainability commitments seriously enough to not burn electricity at power-plant scale on framework overhead. Back up your accessibility promises with native controls that actually work with screen readers. Hold yourselves to the engineering standards you claim to represent.

Electron makes sense for prototypes, for small teams, for apps where reach matters more than polish. It does not make sense as the permanent foundation for flagship products from companies that could easily do better.

We've spent twenty years watching software get slower while hardware gets faster, and mostly it's because the software got lazier, not more capable. Users tolerate it because they have no alternative - but tolerance isn't the same as satisfaction. Every native app that ships pushes back against that trend, even if only a little.

Here's the bar: if your company makes over a billion dollars a year and your app is used daily by millions of people, that app should be native. No exceptions. No excuses.