Electron Isn't a Shell Browser: The Dual-Process, IPC, and Native API Architecture That Runs VS Code and Figma
Electron remains the fastest path from a web codebase to a desktop binary with system-level privileges, but the security model is unforgiving: disabling context isolation or exposing `ipcRenderer` directly turns any XSS into a remote code execution. Teams shipping Electron apps need to treat the preload script as a hard permission boundary, not a convenience layer.
Electron integrates a customized Chromium kernel and a Node.js runtime into a single package, bridging the gap between the browser sandbox and the operating system. A main process holds full system privileges and manages the application lifecycle, while each window runs in an isolated renderer process that only accesses Web APIs. This architecture prevents a single page crash from taking down the entire application and keeps third-party code sandboxed.
Communication between the two process types happens over an IPC channel using `ipcMain` and `ipcRenderer`, with a preload script and context isolation acting as the mandatory security boundary. All system calls — file writes, notifications, tray icons — must pass through this whitelisted bridge, which blocks a frontend XSS from escalating into full OS compromise.
Electron's native API layer wraps Win32, Cocoa, and GTK behind uniform JavaScript calls, so a single `Notification` constructor produces a platform-appropriate alert on Windows, macOS, and Linux. The framework powers VS Code, Figma, Discord, and Slack, disproving the assumption that it can only handle lightweight tools. Performance problems in Electron apps almost always trace back to unoptimized frontend code or too many renderer processes, not to the framework itself.
Electron's architecture is Chromium's multi-process security model repurposed as an application stability pattern — the same isolation that stops a malicious webpage from owning the browser also stops a buggy plugin from crashing Discord.
The framework's security posture is entirely opt-out, which means the most dangerous configuration is also the one that feels most familiar to a Node.js developer: just letting the renderer `require('fs')` directly.
Electron's reputation for bloat is partly a category error: people compare it to native toolkits, but the real comparison is to shipping an entire browser engine, which is what every modern desktop app that embeds web views does.
Calling Electron a 'shell browser' misses that the hard engineering problems — cross-platform native bindings, process lifecycle coordination, and security boundary enforcement — are the same ones any desktop framework has to solve, just with a different language binding.