Electron

Electron is the framework that lets teams ship native-feeling desktop applications for macOS, Windows, and Linux using ordinary web technology. It fuses a Chromium rendering engine with a full Node.js runtime into a single process model split between a privileged main process and one or more sandboxed renderer processes, giving developers direct access to OS-level APIs (menus, notifications, filesystem, auto-updates, native dialogs) from the same JavaScript, HTML, and CSS skills used to build for the browser.

Originally built at GitHub to power Atom, Electron now underpins some of the most widely used desktop software in the industry, including Visual Studio Code, Slack, and Discord. Its two-process architecture, IPC bridge, and context-isolation model are the reference implementation most competing desktop frameworks are still measured against.

What You Get

• A dual-process architecture: a privileged Node.js main process that owns app lifecycle and OS access, plus sandboxed Chromium renderer processes for UI
• A typed, versioned IPC layer (ipcMain/ipcRenderer, contextBridge) for safely exposing native capabilities to untrusted web content
• Native OS integration APIs out of the box: BrowserWindow, Menu, Tray, dialog, notifications, global shortcuts, auto-updater, and crash reporting
• Cross-platform packaging targets for macOS, Windows, and Linux from a single codebase, with code-signing and notarization hooks
• Security primitives (context isolation, sandboxing, permission handlers) purpose-built for embedding remote or untrusted web content safely
• A predictable 8-week major release cadence tracking upstream Chromium and Node.js versions, with three actively supported major versions at any time

Common Use Cases

• Shipping a cross-platform desktop client for an existing web application (e.g. Slack, Discord-style companion apps)
• Building developer tools and IDEs that need native filesystem, terminal, and extension access (e.g. VS Code, Postman)
• Wrapping internal admin or ops tooling into a distributable desktop app with auto-update instead of relying on a hosted web dashboard
• Creating creative or productivity software that mixes native OS chrome (menus, trays, multi-window) with rich HTML/CSS UI

Under The Hood

Architecture: Electron’s process model splits execution into a single privileged main process (lib/browser) that owns the app lifecycle, window management, and native OS bindings, and one or more sandboxed renderer processes (lib/renderer, lib/sandboxed_renderer) that host Chromium and untrusted web content; lib/common and lib/preload_realm supply shared code and the context-bridge boundary between the two, while lib/utility and lib/worker back auxiliary service and worker processes. Communication crosses process boundaries exclusively through the IPC layer defined in lib/browser/ipc-main-impl.ts and lib/common/ipc-messages.ts, and native functionality is exposed to JavaScript via C++ bindings in shell/ compiled through BUILD.gn, making the repo simultaneously a large C++ Chromium-embedding project and a TypeScript API surface.

Tech Stack: The bulk of the codebase by byte count is C++ (Chromium/V8 integration) and TypeScript (the public electron API surface in lib/browser/api and lib/renderer/api), with the npm/ directory holding the thin published package (index.js, cli.js, install.js) that downloads prebuilt native binaries rather than shipping source. Builds are driven by GN/Ninja (BUILD.gn, filenames.gni) alongside a large Python and Node.js script suite in script/ for patch application, filename generation, and CI orchestration; TypeScript compiles under strict mode per tsconfig.json with path-mapped internal modules (@electron/internal/*).

Code Quality: The spec/ directory contains roughly 85 dedicated spec files (api-app-spec.ts, api-browser-window-spec.ts, etc.) covering nearly every public API individually, run against real Chromium/Node binaries rather than mocks, which is unusually thorough for a project of this scope. Linting is enforced via oxlint/oxfmt plus a custom script/lint.js covering JS, docs, and Chromium-roller consistency, and noUnusedLocals/strict TypeScript settings are enabled project-wide; CONTRIBUTING.md documents an active, structured issue-triage and PR review process.

API Design: The public API (documented per-module under docs/api/, 81 reference pages) follows a consistent Node.js-style pattern of EventEmitter-based objects (app, BrowserWindow, ipcMain) with predictable getter/setter and on/once conventions, and the contextBridge/ipcRenderer pair gives a deliberately narrow, explicit mechanism for crossing the security boundary rather than ambient globals. Onboarding has real friction, though: getting a first window on screen requires understanding the two-process split, IPC, and preload scripts before writing any UI code, which is reflected in the extensive tutorial section under docs/tutorial/.