跪拜 Guibai
← Back to the summary

Electron Isn't a Shell Browser: The Dual-Process, IPC, and Native API Architecture That Runs VS Code and Figma

Prerequisite Basics: Three Core Concepts for Understanding Electron

Before diving into Electron, let's lay the groundwork with three core concepts to build your foundational understanding:

  1. The Natural Boundary of Web Technology: The Browser Sandbox Regular HTML/CSS/JS code can only run within the browser's sandbox environment — for security, the browser strictly limits web pages' access to operating system resources. For example, a web page cannot directly read or write local files, invoke global shortcuts, or modify system configurations. This is both the security advantage of web applications and the core limitation that prevents them from replacing desktop applications.

  2. Two Technological Cornerstones: Chromium and Node.js

    • Chromium: The open-source browser kernel project by Google, which mainstream browsers like Chrome and Edge are based on. It is responsible for parsing HTML, rendering pages, and executing JS scripts, providing full Web standard API support. Its core capability is "rendering the interface."
    • Node.js: A server-side JS runtime based on the Chrome V8 engine, allowing JS code to run directly on the operating system outside the browser. It has built-in system-level capabilities like file system, network, and process management. Its core capability is "calling system resources." These two were originally completely independent runtime environments, each with its own role, with no intersection.

  3. The Core Pain Point of Traditional Desktop Development Before Electron, developing a Windows application required C#/WPF, a macOS application required Objective-C/Swift, and a Linux application required C++/GTK. A single product needed to maintain three sets of technology stacks and codebases, leading to high development costs, slow iteration speeds, and extreme unfriendliness to frontend developers.

Electron's core value is to resolve the above contradictions — integrating Chromium and Node.js into a single runtime system, allowing a cross-platform desktop application with full system capabilities to be developed using a single web technology stack.

image.png

I. Core Definition and Overall Architecture of Electron

1. Definition

Electron is an open-source, cross-platform desktop application development framework created by GitHub. It allows developers to build desktop applications that run on Windows, macOS, and Linux using only web technologies like HTML, CSS, and JavaScript. Simply put, Electron is like packaging a customized browser kernel and a Node.js runtime into desktop software, giving web pages all the system capabilities of a desktop application.

2. Underlying Principles

Electron uses a three-layer core architecture, where the three layers work together to complete the entire chain from page rendering to system calls:

The three have clear divisions of labor: Chromium manages interface rendering and interaction, Node.js manages general system calls, and the native adaptation layer manages desktop-specific capabilities and cross-platform compatibility.

3. Concrete Example

A minimal Electron application requires only 3 core files:

  1. package.json: Project configuration file, specifying the application entry point and dependencies.
  2. main.js: Main process entry code, responsible for creating the application window.
  3. index.html: The frontend page loaded by the window.

Core code example for the main process entry:

    // Import Electron main process modules
    const { app, BrowserWindow } = require('electron')

    // Create the main window after the application is initialized
    app.whenReady().then(() => {
      const mainWindow = new BrowserWindow({ width: 800, height: 600 })
      mainWindow.loadFile('index.html') // Load the frontend page, starting the renderer process
    })

After running the above code, an 800×600 desktop window will pop up, rendering the custom HTML page inside — this is a most basic Electron application.

4. Application Scenarios

Electron's core value is lowering the barrier to cross-platform desktop development. Typical applicable scenarios include:

image.png

II. The Dual-Process Runtime Model

1. Definition

The dual-process model is the most core runtime mechanism of Electron. It divides an application into two types of processes with completely isolated responsibilities:

2. Underlying Principles

The dual-process design is not original to Electron but is inherited from Chromium's multi-process security architecture: to prevent a single page crash from causing a total application crash and to prevent malicious web pages from stealing system resources, the browser places each tab in an independent sandboxed process. Electron follows this design philosophy:

The core differences between the two can be intuitively compared in the following table:

Comparison Dimension Main Process Renderer Process
Quantity Globally unique 1 per window, supports multiple instances
Core Responsibility Application lifecycle, window management, native capability calls Page rendering, UI interaction, frontend business logic
Runtime Environment Node.js + Electron Native API Chromium Sandbox Environment
System Privileges Full system privileges No system privileges by default, requires indirect calls
Crash Impact Causes the entire application to crash Only the current window is abnormal, does not affect the whole

3. Concrete Example

Take Discord, a chat application built on Electron, as an example:

4. Application Scenarios

The design goal of the dual-process model is to ensure stability and security. Core application scenarios include:

image.png

III. Inter-Process Communication (IPC) Mechanism

1. Definition

IPC stands for Inter-Process Communication. It is the core mechanism in Electron for passing data and calling methods between the main process and renderer processes. Because the two processes have isolated memory and privileges, they cannot directly call each other's functions and must complete data interaction through an IPC channel.

Electron provides two core IPC modules:

Two key terms are added here:

2. Underlying Principles

The underlying layer of IPC is based on Chromium's inter-process communication pipeline, using an event-driven, asynchronous communication model:

  1. The sender sends a request to the other process by specifying an event name with attached parameter data.
  2. The receiver pre-listens for the corresponding event name and executes the corresponding logic upon receiving the request.
  3. The receiver can return the processing result to the sender via a callback or Promise.

Based on the communication pattern, it is divided into two common methods:

3. Concrete Example

Take the "save file" function of a desktop notepad as an example. The complete communication flow is as follows:

  1. In the preload script, securely expose the save file interface to the renderer process:
// preload.js (Preload Script)
const { contextBridge, ipcRenderer } = require('electron')
contextBridge.exposeInMainWorld('electronAPI', {
  saveFile: (content) => ipcRenderer.invoke('save-file', content)
})
  1. In the main process, listen for the save request and call the file system to write the file:
// main.js (Main Process)
const { ipcMain } = require('electron')
const fs = require('fs')

ipcMain.handle('save-file', async (event, content) => {
  fs.writeFileSync('note.txt', content)
  return 'Save successful'
})
  1. The frontend page clicks a button and calls the exposed interface to trigger the save operation:
// Renderer process frontend code
document.querySelector('#saveBtn').addEventListener('click', async () => {
  const content = document.querySelector('#editor').value
  const result = await window.electronAPI.saveFile(content)
  alert(result)
})

Throughout the entire process, the frontend page cannot directly call the fs module. It can only initiate requests through a predefined whitelist interface, and the main process completes the system operation, all under security control.

4. Application Scenarios

IPC is the "neural network" of an Electron application. All cross-process interactions rely on it. Typical scenarios include:

image.png

IV. Native Capability Invocation and Cross-Platform Compatibility

1. Definition

Electron has a built-in, complete native API system. Developers do not need to write native code like C++/Objective-C; they can call the operating system's native functions using only JS, and it automatically adapts to the three major platforms of Windows, macOS, and Linux, eliminating the need for separate development for different systems.

2. Underlying Principles

Electron's native capabilities are implemented in three layers, balancing generality and extensibility:

3. Concrete Example

Take the system notification function as an example. Full-platform native adaptation can be achieved with just a few lines of code:

// Main process code
const { Notification } = require('electron')

new Notification({
  title: 'Task Complete',
  body: 'The file has been successfully exported to the desktop'
}).show()

On Windows, this code will call the system notification center to pop up a notification; on macOS, it will call the system notification bar. The style perfectly matches the native design of each system, and the developer does not need to do any platform adaptation. Besides this, common desktop features like tray icons, file drag-and-drop, system theme adaptation, and auto-start on boot all have corresponding single-line APIs.

4. Application Scenarios

Native capabilities are the core hallmark that distinguishes Electron from a "webpage shortcut." Typical application scenarios include:

image.png

Common Misconceptions

  1. Misconception: Electron is just a "shell browser" with no technical depth. In reality, Electron's underlying layer involves complex technical fields like Chromium customization, process scheduling, security sandboxing, cross-platform native adaptation, and performance optimization. An Electron application with a good user experience needs to solve a large number of engineering problems such as memory optimization, startup speed, white screen issues, security hardening, and native interaction adaptation. It is by no means a simple shell.
  2. Misconception: Electron applications are always laggy and have high memory usage. High memory usage is an inherent characteristic of the Chromium kernel, but it is not unoptimizable. Unoptimized Electron applications do tend to have high memory usage, but after reasonable optimization (reducing the number of renderer processes, frontend lazy loading, memory leak management), an application can run smoothly with memory controlled within a reasonable range. Lag issues mostly stem from unreasonable frontend code, not Electron itself.
  3. Misconception: Renderer processes can directly use all Node.js APIs. Early versions of Electron allowed renderer processes to directly enable Node.js integration, but for security reasons, Electron 12+ versions enable context isolation and sandbox mode by default. Renderer processes cannot directly access Node.js APIs. Directly disabling security configurations brings serious risks; if an XSS vulnerability appears on a frontend page, an attacker could directly gain full system privileges.
  4. Misconception: Electron can only make simple tools and cannot support complex applications. In reality, large, complex applications like VS Code (code editor), Figma Desktop (design tool), Discord (instant messaging), and Slack (enterprise collaboration) are all built on Electron. They carry complex business logic, high-performance rendering, and massive user bases, fully capable of supporting heavy-duty desktop application scenarios.

Actionable Practical Advice

Getting Started

Security Standards (Must Follow)

Performance Optimization

Packaging and Publishing

image.png