+ +

The Electron Problem

+

Electron is everywhere. VS Code, Discord, Slack, Figma — some of the best desktop apps in the world are built with it. And for good reason: you write one web app, and it runs on macOS, Windows, and Linux. The developer experience is fantastic.

+

But there's a cost. Every single Electron app bundles its own copy of Chromium. That's not a shared system library — it's a full copy of Chrome, embedded inside your app. A simple todo app? 150MB on disk. A chat app? 200MB. A complex tool like VS Code? Over 300MB.

+

And it's not just disk space. Each Electron app spins up its own Chromium renderer process, its own GPU compositing pipeline, its own memory space. If you have three Electron apps open, you have three copies of Chromium running. On a laptop with 8GB of RAM, that adds up fast.

+ +

The Memory Issue

+

This is what bothered me the most. Memory usage in Electron apps is genuinely high. A minimal "hello world" Electron app uses 80-120MB of RAM. That's more than some full desktop applications. The reason is Chromium — it's a full web browser, and browsers are memory hogs.

+

Chromium keeps multiple processes running: the main process, renderer processes for each window, GPU processes, utility processes. Each one consumes memory. Even when your app is idle, Chromium is still managing tabs you don't have, networking you don't need, and features you'll never use.

+

On my Mac, I routinely have 5-6 apps open at once. If three of them are Electron-based, that's easily 1-1.5GB of RAM just for those apps. On a machine where I'm also running Docker, VS Code, and a browser with 30 tabs... something has to give.

+ +

Why Not Just Use something else?

+

There are alternatives to Electron. Tauri uses the system's webview instead of bundling Chromium, which solves the disk space problem. But system webviews are inconsistent — Safari's webview on macOS is different from WebView2 on Windows, which is different from whatever GTK ships on Linux. You lose consistency.

+

I wanted something different. I wanted the consistency of Electron — same rendering engine everywhere — but without the Chromium baggage. That's when I started looking at Servo.

+ +

Enter Servo

+

Servo is Mozilla's next-generation browser engine. It was designed from the ground up for embedding, parallelism, and modern hardware. It uses Stylo for CSS (Rust-powered, parallel style computation) and WebRender for GPU compositing (the same renderer Firefox uses).

+

The key insight is that Servo doesn't bundle a full browser. It's a rendering engine designed to be embedded in other applications. That's exactly what Electron does with Chromium, but Servo is built for this use case rather than having it bolted on.

+

And because it's written in Rust, you get memory safety without a garbage collector. No runtime overhead, no unexpected pauses, no memory leaks from C++ code. The Rust compiler catches whole categories of bugs that would be silent in C++.

+ +

The Efficiency Argument

+

Here's what got me excited. Servo's architecture is fundamentally more efficient than Chromium for the embedding use case:

+
    +
  • Parallel CSS layout: Stylo computes styles in parallel across CPU cores. Chromium does this mostly single-threaded.
    • +
  • GPU compositing via WebRender: The same renderer Firefox uses, designed for efficient GPU utilization from the start.
    • +
  • No process-per-tab overhead: Servo doesn't spawn a new process for every rendering context. Less memory, less overhead.
    • +
  • Smaller binary: Rust static linking produces smaller binaries than Chromium's C++ build system.
    • +
  • Designed for embedding: Unlike Chromium, which had embedding support added later, Servo was built for this.
    • +
+

I'm not claiming Gelectron is faster than Electron today — it is but . It's early, it's experimental, and many APIs are stubs. But the foundation is more efficient. The ceiling is higher. And that's what matters.

+ +

How It Works

+

Gelectron is a drop-in replacement for Electron. You run gelectron . instead of electron ., and your app should just work. Under the hood:

+
    +
  • A JavaScript compatibility layer maps Electron's API surface (BrowserWindow, ipcMain, Menu, Tray, etc.) to Gelectron's internals
    • +
  • A Rust N-API addon handles the heavy lifting: window management via winit, native menus via muda, system tray via tray-icon, file dialogs via rfd
    • +
  • Servo handles all rendering — HTML, CSS, JavaScript execution
    • +
  • Node.js runs the main process, just like Electron
    • +
+

The goal is zero changes to existing Electron apps. Same require('electron') imports, same APIs, same code. Just a different engine underneath.

+ +

Where It's At

+

Let me be clear: Gelectron is very early. This is a proof of concept, not a production tool. Many Electron APIs are stubs. Some things break. Auto-updater doesn't exist yet. Multi-window support is limited.

+

But the core works. You can create windows, handle IPC, build menus, show dialogs. The foundation is there. And every week, more APIs get filled in.

+ +

Why It Matters

+

Desktop apps aren't going away. And the web platform keeps getting more powerful. The question is: how do we build cross-platform desktop apps without burning 300MB of disk and 200MB of RAM per app?

+

Gelectron is my answer to that question. It's early, it's rough, and it might not go anywhere. But if it works — if we can get Electron's developer experience with Servo's efficiency — that changes the economics of desktop app development.

+

Smaller apps. Less memory. Same code. That's the dream.

+ +
The best infrastructure is the one you don't notice. If your app framework is using 200MB of RAM, you notice it.
+ + + + Back to Devlog + +