Chapter 18: Electron and the Web as Native Application Platform

Open your code editor.

If you’re a working developer, it’s probably VSCode (or Cursor, or another Cursor-style fork). The interface is rendered in Chromium. The extensions run in Node. The application that ships as a native binary for macOS, Windows, and Linux is, under the hood, a web application packaged with its own browser engine. You write JavaScript in a JavaScript application that’s running JavaScript to render the JavaScript you’re writing.

If you’re not using VSCode, you’re probably using a different Electron application. Slack. Discord. Notion. Postman. 1Password. The desktop ChatGPT app. The desktop Claude app. Linear. Obsidian. Microsoft Teams. The desktop version of Spotify. Probably half a dozen others, depending on what you do for work.

The desktop software industry has been quietly rebuilt on the browser. Most of the applications you spend your workday inside are web applications — they just happen to ship with their own browser engine instead of using the one you already have installed.

This is the reveal chapter. The argument the rest of this book has been preparing for is that the browser is a serious application platform. The desktop software industry has already concluded the same thing. It just hasn’t said it out loud.

Electron’s Origin

Electron started as Atom Shell.

In 2011, GitHub began building a new text editor called Atom. The project’s goal was to ship a programmer’s editor that felt as customizable as Emacs or Vim but with a modern UI and a contemporary extension model. The team needed a way to build native desktop applications using web technologies — they wanted the UI to be HTML and CSS, the extension language to be JavaScript, and the deliverable to be a real desktop binary that users could install.

The component they built to make this possible was Atom Shell. Cheng Zhao (known online as zcbenz) and a small team at GitHub combined three pieces. Chromium’s rendering and JavaScript engine handled the UI. Node.js — which by this point ran on the same V8 engine that Chromium used — handled the application’s access to the file system, child processes, and operating system. A small native wrapper bound the two together and exposed APIs for windows, menus, system notifications, and other native concerns. The combination meant that an Atom Shell application could render its interface with web technologies while also having unrestricted native access through Node — something a browser page could never do.

Atom shipped publicly in February 2014. Atom Shell was released as a standalone project the same year, and renamed Electron in 2015.

The naming was modest. The implications were not.

Atom, in Retrospect

Atom itself was a respectable text editor. It was extensible, attractive, and had a real community. It was also slow, memory-hungry, and never quite caught up to its competitors on performance. By 2020 it was clearly losing ground to VSCode. GitHub announced Atom’s sunset in 2022, and the project was archived.

Atom’s legacy isn’t the editor. It’s the platform underneath.

Atom Shell was an in-house infrastructure project for a single GitHub product. The decision to release it as open source — to let other companies build their own desktop applications using the same combination of Chromium and Node — was the move that mattered. The combination was already well-engineered, well-documented, and battle-tested by the time anyone outside GitHub started using it. The next few years saw an explosion of Electron-based applications, almost none of which had any direct connection to Atom or its editor design.

This is the kind of inheritance the open-source ecosystem produces well. A project’s stated goal turns out to be less important than the infrastructure it produces in service of that goal. Electron is GitHub’s most lasting contribution to the developer world, and Atom was the vehicle through which it shipped.

VSCode and the Erich Gamma Move

In 2015, Microsoft launched Visual Studio Code.

VSCode was built on Electron from the start. The project was led by Erich Gamma — one of the original Gang of Four design patterns authors (from the 1994 book that defined a generation of object-oriented design), the original Eclipse IDE architect at IBM in the early 2000s, and the lead of Microsoft’s Visual Studio Online product before VSCode. Gamma’s involvement was a signal. Microsoft was putting one of its most senior software architects on a free, cross-platform editor built on a web technology stack. This wasn’t a side project.

VSCode shipped in April 2015 and grew quickly. By 2019, it was the most-used code editor among professional developers, according to the Stack Overflow Developer Survey. By 2024, it had become the de facto default. The IDE wars that had defined developer tooling for thirty years — Visual Studio versus Eclipse versus IntelliJ versus Vim versus Emacs versus Sublime — were over. VSCode had won.

The strategic implication is worth pausing on. Microsoft, the company that had built the most-deployed proprietary desktop software in the world (Windows, Office, Visual Studio Professional), had concluded that the right substrate for its next-generation flagship developer tool was Chromium plus Node plus open source. The same Microsoft that, twenty years earlier, had been the antagonist of the browser wars described in Chapter 6, had made the browser its native application platform.

VSCode also did something Atom never quite managed. It ran fast enough to compete with native editors. The performance work the VSCode team did on Electron applications — language servers running in separate processes, careful management of the renderer-process update loop, aggressive optimization of the DOM operations the editor performed — became the template for the next generation of Electron applications. The framework hadn’t changed. What had changed was that the industry now had a credible example of an Electron application that didn’t feel like an Electron application.

The Expanding Roster

The Electron application list grew through the late 2010s and into the 2020s. A partial inventory of the products built on it:

Developer tools. VSCode, Atom (until it was sunset), Postman, Insomnia, GitHub Desktop, GitKraken, Cursor (the AI-augmented VSCode fork), Tabby, Hyper.

Communication. Slack, Discord, Microsoft Teams, Skype (until its sunset), Element (Matrix-protocol chat).

Productivity. Notion, Obsidian, Linear (desktop client), Asana, Trello, Airtable, Logseq, Roam Research.

Creative. Parts of Adobe’s product line, Figma’s desktop client (though Figma is mostly the in-browser webapp with a thin Electron wrapper).

AI assistants. The desktop ChatGPT app, the desktop Claude app, the Perplexity desktop app, Cursor (mentioned above), Warp Terminal, Raycast.

Specialty. 1Password, Spotify desktop, virtually every modern cryptocurrency wallet’s desktop UI.

The list is incomplete. New Electron applications launch every month, and the share of the desktop software market built this way has been increasing for a decade.

What’s worth noticing about the list is the diversity of categories. Communication, productivity, creative, developer tooling, AI — every major category of modern desktop software has at least one significant product built on Electron. The technology stack is, by 2025, as common in production desktop software as it has ever been in any era of any platform.

The Trade-Offs

The criticism of Electron is real and worth stating honestly.

Electron applications are large. The Chromium engine and Node runtime bundled with the application typically add 150–250 megabytes to the installer. A small Electron application might ship at 200 MB; a feature-rich one at 500 MB or more. Native applications of equivalent functionality might be 5–20 MB. The disk cost is real.

Electron applications use a lot of memory. Each open VSCode window is a fresh Chromium browser process, which means a fresh V8 isolate, a fresh DOM, and the typical 100–300 MB memory baseline that comes with running a browser engine. A developer with five VSCode windows, Slack, Discord, and the desktop Claude app open has, in effect, several copies of Chromium running simultaneously. The memory pressure on developer machines is widely complained about and not always exaggerated.

Electron applications start slowly. Loading Chromium, initializing the renderer, parsing and executing the application’s JavaScript, and rendering the initial UI together can take several seconds on cold start. Compared to a native application written in C++ or Swift, the difference is noticeable.

These are real costs. The reason Electron has won despite them is that the costs are paid by users (who have 16 or 32 GB of RAM and don’t notice another 300 MB application), while the savings are reaped by developers (who write the application once for all three desktop platforms, use a single skill set, and ship features at a much higher cadence than a multi-platform native team could).

The economics, in other words, favored Electron at the moment in computing history — the mid-2010s onward — when desktop machines had become powerful enough that the inefficiencies stopped being noticeable for most users. The native-software purist argument — that this is wasteful, that we used to ship 5MB applications that did equivalent work — is correct on the technical merits and irrelevant on the market merits. Users don’t notice. Companies do.

Tauri and the Lighter Approach

Not everyone is satisfied with the trade-off.

Tauri, started in 2020 and reaching 1.0 in 2022, is an alternative to Electron that takes a different approach to the same problem. Instead of bundling Chromium and Node with every application, Tauri uses the operating system’s native webview — WKWebView on macOS, WebView2 (Chromium-based) on Windows, WebKitGTK on Linux — for rendering, and replaces Node with a Rust backend for native operations.

The savings are significant. A Tauri application typically ships at 3–10 MB instead of 150–250 MB. Memory use is lower (the OS-provided webview is shared with other applications using it). Performance is competitive with Electron and sometimes better.

The trade-offs are different. The application’s web layer has to be compatible with whichever webview the user’s OS provides, which means dealing with cross-engine differences (WKWebView is WebKit; WebView2 is Chromium; WebKitGTK is WebKit). The native backend has to be written in Rust, which has a steeper learning curve than Node for teams used to JavaScript. And Tauri’s ecosystem, while growing, doesn’t yet match Electron’s in plugin count, documentation depth, or sheer number of production applications shipped.

Tauri’s adoption is meaningful but smaller than Electron’s. The bet the Tauri team is making is that the inefficiencies of Electron will eventually matter enough — to users, to enterprises, to environmental discussions, to the kinds of constrained-environment deployments where Electron is a non-starter — to justify the migration cost. The bet is plausible. It hasn’t been validated yet.

The deeper point is that the alternative to Electron is still the web. Tauri’s UI is still HTML, CSS, and JavaScript. It just renders that UI in a smaller container. The web’s status as the substrate for desktop UI isn’t in question — the only question is how to ship it efficiently.

PWAs and Capacitor on Mobile

The same story plays out on mobile, with different specifics.

Progressive Web Apps (PWAs) are web applications that can be installed on the user’s device, run in their own window, and access platform features (notifications, offline, hardware) through the browser’s standard APIs. Google and the broader web standards community pushed PWAs hard through the late 2010s. Apple’s support has been deliberately uneven — iOS supports PWAs but with restrictions that Apple’s competitors have complained about for years, including the limitations the EU’s Digital Markets Act is now addressing.

Capacitor (by the Ionic team) and the older Cordova are frameworks that wrap a web application in a native mobile shell, exposing native APIs to JavaScript. Capacitor applications ship to the App Store and Google Play as native apps, but internally they’re web applications running in a webview — much like Electron on desktop. Ionic itself, the UI framework that Capacitor was originally built to serve, ships components designed to feel native on each platform.

React Native is the major alternative on mobile. Despite the name, it isn’t a webview wrapper — it renders to actual native UI components on each platform — but the developer experience is web-shaped (React components, JavaScript logic), and the reasoning is similar to Electron’s. Write once in a familiar paradigm, ship to multiple platforms. The trade-off is that React Native applications behave less like native apps in some respects (memory model, JavaScript bridge overhead) than Capacitor or even Cordova, but they look and feel more native because the UI components are the system’s own.

The pattern is consistent across mobile and desktop. The web is the development substrate; native shells are the delivery mechanism; the trade-offs vary by platform and by how thick the shell is. What stays constant is that web technologies are the lingua franca of cross-platform UI development, and the industry has settled into this consensus over more than a decade.

The Industry Voted

This is the chapter’s central point, and the rest of this section is just unpacking it.

For thirty years, the conventional wisdom in software was that desktop and mobile applications would be built in native technologies — C++ on Windows, Objective-C and later Swift on Apple platforms, Java and later Kotlin on Android, with native UI toolkits (Win32, Cocoa, GTK, Qt) providing the visual layer. The web was for the web. Desktop software was for desktop platforms. The two were separate, and the boundary was respected.

Electron, Tauri, Capacitor, and React Native are evidence that the conventional wisdom has been overturned. The companies shipping the most-used desktop software — Microsoft, GitHub, Slack, Discord, Notion, Adobe, the entire developer-tools industry, every major AI company, most of the productivity space — have concluded that web technologies are the right substrate for cross-platform UI. They’ve made that choice, not for one product, but for their entire product lines. They’ve made it knowing about the memory costs, the startup costs, the disk costs. They’ve made it because the trade-off is correct given the rest of the constraints they operate under.

If web technologies are the right substrate for desktop software — which is to say, the most performance-sensitive, distribution-sensitive, install-sensitive category of consumer software — then they’re clearly capable of being the right substrate for the actual web. The web that runs in real browsers. The web you ship to users without bundling 200 MB of Chromium first.

This is the platform-first argument the rest of this book builds, made by the industry without saying it out loud. The browser is a serious application platform. It is being used as one, every day, by every developer reading this book. The only remaining question is whether to use it that way inside the browser too — without the Electron wrapper, without the parallel reality the framework imposes, with the platform’s native capabilities directly accessible to the application.

That’s the question Part II of this book takes seriously.

A Note on Ownership

One detail about the Electron / VSCode story is worth surfacing because it shapes the political economy of the broader frontend ecosystem.

GitHub built Electron. Microsoft acquired GitHub in 2018. Microsoft also built VSCode on Electron, and now owns both the most-used Electron application and the underlying framework. The dominant editor for developers and the dominant cross-platform desktop app shell are both, ultimately, Microsoft products.

This isn’t a critique. Microsoft’s stewardship of both projects has been, by open-source standards, respectful. VSCode is open source (under an MIT-licensed core, with Microsoft adding proprietary features in their distributed build). Electron remains independently governed under the OpenJS Foundation. Microsoft contributes generously to both.

The observation is structural. The infrastructure underneath much of modern developer life is concentrated, by a series of acquisitions, in one company. The economic logic of open-source-by-corporate-sponsor produces this outcome again and again. React → Meta. Angular → Google. Next.js → Vercel. SvelteKit → Vercel. Atom and VSCode and Electron → Microsoft. Bun → Anthropic. The frontend ecosystem’s most important tools all sit inside large companies whose interests don’t always perfectly align with their users’.

This isn’t a reason to panic. It’s a reason, alongside the supply-chain story from the previous chapter, to develop a working sense of what depends on what, and to prefer abstractions (decorating, platform-first) whose continued existence doesn’t depend on any single company’s strategic priorities. The platform, governed by W3C and WHATWG and TC39, is the durable substrate. The companies above it come and go.

What Comes Next

Part I of this book has been about the history of frontend abstraction. The next chapter closes the part by examining what the platform itself has been doing during the years the abstraction layers were being built on top of it. Most of the capabilities the abstraction layers were built to provide have, quietly, been absorbed into the platform itself. The browser caught up while we were abstracting it. That’s the hinge that turns Part I into Part II.

Exercise: Inventory Your Desktop

Look at the applications currently running on your computer.

For each one:

1. Is it an Electron application? (You can usually tell from the package.json inside the application bundle, or from the memory footprint if it’s around 200 MB+ for a relatively simple app.)
2. If yes, when was the application originally released? Has it always been Electron-based, or was it ported from a native codebase?
3. If no, is it built on another web-based framework (Tauri, native webview wrappers, React Native equivalents on desktop like Proton)?
4. What’s the closest equivalent native application for the same use case? When was it last updated?
5. If you had to choose between the Electron version and the native equivalent — discounting habit — which would you actually prefer to use? Why?

The point isn’t to convict yourself or your applications of inefficiency. The point is to develop a working sense of how much of the software you use is, in fact, web software running in a custom shell. Once you see the pattern, the rest of this book’s argument lands differently. You’re not being asked to consider whether the browser could be a serious application platform. You’re being asked to take seriously a thing your own day-to-day workflow already depends on.