cloudparts

Electron

A framework for Windows, macOS and Linux apps written in HTML, CSS and JavaScript, which ships its own copy of Chromium and Node.js inside every app; Visual Studio Code runs on it.

OpenJS · Impact
Type
Open source
Foundation
OpenJS Foundation, impact, joined December 2019. Part of the Linux Foundation
License
MIT
Facts checked
28 October 2026

What it is

An Electron app is a small browser with Node.js built in. Each app bundles a full Chromium and a Node.js runtime, so the same HTML renders the same way on every operating system, whatever web view the system has. It follows Chromium’s multi-process model. The main process runs in Node.js: it creates windows with BrowserWindow, owns the app’s lifecycle and provides menus, dialogs and tray icons. Each window’s page runs in its own renderer process, like a browser tab, so one crashed page doesn’t take the app down. UtilityProcess starts extra Node.js processes for crash-prone or CPU-heavy work.

Renderers are treated as untrusted web pages. They have no access to require or other Node.js APIs; context isolation has been on by default since Electron 12, and renderers have been sandboxed by default since Electron 20. A preload script, which runs before the page loads, uses contextBridge to expose a narrow API, typically functions that send messages to the main process over IPC. Electron Forge, the project’s own tool, packages and publishes apps; third-party tools such as electron-builder do the same.

A new major version comes out every eight weeks, after four weeks of alpha and four of beta, and each tracks a recent even-numbered Chromium. Electron 45, stable on October 20, 2026, ships Chromium 156 and Node.js 24.22; only the latest three stable majors get fixes, so a version is supported for about six months. The project is run by nine working groups, covering areas such as API design, releases, security and Chromium and Node.js upgrades.

Why teams pick it

  • One rendering engine everywhere: the app ships its own Chromium, so there is no testing against three different system web views
  • The full Node.js runtime and npm in the main process, alongside native menus, tray icons, dialogs and auto-update
  • Proven in large apps: VS Code is built on it, Slack and GitKraken were early users, and Electron Forge handles packaging and publishing
  • Secure defaults for new apps: renderers are sandboxed and context-isolated, and reach the system only through APIs the preload script exposes

Watch out for

  • Size: every app carries its own Chromium and Node.js, about 100 MB for a default app according to Firezone’s comparison, against a few megabytes for a Tauri app
  • Each window is a Chromium renderer process, so memory use is that of a browser per app
  • Fast support window: with a major every eight weeks and only three supported, an app has to upgrade Electron, and the Chromium in it, about every six months to keep getting security fixes
  • Exposing too much through the preload script or loading remote content with Node.js access undoes the sandbox; the security model depends on keeping the bridge narrow

Alternatives

What all cross-platform desktop apps have in common →Compare side by side →

How it fits with other technologies

A window whose page can ask the main process for the app version · js

// main.js: the main process, running in Node.js
const { app, BrowserWindow, ipcMain } = require('electron/main');
const path = require('node:path');

app.whenReady().then(() => {
  ipcMain.handle('get-version', () => app.getVersion());
  const win = new BrowserWindow({
    webPreferences: { preload: path.join(__dirname, 'preload.js') },
  });
  win.loadFile('index.html');   // the page runs in a sandboxed renderer
});

// preload.js: runs before the page, exposes one function and nothing else
const { contextBridge, ipcRenderer } = require('electron/renderer');
contextBridge.exposeInMainWorld('desktop', {
  version: () => ipcRenderer.invoke('get-version'),
});

// in index.html’s script:
//   document.title = `My app ${await window.desktop.version()}`;
//   typeof require  // 'undefined': the page has no Node.js access

See it in a real stack

No architecture uses Electron yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2013–2026

Electron began at GitHub as Atom Shell, the framework the Atom editor was built on: a way to build a desktop app with web technology by combining Chromium with Node.js. GitHub released it alongside Atom, renamed it Electron on April 23, 2015, and shipped 1.0 on May 11, 2016, by which time it had been downloaded more than 1.2 million times in a year and was running apps such as Slack and GitKraken. Microsoft built Visual Studio Code on it, previewing the editor in 2015.

As more companies came to depend on it, the project wrote down its governance in 2019 and moved away from being owned by one company. The OpenJS Foundation accepted it into incubation at Node+JS Interactive in Montreal in December 2019, and it graduated directly to Impact in June 2020. Today it is maintained by people from several companies and independent contributors, organised into working groups, and its eight-week release cadence keeps it close to Chromium’s security fixes.

Why it’s built this way

Bundle Chromium instead of using the system web view
Shipping the same engine with every app means pages look and behave identically on Windows, macOS and Linux, and new web features are available everywhere at once, at the price of download size.
Node.js in the main process
Pairing Chromium with Node.js gave web developers file, process and network access in the language they already used, along with npm’s packages.
Sandbox renderers and isolate contexts by default
Early Electron gave pages full Node.js access, so a script injected into a page could take over the machine. Context isolation (Electron 12) and sandboxing (Electron 20) make renderers behave like browser tabs, reaching the system only through the preload bridge.
Release every eight weeks, tracking Chromium
Every app embeds a browser engine, so it needs Chromium’s fixes quickly. Moving to a new Chromium every eight weeks keeps the engine recent, and supporting only the latest three majors keeps the number of lines to patch small.

Timeline

  1. 2013

    Created at GitHub as Atom Shell, the base of the Atom editor

  2. 2015

    Renamed Electron on April 23; VS Code previewed on it

  3. 2016

    Electron 1.0 on May 11

  4. 2019

    Governance written down; enters OpenJS incubation in December

  5. 2020

    Graduates to an OpenJS Impact project in June

  6. 2022

    Electron 20 sandboxes renderers by default

  7. 2026

    Electron 45 ships on October 20 with Chromium 156

Sources9 · facts checked 28 October 2026

Improve this page on GitHub