Electron: what it is and why it eats so much RAM

⏱️ Reading time: 11 min

A 15-second clip racked up 2.3 million views this week: Discord’s new client, written in Rust, loads the friends list before the current Electron-based version finishes showing its loading screen. Both started cold, on the same laptop, at the same time. According to the video shared by Discord CTO Stanislav Vishnevskiy, the new client uses just 290 MB of RAM with two accounts active at the same time.

📑 En este artículo

1. TL;DR
2. What is Electron?
3. Why the Electron framework uses so much RAM
4. How Electron works under the hood
5. Practical examples: your first app with the Electron framework
6. Getting Started
7. Comparison: Electron, Tauri, and WebView2
8. Real use cases
9. Common mistakes and best practices
10. Going deeper
11. Frequently Asked Questions
    1. Is Electron the same as an embedded browser?
    2. Why did Discord switch from Electron to its own Rust client?
    3. Does Tauri completely replace Electron?
    4. What apps use WebView2 instead of Electron?
    5. How much RAM does switching from Electron to Tauri actually save?
12. References

To understand why that’s news, you first need to look at what the Electron framework is and why every application that uses it, from Discord to Slack and VS Code, ends up dragging an entire browser along with it. And what alternatives, like Tauri or WebView2, exist to avoid paying that price in memory.

TL;DR

• Electron bundles a full Chromium and Node.js into every app, which is why it weighs hundreds of MB at idle.
• Discord’s Rust client uses 290 MB with two active accounts, about 70% less than the usual 1-2 GB.
• Tauri swaps Chromium for the system’s native engine, shrinking the final binary to a few megabytes.
• contextBridge isolates the renderer from Node.js without blocking inter-process communication.
• Migrating from Electron to Tauri or WebView2 means rewriting the native layer, not just changing the packaging.

What is Electron?

Electron is an open-source framework, released by GitHub in 2013, for building desktop applications with HTML, CSS, and JavaScript. Every program built with the Electron framework bundles its own copy of Chromium and Node.js, which explains why these apps weigh so much in RAM compared to a native app.

The original idea was simple: if you already know how to build a website, you can package it as a desktop app without learning Swift, C++, or C#. Electron was born inside GitHub to build the Atom editor, and today it’s used by VS Code, Slack, Notion, WhatsApp Desktop, and, until now, Discord.

Why the Electron framework uses so much RAM

A normal browser (Chrome, Edge, Firefox) runs once on your system, and every tab shares that single base process. The Electron framework shares nothing between apps: each application brings its own embedded Chromium, with its own V8 JavaScript engine, its own graphics compositor, and its own Node.js runtime for accessing the file system or the network.

If you have Discord, Slack, and VS Code open at the same time, you’re not running three lightweight apps: you’re running three full copies of Chromium in parallel, each with its own baseline memory footprint before rendering a single pixel of interface. To confirm this, open Windows Task Manager, find the app’s executable (for example Discord.exe) and expand the entry: you’ll see a parent process and several child processes, one for each window or internal tab the app opens. That tree is Chromium multiplying inside your RAM.

According to the Windows Latest report, a Discord employee had noted back in December 2025 that normal use of the Electron app stays under 1 GB, and that the company was testing an automatic restart once it hit 4 GB. The new client’s 290.2 MB, with two active sessions, lands roughly 70% below that 1 GB floor.

How Electron works under the hood

Electron splits its execution into two kinds of processes. The main process runs in pure Node.js, has full access to the operating system (files, network, native menus), and is the only one that can create windows. Each window in turn opens a renderer process, which is basically an isolated Chromium tab with no direct access to Node.js for security reasons.

Communication between the two goes through IPC (inter-process messaging). So the renderer can ask the main process for something without exposing all of Node.js to it, Electron recommends a preload script using contextBridge, which exposes only the specific functions the interface needs.

graph TD
    A["Main process (Node.js)"] --> B["Renderer: window 1 (Chromium)"]
    A --> C["Renderer: window 2 (Chromium)"]
    B -. "IPC" .-> A
    C -. "IPC" .-> A

Electron’s official process model documentation details this separation. Each dotted arrow in the diagram is an ipcRenderer.invoke call in the renderer that the main process answers with ipcMain.handle.

sequenceDiagram
    participant R as Renderer (HTML/JS)
    participant P as Preload (contextBridge)
    participant M as Main (Node.js)
    R->>P: window.api.getVersion()
    P->>M: ipcRenderer.invoke("get-version")
    M-->>P: process.versions.electron
    P-->>R: Promise resolved with the version

Practical examples: your first app with the Electron framework

This app opens a window, loads a simple HTML file, and passes a piece of data from the main process to the renderer without exposing Node.js directly. First, the main process, in main.js:

const { app, BrowserWindow, ipcMain } = require('electron');

function createWindow() {
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: __dirname + '/preload.js',
      contextIsolation: true,
      nodeIntegration: false
    }
  });
  win.loadFile('index.html');
}

ipcMain.handle('get-version', () => process.versions.electron);

app.whenReady().then(() => {
  createWindow();
  console.log('App ready, window created');
});

When you run npm start, the terminal literally prints App ready, window created and an 800×600 pixel window opens. Now preload.js, the only file with one foot in Node.js and the other in the browser:

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('api', {
  getVersion: () => ipcRenderer.invoke('get-version')
});

And the renderer, which runs inside the HTML without ever seeing Node.js:

window.api.getVersion().then((version) => {
  document.getElementById('version').textContent = `Electron ${version}`;
});

The text on screen changes from empty to something like Electron 38.0.0 (the version installed on your machine). That’s exactly the separation described in Electron’s context isolation documentation: the HTML never touches require(), it only calls the specific function the preload script decided to expose.

Getting Started

Required dependencies: Node.js 18 LTS or higher and npm (bundled with Node). The commands are identical on Windows (PowerShell or cmd), macOS, and Linux, because npm doesn’t change across systems.

mkdir hello-electron
cd hello-electron
npm init -y
npm install --save-dev electron
npm pkg set main=main.js
npm pkg set scripts.start="electron ."

Then you create main.js, preload.js, and index.html with the code from the previous section, and run:

npm start

Expected output: an 800×600 window opens with the text Hello Electron and, below it, the installed version; the terminal shows the line App ready, window created.

Comparison: Electron, Tauri, and WebView2

flowchart TD
    subgraph Electron
    E1["Own Chromium"] --> E2["Own Node.js"]
    end
    subgraph Tauri
    T1["System WebView"] --> T2["Rust backend"]
    end
    subgraph WebView2
    W1["Shared Edge WebView2"] --> W2["C# or C++ backend"]
    end

Real use cases

VS Code, Slack, Notion, and WhatsApp Desktop still run on Electron today. So does Discord’s current client, although the company has already publicly shown off its Rust replacement: it’s not an app built with Tauri, it’s a proprietary engine, but it solves the same problem Tauri tackles, avoiding the duplicated Chromium copy.

Microsoft, for its part, rebuilt the modern version of Teams using WebView2 instead of Electron: it shares the Edge rendering engine already running on the system instead of bundling its own. The savings don’t come from a configuration trick, they come from not loading a second full browser per application.

💭 Key takeaway: neither Tauri nor WebView2 eliminates Chromium entirely: they share it between apps instead of duplicating it. The RAM savings come from that reuse, not from some magically lighter engine.

Common mistakes and best practices

• nodeIntegration: true in the renderer: exposes all of Node.js to the app’s HTML, enough for an injected script to read files or run system commands.
• Skipping contextIsolation: without isolation, the preload script and the page share the same JavaScript environment, and any third-party library can touch the exposed functions.
• Not closing BrowserWindow when a task is done: every unclosed window keeps running its full Chromium process in the background.
• Updating Electron sporadically: every new version brings Chromium’s security patches; falling behind means running a browser with already-known vulnerabilities.

Going deeper

Every Chromium renderer process reserves memory for its own V8 heap, its own graphics compositor, and its own security sandbox before interpreting a single line of the app’s HTML. That baseline cost is independent of the content: an empty window and a window with a complex interface both start from the same memory floor.

Tauri avoids that floor because it doesn’t bring its own browser: on Windows it uses WebView2 (the same engine as Edge), on macOS it uses WKWebView (WebKit), and on Linux it uses WebKitGTK. The Electron framework, by contrast, fixes Chromium as the single engine across all three systems, which gives total visual consistency in exchange for paying the RAM cost. That’s precisely the trade-off with Tauri: you gain size and memory, but your interface may render with small differences between WebKit on macOS and WebView2 on Windows, something a small team without time for cross-platform QA might not notice until a user reports a misaligned button.

Your next step: clone the example from this guide, run it with npm start, and then open Task Manager to count how many child processes a single window creates.

Frequently Asked Questions

Is Electron the same as an embedded browser?

It’s more than that: besides Chromium as its rendering engine, it includes a full Node.js runtime so the app can access files, network, and operating system APIs, something a normal browser doesn’t allow a web page to do.

Why did Discord switch from Electron to its own Rust client?

According to the Windows Latest report, the goal was to eliminate the 5-to-10-second loading screen and lower RAM usage; Discord’s team confirmed that the new client, internally named Phoenix, updates in the background without that step.

Does Tauri completely replace Electron?

Not in every case: Tauri requires writing native logic in Rust and has fewer ready-made plugins than Electron, so it’s better suited for new projects where size matters from the start, not necessarily for migrating a large, already-mature Electron app.

What apps use WebView2 instead of Electron?

The modern version of Microsoft Teams is the best-known example: it reuses the Edge engine that Windows already has running instead of bundling its own Chromium.

How much RAM does switching from Electron to Tauri actually save?

There’s no universal figure: it depends on how many windows the app opens and how heavy its interface is. What’s verifiable is the mechanism, not reserving a second browser engine, and that can be confirmed by looking at the process tree in Task Manager or Activity Monitor.

References

• Windows Latest: report on Discord’s Rust client and its RAM usage compared to Electron.
• Official Electron documentation: main and renderer process model.
• Official Electron documentation: context isolation and contextBridge.
• Tauri: official website of the framework that uses the system’s native webview.
• Microsoft Learn: official WebView2 documentation.
• Wikipedia: history and origin of the Electron framework at GitHub.

📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion

Featured image: Foto de Fotis Fotopoulos en Unsplash