Electron - Chrome Wrapped Around Your Web App

Electron is what happens when you take a web browser and duct-tape it to Node.js. GitHub built it for Atom editor back when they thought text editors needed to be written in web technologies. Atom is dead now, but Electron survived because it solved a real problem: web developers want to build desktop apps without learning C++.

Chrome's multi-process architecture that Electron inherits

The Technical Reality

The Electron Stack:

┌─────────────────────────────────────┐
│           Your Web App              │  ← HTML, CSS, JavaScript
├─────────────────────────────────────┤
│            Node.js API              │  ← File system, OS APIs
├─────────────────────────────────────┤
│         Chromium Browser            │  ← V8 engine, rendering
└─────────────────────────────────────┘

Here's what you're actually getting:

• Chromium: A full Chrome browser bundled with your app
• Node.js: Runtime that gives you filesystem access and system APIs
• Your web app: Running inside this browser with superpowers

Bottom line: web developers can finally build desktop apps without learning a new language. Sure, they're bloated memory hogs, but at least you don't have to deal with Xcode and Visual Studio project files. The multi-process architecture inherited from Chromium means you get process isolation for free.

Why Every Process Matters (And Why It Breaks)

Electron borrows Chrome's process model, which sounds great until you start debugging:

• Main Process: Your app's brain. When this crashes, everything dies. Handles window management, app lifecycle, and native APIs.
• Renderer Processes: Each window is basically a browser tab. These crash individually, which is actually helpful. Each runs its own Chromium instance with context isolation.
• Utility Processes: Background stuff that breaks in mysterious ways. Handle heavy computation without blocking the UI.

Electron Process Model:

Main Process (Node.js)
├── Manages app lifecycle
├── Creates BrowserWindows
└── Controls renderer processes
    │
    ├── Renderer Process 1 (Chromium)
    │   └── Window with your web app
    │
    ├── Renderer Process 2 (Chromium)
    │   └── Another window/webview
    │
    └── Utility Processes
        └── Background tasks

The process isolation means when your renderer crashes with `Maximum call stack size exceeded`, your main process keeps running. Until it doesn't, and you have no idea why. Check the DevTools and crash reporter for clues.

Current Status (And Version Hell)

Electron 38.0.0 dropped September 2, 2025, packing Chromium 140.0.7339.41 and Node.js 22.18.0. They follow Chromium's insane 8-week release cycle, which means your build breaks every couple months when they update. Check the release timeline to see what's coming.

Real apps built with Electron that you actually use:

• VS Code - Microsoft's editor that somehow doesn't suck. Hits 600MB, maybe 800MB with extensions
• Discord - Gaming chat that eats your RAM. Try the memory debugging guide when it hits 2GB
• Slack - Corporate messaging that makes your laptop sound like a jet engine. Memory consumption issues will drain your battery
• Figma - Design tool that convinced everyone browsers are fine for heavy apps. Uses WebGL for rendering

These work because they have massive teams optimizing the hell out of them, or they naturally do web-friendly stuff. Your side project won't have Microsoft's resources. Trust me on this one.

Popular Electron Apps You Use Daily:

• VS Code, Discord, Slack, Figma, Notion, Postman, GitHub Desktop
• WhatsApp Desktop, Signal, Element, Hyper Terminal
• All consuming 200-500MB each while pretending to be "native" apps

Apps That Actually Work (And Why)

Let's talk about the Electron apps you actually use and why they don't suck:

Development Tools

• VS Code - Microsoft threw a huge team at making this fast. Uses native modules for heavy lifting and extension sandboxing for security
• GitHub Desktop - Simple enough that Electron doesn't get in the way. Open source so you can see how they did it, with detailed architecture docs
• Postman - API tool that needs cross-platform more than speed. Collection sharing justifies the overhead, built with custom Electron optimizations

Communication Apps

• Discord - Works because voice/video is handled natively. Text chat is just React in a box, with Go microservices handling the heavy lifting
• Slack - Corporate users can't choose their tools anyway. Engineering blog shows they optimize heavily, with dedicated performance teams fighting the Electron bloat
• Microsoft Teams - See above, plus Microsoft muscle. Uses WebRTC for calls and native module integration for OS features

Creative Tools

• Figma - Proved browsers can handle heavy graphics work. Uses WebAssembly for performance, complex multi-threading, and optimized vector rendering
• Notion - Database views would be hell in native code. Block-based architecture fits web paradigms, with real-time collaboration over WebSockets

See the pattern? These either have armies of engineers making them fast, or they're doing stuff that fits web tech naturally. Your note-taking app doesn't have VS Code's 1,500+ contributors working on it.

Development Tools That Lie to You

Electron Forge: Works great in tutorials but breaks the moment you need something custom. The templates are fine until you add native dependencies, then you're debugging node-gyp compilation hell at 3am wondering why Python 2.7 is suddenly required on your machine.

electron-builder: More powerful but assumes you're already an expert. Windows builds fine, macOS fails with cryptic errors about missing entitlements. The GitHub issues become your actual docs because the official ones skip the painful parts.

Deployment Horror Stories

Code Signing on macOS: Apple's notarization is pure hell. Spend three days getting certificates working, then watch your build sit at "notarization in progress" for 6 hours with zero feedback. The entitlements.plist file will break your soul - one wrong boolean and the whole thing fails silently.

Auto-Updater Failures: Works great in dev, dies in prod. Users stuck on versions from three months ago while you figure out why your update server suddenly returns 404s. Squirrel.Windows and Squirrel.Mac behave differently because fuck consistency, right?

Platform-Specific Bugs:

• Windows Defender flags your installer as malware for zero reason. SmartScreen thinks your note app is a bitcoin miner
• Linux AppImage works on Ubuntu, crashes on Fedora. FUSE isn't installed by default and users don't know what that means
• macOS users get "app isn't properly signed" errors even though Apple's notarization worked. Gatekeeper is moody as hell

Bundle Size Reality: Your hello world is 150MB. Users will ask why your text editor is bigger than Photoshop. You'll mumble something about "cross-platform compatibility" while they uninstall it. asar compression saves like 20MB if you're lucky. Check electron-builder optimization docs for marginally better results.

Bundle Size Reality Check:

Hello World App Sizes:
┌─────────────────┬──────────────┐
│ Native (C++)    │     2-5 MB   │
│ Swift/Obj-C     │     5-15 MB  │
│ Qt              │    20-50 MB  │
│ .NET            │    30-80 MB  │
│ Electron        │   150-300 MB │ ← Your \"simple\" app
└─────────────────┴──────────────┘

VS Code casually using 400MB+ with a few files open

Electron Forge Build Process:

The Electron Build Hell Pipeline:

Source Code
    ↓ TypeScript/Babel compilation
Main Process Bundle
    ↓ webpack/esbuild bundling  
Renderer Process Bundle
    ↓ Native module compilation (💀 HERE BE DRAGONS)
Platform-Specific Packaging
    ↓ Code signing (🔥 ABANDON HOPE)
Distributables
    ↓ Upload to servers
    ↓ Auto-updater config
Broken deployment ← You are here

1. Source Code → TypeScript/JavaScript compilation
2. Main Process → Bundle with webpack/esbuild
3. Renderer Process → Web app bundling
4. Native Dependencies → node-gyp compilation (where it breaks)
5. Platform Packaging → Different for Windows/Mac/Linux
6. Code Signing → Certificate hell, especially on macOS

Discord eating 2GB+ RAM because it's just "a browser tab"

Security Reality

Electron's security docs list 20+ recommendations. Here's what actually happens in the real world:

Context Isolation: Should isolate your preload scripts from web content. Great in theory, breaks your shit in practice. 54% of apps just disable it because the alternative is spending weeks debugging why `window.electronAPI` is undefined.

Preload Scripts: The "secure" way to expose APIs. contextBridge is confusing and every tutorial shows the wrong way first. You'll waste a day figuring out why your IPC calls return undefined.

Content Security Policy: Should use strict CSP. Won't, because it breaks everything and you have deadlines. CSP bypasses exist anyway so it's mostly theater.

Security Gotchas That Will Bite You

Remote Code Execution: One XSS vulnerability and attackers own the user's machine. One bad `eval()` in your renderer = game over. This isn't theoretical - it happens to real apps constantly.

Node.js Integration: Should be disabled in renderers. You'll enable it anyway because disabling breaks everything and you don't have time to learn proper IPC patterns. 50% of apps do this.

Resource Loading: Should only load HTTPS. Your app breaks behind corporate proxies, so you add cert exceptions and create security holes because users can't wait for IT to fix their network.

Outdated Dependencies: Electron bundles specific Chromium and Node versions. When CVEs drop, you're stuck waiting for Electron to update. Could be weeks or months. 79% of apps are running outdated Electron with known vulnerabilities.

VS Code's complex process architecture after enabling sandboxing - this is what it takes to make Electron secure

Electron Security Architecture Components:

Secure IPC vs Reality:

How it SHOULD work:
Renderer → contextBridge → preload script → ipcRenderer → Main Process

How it ACTUALLY works in your app:
Renderer → window.require('electron') → Main Process
         ↑ (because context isolation broke everything)

• Main Process: Trusted, has full system access, manages everything
• Renderer Processes: Sandboxed (if you enable it), limited API access
• Preload Scripts: Bridge between main and renderer with contextBridge
• Context Isolation: Separates your preload from web content (breaks everything)
• Node.js Integration: Should be disabled in renderers (but you'll enable it anyway)

Performance Reality

"Optimized Electron apps are as fast as native" is complete bullshit. Here's what actually happens:

Memory Usage: Your "optimized" app still eats 300MB+ doing nothing. VS Code with extensions hits 1GB. Users notice when their MacBook turns into a space heater running a fucking text editor. Check memory profiling tools for debugging.

Startup Time: Native apps start instantly. Your Electron app takes 3 seconds to boot Chrome, load your bundle, and actually show something. Users will complain. Lazy loading strategies barely help.

Battery Life: Chrome drains batteries like crazy. Your app does too. Users will uninstall it when they realize their 2-hour meeting turned into 45 minutes of battery life. Power profiling in DevTools shows the ugly truth.

Debugging Hell

DevTools: Great for web debugging, useless when your file dialog doesn't show up on Linux. Good luck debugging that. Remote debugging works sometimes.

Process Crashes: Main process dies silently. Renderer crashes show white screens. Users report "broken" with zero useful details. crash-reporter module helps if configured right.

Platform Differences: Works on your Mac. Crashes on Windows. Nobody knows why. Cross-platform is still a joke. Check platform-specific issues on GitHub.

Development Workflow Reality

Electron Forge vs electron-builder: Both suck. Forge is simple but breaks with custom needs. electron-builder is powerful but config hell. Pick your poison.

Hot Reload: Works until it doesn't. You'll restart 50 times a day when hot reload shits itself for no reason. webpack-dev-server integration helps sometimes.

Native Dependencies: Need a native module? Get ready for node-gyp compilation hell across three platforms. Windows needs Visual Studio Build Tools. Try explaining that to your designer.

The Electron Development Cycle:

1. Write code → Everything works in development
2. Package for production → Build breaks mysteriously
3. Fix build issues → Different error on each platform
4. Deploy → App crashes on user's machine
5. Debug remotely → No useful error messages
6. Repeat → Welcome to Electron development