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.

The Native Web View Approach

There are alternatives to Electron. Tauri uses the system's webview, which solves the disk space problem but introduces consistency issues — Safari's webview on macOS is different from WebView2 on Windows, which is different from WebKitGTK on Linux. You lose predictability.

I wanted something closer to Electron's developer experience. Same Node.js runtime. Same IPC model. Same APIs. But instead of bundling a full Chromium binary, Gelectron maps Electron's rendering layer to the OS-native web view. WKWebView on macOS/iOS, WebView2 on Windows, WebKitGTK on Linux. Each platform gets its own optimized renderer — no browser to bundle, no 150MB tax.

Why Native Web Views Win

The efficiency gains come from not duplicating what the OS already provides:

  • Shared system libraries: The OS already has its web rendering engine loaded. No need to bundle another one.
  • No process-per-app overhead: Each Electron app spins up its own Chromium process tree. Native web views share the system renderer.
  • Smaller binary: No Chromium bundle means binaries measured in megabytes, not hundreds of megabytes.
  • Lower baseline memory: Without a full browser engine in-process, your app starts with a fraction of Electron's baseline RAM.
  • OS-level optimizations: Apple, Microsoft, and the GNOME team all optimize their web views for their own platforms. You get that for free.

I'm not claiming Gelectron is faster than Electron today. It's early, experimental, and many APIs are stubs. But the foundation is fundamentally 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
  • The platform's native web view 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 no bundled browser.

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 without bundling a full browser — 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