Spend enough time on Hacker News or Reddit and you will eventually see the same criticism: Electron is bloated, Electron uses too much memory, and serious desktop applications should be native.
There is some truth behind that criticism. Electron applications generally have a larger baseline footprint because they ship Chromium and Node.js. A carefully engineered native application can use less memory, launch faster, and integrate more deeply with its operating system.
But this debate focuses too much on the computer and not enough on the company building the software.
For most users, the technology behind an application barely matters. They care whether it works, whether it feels responsive, whether bugs get fixed, and whether useful features keep appearing. For a software company, one of the most important properties of a technology stack is therefore something that rarely appears in benchmark tables: how quickly can the team build, ship, learn, and improve the product?
For many modern desktop applications, Electron is exceptionally good at that.
The scarce resource is engineering time
The idealized native desktop company has an excellent macOS team, another team building the Windows application, and perhaps another team supporting Linux. Every application is carefully optimized for its platform and every engineer deeply understands the operating system they work on.
Most companies do not have that luxury.
A desktop product might have five engineers. It might have two. Those same engineers need to build features, fix bugs, improve performance, respond to customers, maintain infrastructure, deal with operating-system changes, and keep the product moving forward.
Native development makes this harder because macOS, Windows, and Linux are genuinely different platforms. They have different UI frameworks, APIs, permission systems, lifecycle behavior, installers, update mechanisms, notification systems, window management, accessibility APIs, and years of platform-specific quirks.
Electron changes that equation. It combines Chromium, Node.js, and desktop APIs into a shared application model across macOS, Windows, and Linux. The same TypeScript engineer can often build a feature from interface to application logic and ship it on every desktop platform. Native code remains available when it is genuinely needed, but it becomes the exception rather than the foundation of the product. Electron itself describes this as one of its core advantages: one JavaScript codebase across all three major desktop platforms.
That difference compounds over years. If every meaningful feature requires separate Mac and Windows implementations, the company pays that platform tax repeatedly: every feature, redesign, experiment, bug fix, accessibility improvement, and performance optimization.
With Electron, much of that work happens once.
Electron optimizes for iteration speed
Products rarely become great because the first implementation was perfect. They become great through iteration.
A team ships something. Customers use it. The team learns. It changes the feature. More people use it. Another problem becomes visible. The team improves it again.
The shorter the loop between idea, implementation, feedback, and improvement, the faster a product gets better.
Electron is unusually good at shortening that loop because it is built around technologies software companies already use everywhere: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js, and npm.
That means companies can share much more than source code. They can share engineers, UI components, tooling, libraries, infrastructure, testing approaches, and institutional knowledge between their web and desktop products.
A frontend engineer does not suddenly become irrelevant because the company needs help with the Windows client. A desktop engineer can contribute to the web application. A full-stack TypeScript engineer can move between products as priorities change.
For a small or medium-sized company, that flexibility can be worth far more than saving 100 MB of RAM.
Look at who actually uses Electron
Electron is sometimes described as a shortcut for companies unwilling to invest in a “proper” desktop application. The products built with it make that argument increasingly difficult to sustain.
Electron’s own project highlights products such as Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom, and Canva. These are not simple utilities. Many are among the most sophisticated and widely used productivity applications in the world.
Visual Studio Code is a particularly useful example. Microsoft could build its flagship code editor with practically any Windows technology it wanted, yet VS Code uses Electron across Windows, macOS, and Linux. It includes terminals, debugging, language servers, Git integration, remote development, notebooks, extensions, and highly customized editors.
The interesting question is not whether Microsoft could save memory by building three separate native versions. Of course it could.
The better question is whether VS Code would have evolved as quickly, remained as consistent across platforms, and developed such a large ecosystem if every major capability required several separate implementations.
ChatGPT and Claude show the difference in approach
The contrast between ChatGPT and Claude is also instructive.
OpenAI initially built a dedicated native macOS application for ChatGPT. Anthropic, by contrast, built Claude Desktop on Electron and had a shared desktop foundation across platforms from the beginning.
That difference became more important as the products expanded. Claude Desktop could keep adding capabilities such as MCP integrations, extensions, and Claude Code into the same cross-platform application. Anthropic now supports Claude Code directly inside its desktop experience, including multiple local and remote sessions.
OpenAI later moved its newer cross-platform desktop direction toward Electron as well, and Electron now lists both ChatGPT and Claude among prominent Electron applications.
It would be too strong to claim that Electron alone explains the difference in product velocity. Team size, priorities, product strategy, and internal organization all matter. But the architectural advantage is straightforward: a shared cross-platform foundation makes it easier to ship features across operating systems without maintaining separate implementations.
That is exactly the kind of advantage that becomes more valuable as a desktop product grows.
Evernote learned the cost of maintaining separate clients
Evernote is one of the clearest historical examples of this problem.
For years, Evernote maintained different applications across Mac, Windows, mobile, and the web. Over time, those products accumulated different behaviors, rendering differences, legacy assumptions, and synchronization problems.
In 2020, Evernote rebuilt its Windows and Mac applications around a shared codebase. The company said the new foundation would make the apps more stable, allow bugs to be fixed faster, let features ship more frequently, and improve synchronization across platforms.
That migration was not painless, and some long-time users disliked the initial loss of platform-specific features. But the reason Evernote undertook such an expensive rewrite is more interesting than the migration problems themselves.
Once a product has a rich editor, offline storage, search, attachments, collaboration, tasks, calendars, and complex synchronization, maintaining several independent implementations becomes increasingly expensive. Bugs behave differently. Rendering differs. Sync logic interacts with different local architectures. Every meaningful product change has to propagate through several clients.
A shared architecture does not make hard problems disappear. It allows the company to solve more of them once.
Linux may be Electron’s most underrated advantage
Linux makes the case for Electron even stronger.
Supporting Linux properly is hard. Unlike macOS or Windows, “Linux desktop” is not one tightly controlled platform. Developers have to deal with different distributions, package formats, desktop environments, graphics stacks, system libraries, and display protocols.
For many software companies, the rational business decision would simply be not to support Linux.
Electron changes the economics.
Because Electron provides a common runtime across macOS, Windows, and Linux, adding Linux support can be dramatically easier than maintaining a separate native Linux implementation. This is one reason Linux users today have access to many major desktop applications that historically might never have received an official Linux client.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian, and many other tools can support Linux without maintaining an entirely separate GTK or Qt application.
Electron also absorbs a lot of Linux-specific complexity on behalf of application developers. A good example is the move from X11 to Wayland. Electron’s maintainers have described how Chromium’s Wayland transition effectively brought Electron applications along with it, reducing the amount of display-stack work each application team had to do independently.
Without frameworks like Electron, many companies would not build native Linux clients. They would simply support macOS and Windows and leave Linux users with a browser tab.
Electron has probably done more for commercial Linux desktop software than it gets credit for.
Even Microsoft increasingly chooses web technology
Microsoft is perhaps the strongest counterexample to the idea that serious Windows software should always use native Windows UI frameworks.
Microsoft controls Windows. It controls Win32, .NET, WinUI, WebView2, and much of the platform developers build on. If fully native Windows development were always the obvious answer, Microsoft would be in the best possible position to use it everywhere.
It does not.
Visual Studio Code uses Electron. Teams remains built around React, TypeScript, and Chromium even after Microsoft replaced Electron with a more optimized WebView2 host. The new Outlook for Windows also relies heavily on web technology, and Microsoft explicitly describes that architecture as a way to improve agility, enable faster feature delivery, and create a more consistent experience.
Teams is especially instructive. Microsoft wanted to improve performance and reduce resource consumption, so it changed the architecture. But it did not rewrite the UI as a traditional Windows-native application.
It kept the web stack and optimized around it.
That distinction matters. Microsoft decided that the organizational advantages of React, TypeScript, and Chromium were worth preserving even while aggressively improving performance.
There is another lesson here too. Microsoft itself has introduced many generations of Windows application technology over the years: Win32, WPF, UWP, WinUI, and others. A company choosing “native Windows” is not necessarily choosing a timeless platform. It is often making a bet on one generation of Microsoft’s preferred framework.
The web platform has, somewhat ironically, become one of the more stable application targets available.
Hiring is part of architecture
Framework choices also determine who you can hire.
JavaScript and TypeScript developers represent one of the largest engineering talent pools in the industry. A company building with Electron can recruit from that pool instead of requiring separate teams of experienced macOS, Windows, and Linux specialists.
Native specialists remain valuable. Serious desktop products still need engineers who understand operating systems deeply. But Electron changes how many specialists you need.
Instead of requiring most of the application to be built by platform experts, you can keep a relatively small amount of native integration code and let the majority of the team work on the shared product.
This matters even more when a company already has a web application. React components can sometimes be shared. TypeScript libraries can be reused. Product logic can move between web and desktop. Engineers can switch teams without learning an entirely different ecosystem.
Hiring also becomes less fragile. If the only engineer who deeply understands your native Windows client leaves, replacing that expertise can be difficult. With Electron, much more of the codebase uses technologies familiar to the rest of the organization.
A framework therefore does not merely determine how an interface is rendered. It affects how the engineering organization itself can be structured.
Native does not automatically mean better software
Developers often use “native” almost as a synonym for “fast.”
It is not.
Native APIs give developers the opportunity to create a very efficient application. Whether the final product actually achieves that depends on the architecture, team, budget, and amount of optimization work the company can afford.
A native application can still be slow, buggy, memory-hungry, inconsistent, or poorly maintained.
More importantly, splitting a limited team across several native implementations means each implementation receives fewer engineering hours.
Imagine a company has six engineers available for its desktop product. One option is to divide them between Mac and Windows, perhaps leaving Linux unsupported. Another is to put almost all six engineers onto one shared Electron application serving all three platforms.
Which approach gives the company more engineering capacity to improve startup time, fix memory leaks, polish interactions, improve accessibility, reduce crashes, and respond to users?
It is not obvious that the native applications produce the better product.
This creates an interesting paradox: a framework that consumes somewhat more machine resources can allow a company to build a better-optimized product because it consumes far fewer engineering resources.
Electron gives you a controlled platform
Electron also has another advantage that is easy to overlook: it ships the Chromium runtime the application was built and tested against.
That removes a major variable from cross-platform development.
Frameworks based on operating-system webviews can produce smaller applications, but the trade-off is that the same frontend may run on WebView2 on Windows, WKWebView on macOS, and WebKitGTK on Linux. Those engines have different capabilities, bugs, release schedules, and rendering behavior.
Electron makes a different trade: bundle the runtime and make it part of the application.
Yes, that costs disk space.
But it gives developers a much more consistent target across three very different operating systems.
Consistency has enormous engineering value.
When Electron is not enough, you can still go native
Choosing Electron does not mean giving up access to native capabilities.
Electron applications can use native modules and platform-specific code where necessary. That means the architectural choice is not really:
100% native or 100% JavaScript.
For many products, a better model is:
most of the application shared, with a small amount of native code where the operating system genuinely requires it.
Native code becomes an escape hatch rather than the foundation of the entire product.
That is a much better allocation of engineering effort for many companies.
Users care about products, not frameworks
There is a small group of technically sophisticated users who open Activity Monitor, notice several Chromium processes, and immediately complain that an application uses Electron.
Most users do not.
They do not care that Slack uses Electron. They do not care that VS Code is built with web technologies. They do not know what framework Claude uses. They care whether the software helps them get their work done.
If an application launches quickly enough, feels responsive, rarely crashes, and solves the user’s problem, the implementation technology is largely invisible.
The reverse is equally true. A native application does not automatically become a good product because it uses Swift or WinUI.
Software competes at the product level, not at the framework level.
Optimize the company, not just the binary
Electron has real costs. It uses more disk space. Its baseline memory footprint is usually higher than that of a small native application. There are absolutely products where those costs make Electron the wrong choice.
A tiny menu-bar utility probably does not need Chromium. A device driver certainly does not. Games, professional audio software, and extremely latency-sensitive applications have different requirements. And if your product will only ever run on one operating system, native development becomes much easier to justify.
But a huge percentage of modern desktop software is not in those categories.
It consists of complex interfaces connected to cloud services. It needs to run on Windows and macOS, and increasingly users expect Linux support too. It needs to evolve continuously. It competes with products shipping changes every week. And it is usually built by a company with a finite number of engineers.
For those products, developer productivity is part of application performance.
Electron lets a company hire from a much larger talent pool, share engineers between web and desktop, maintain one primary application instead of several, reuse the JavaScript ecosystem, ship features across operating systems more consistently, support Linux at a cost that would otherwise often be difficult to justify, and spend more engineering time improving the product instead of maintaining parallel implementations.
You can easily measure Electron’s cost in megabytes.
The alternative costs are harder to see. They appear as additional engineers, duplicated implementations, longer release cycles, platform-specific bugs, hiring difficulties, organizational silos, unsupported Linux users, and features that take months longer to reach everyone.
Those costs do not appear in Activity Monitor.
But for the company building the software, they may be considerably larger.
The goal of software development is not to produce the smallest binary.
It is to build the best product your organization can ship, maintain, and continuously improve.
For a surprisingly large class of desktop applications, Electron remains one of the most efficient ways to do exactly that.