Electron is a free, open-source framework for building Windows, macOS and Linux desktop applications with JavaScript, HTML and CSS. It combines Chromium with Node.js and desktop APIs. The project operates under the OpenJS Foundation, and its contributor community develops the framework under the MIT license.
Pages inside desktop windows
An Electron project identifies its main script through package.json. That script controls application startup and creates BrowserWindow objects after Electron signals readiness. Each window loads a local HTML file or a remote web address. Chromium displays the page, while CSS controls its appearance and JavaScript handles its interactions.
Application code chooses the window dimensions and reacts to lifecycle events. For example, an activation event can reopen a window, while another handler can quit after the last window closes. Electron leaves these platform conventions to the application. Closing a BrowserWindow also ends its renderer process.
Main, renderer and preload
The main process runs Node.js and controls windows, application events and native desktop operations. Node.js APIs also give this process access to the filesystem. Renderer processes handle the web interfaces in individual windows, and their default environment does not provide direct Node.js access.
A preload script runs before its page begins loading. Developers use it to expose particular desktop functions through contextBridge. Context isolation keeps the preload environment separate from the page’s JavaScript environment. Electron also enables renderer sandboxing by default, which limits direct access to system resources.
Requests across process boundaries
Inter-process communication carries requests between the page and the main process. Developers define channel names and handlers for their application. A one-way message can change a window title. A request that expects a reply can open a native file chooser and return the path the user chooses.
Electron pairs ipcRenderer.invoke with ipcMain.handle for that request-and-response pattern. The preload script exposes a specific wrapper that the page calls. Application code still decides which operations to expose and validates incoming requests. Context isolation alone does not make every function safe to expose.
Menus, dialogs and desktop events
Electron’s main-process modules connect application code to desktop controls. Each module accepts its own configuration and reports user actions through results or events:
- Menus combine labels, keyboard shortcuts, standard roles and custom callbacks. Applications can attach a menu or show a context menu.
- File dialogs accept file-type filters and selection options, then return paths or a cancellation result.
- Tray icons accept an image, tooltip and context menu, placing application controls in the system notification area.
- Notifications accept a title and body. The show method displays the notification, and click events return interaction to application code.
Some controls differ across systems. Windows and Linux file choosers cannot select files and directories together. macOS notifications require the application’s code signature.
Sessions and permissions
A session holds browser state such as cookies, cache and proxy settings. Electron can assign windows to session partitions. Windows that use the same partition share its session. A persistent partition retains browser state, while a partition without the persistence prefix keeps its session in memory.
Permission handlers receive the requesting web content and permission type. Application code returns an approval or denial through a callback. This gives the application a decision point for website capabilities, including notification and screen-capture requests. Session permissions complement the separate controls for sandboxing and context isolation.
Native modules and utility work
Electron applications can use native Node.js modules alongside JavaScript packages. Native modules need a build that matches Electron’s binary interface, target platform and architecture. The rebuild tool recompiles modules for Electron, and Electron Forge uses that tool during development and distribution work.
The utilityProcess module starts a separate Node.js process from a script path and optional arguments. Message ports carry communication with that child process. Applications can move processor-intensive tasks or components that might crash into utility processes, separating that work from the main process.
Inspecting code and crashes
Chromium DevTools opens against a window’s web contents to debug its renderer code. Debugging the main process uses a different connection. Electron exposes the V8 inspector protocol to an external debugger, with an option that pauses execution on the first JavaScript line.
The crashReporter module uses Crashpad to collect crash reports. Developers supply a submission address for server uploads or disable uploads to retain reports locally. A server that accepts Breakpad minidumps can receive these reports. Reporting configuration also accepts additional application-specific annotations.
Turning a project into an application
Distribution combines application code with the Electron runtime. A manual package places the project in the runtime’s resources directory. Alternatively, an ASAR archive holds the application source, and Electron reads that archive when the application starts. Developers can replace Electron’s default executable name and application identity.
Electron Forge supplies separate packaging and distribution tools. Its package operation combines the code and runtime into an application folder. Makers then turn that folder into platform-specific distributables, such as Windows installers, macOS disk images or Linux packages. Code-signing configuration identifies the application publisher on Windows and macOS.
The Mac App Store uses a distinct MAS build that supports Apple’s App Sandbox. That build excludes crashReporter and autoUpdater. Sandbox entitlements also determine which resources the application can access.
Update delivery
The autoUpdater module checks a release feed and downloads an application update when one becomes available. Application code handles the resulting events and can offer a restart to apply it. Developers publish the application release and its metadata through static storage or an update server.
Electron provides this updater on Windows and macOS; Linux applications use an external update mechanism such as their distribution’s package manager. macOS automatic updating requires an application signature. Framework updates reach an application’s users when its developer incorporates the newer runtime and distributes an application update.
