I dedicated years bringing web technologies and desktop apps closer together. The most recent and most successful project in that vein is Electron, which I've spent the last ten years working on.

As an open source project, our website never had to "convince people" to use Electron, so I never took the time to actually explain why I'm betting on web technologies to build user interfaces or why I prefer bundling a rendering engine.

Electron's choices, especially the very idea of building interfaces with web tech and shipping large parts of Chromium to render them, are not uncontroversial. Reasonable people wonder why we made those choices. Operating systems already have user interface libraries. In those libraries is usually also some kind of WebView, often actually based on Blink (Windows) or WebKit (macOS, many Linux distributions). Why go through all that trouble of bundling parts of Chromium? And, even if we go through that trouble, why do so many apps (Visual Studio Code, Slack, Discord, Figma, ChatGPT, Claude, Notion, 1Password, Docker Desktop, and many more) go along with it?

I finally took the time to write down the arguments for the choices that we made. You can find that document on the Electron homepage. It tries to pre-empt a lot of common misconceptions. This post is a pairing suggestion —and discusses some of the things I believe people get most wrong about Electron on the Internet today.

Electron pits JavaScript versus native code

The argument: JavaScript isn't the right choice for everything. Native is better. Electron is not native.

This misconception is likely the fault of Electron's maintainer team and especially me. Most of the talks I've given in the earlier days of Electron highlighted its ability to interact with the operating system from JavaScript.

However, the entire point of Electron is that you can pair your web app with any native code you want to write—specifically with C++, Objective-C, or Rust. Some apps (like mine) only reach for native code when I want to use native UI components, offload some particularly processing-intensive work, or use a native dependency like SQLite. Other apps, like 1Password, have most of their code written entirely in Rust.

Electron's proposition is for developers to mix and match. Writing an app that uses primarily OS-native UI libraries will always be more fun and productive in XCode or Visual Studio, but Electron's superpower is that you can combine HTML for your UI with as much native code as you feel like.

Demos are often easier to follow than long step-by-step tutorial, so I've created an example repository that features a simple "todo app interface" implemented in SwiftUI, GTK, and Win32 using Swift, Objective-C, Objective-C++, and C++.

Web apps are bad

The argument: All native apps are better than all web apps. Any given web app would be better as a native app.

You can obviously feel that way, but the market does not reflect that sentiment. Software ate the world, and then the web ate software. Bad apps are bad—and plenty of web apps are bad, for sure—but some of the most-used, most-purchased, and most-loved apps are web apps.

My personal take is that web technologies make up the most successful, versatile, and capable UI stack out there today. To take it straight from my Why Electron document: "NASA’s actual Mission Control is written with web technologies. The Bloomberg Terminal, the computer system found at every financial institution, is written with web technologies and runs inside Chromium. It costs $25,000 per user, per year. The McDonald’s ordering kiosk, powering the world’s biggest food retailer, is entirely built with Chromium. The SpaceX’s Dragon 2 space capsule uses Chromium to display its interface."

Nothing is without tradeoffs, web technologies aren't perfect, and well-built native applications using operating system-native UI libraries can be works of art. However, assertions that web apps are inherently inferior and that web apps are only written by people who couldn't bother to learn native technologies is at best ignorant and at worst lacking empathy with the requirements and constraints, and in turn with end users empowered with choice.

Operating System WebViews are more performant

The argument: macOS, Windows, and most Linux distributions ship with a built-in WebView primitive. That WebView is "better" than the latest version of Chromium.

Before moving eventually to Electron, the first versions of Slack's desktop app used built-in WebViews on macOS through a framework called MacGap, which sounded great (and was, in fact, ahead of its time):

These Apps run in OS X's WebView and take advantage of WebKit technologies. MacGap exposes a JavaScript API for OS X integration, such as displaying native notifications or writing data to a file. MacGap is extremely lightweight and nimble; a blank application weighs less than 1MB.

All UIWebViews run in a single process, which ends up using less CPU and Memory when directly compared with Electron. However, when running the actual Slack web app, users would report slow performance. Whatever the user wanted to do, it'd be faster in Chrome. Eventually, Apple moved towards a multi-process architecture with shared utility processes as popularized by Chrome et all with WKWebView. This "catch up" game remains – the very best web app rendering engines and runtimes can be found in our best browsers. Operating system WebViews will eventually catch up — but I have yet to see them ahead.

In other words, I have not seen data that proves that built-in WebViews perform better than Chromium. Naively, it seems unlikely to me that an operating system-bundled renderer would beat the best available renderer code out there, as long as the most funding goes towards optimizing browsers. It's not inconceivable: Apple, Microsoft, or another operating system provider might eventually build a browser stack that blows Chromium out of the water.

The operating system has, in theory, the ability to share some resources between all applications using a WebView. In practice, many resources remain strictly isolated to the owning app, largely for security purposes. As a result, I have yet to see a benchmark that shows that an interactive app (think GMail, Notion, Figma, Loom, Slack) perform better in a built-in WebView than in the latest version of Chromium.

But: You might be surprised to hear that performance is not the primary reason why many Electron developers prefer a bundled engine. The primary reason is allowing developers to control the stability, security, and reliability of their applications independently from a WebView that's tightly coupled with the operating system and therefore out of their control.

Bundle size matters

The argument: End users prefer apps that are 5 MB over apps that are 200 MB.

Most Electron apps clock in around 100 to 300 MB. From first principles, smaller is obviously better. Nobody argues that a bigger app is better than a smaller app.

But: Users, both in the consumer and business space, do not care. One hour of Netflix at 4K is roughly 7 GB, a typical Call of Duty update regularly clocks in more than 300 GB. In practice, we have not seen end users care about binary size more than they do about virtually anything else your engineering team could spend time on.

Defeating Electron

In the past, I've written about how Electron only exists because a small group of people passionate about building desktop apps feels like they need to build a framework to enable them to build the kind of apps they want to build. Noticeably, the end goal is to build desktop apps, not to build a framework to do so. This still remains true.

Electron isn't here to compete with anyone. It's a free open source community effort filling a gap. If you want to defeat Electron, you will need to fill it too; and you will need to do a better job than Electron is doing today — at the things that allow us to deliver a good experience. Many of the Electron maintainers are here to build desktop apps that end users love. If you succeed in helping them with that difficult task by building a better platform, they will smile, shake your hand, and thank you.