Gelectron for Developers
An honest look at what Gelectron is, what it isn't, and whether it makes sense for your next project. No fluff, no overpromising.
"Gelectron is a drop-in Electron replacement built on Servo (Rust) instead of Chromium. Same JavaScript APIs, smaller binary, lower memory. But it's early — not everything works yet."
What We Have
These modules work today. Some are fully functional, others have gaps — we're transparent about what's missing.
| Module | Status | Notes |
|---|---|---|
app |
Full | Full lifecycle, dock, badge, GPU info, about panel, window tracking |
ipcMain |
Full | handle, handleOnce, on, once, removeHandler, full EventEmitter |
BrowserWindow |
Partial | Create, show, hide, resize, loadURL, loadFile. Missing: DevTools, navigation, capturePage, print |
Menu / MenuItem |
Partial | buildFromTemplate, native setApplicationMenu via muda. Missing: native click events, role auto-behavior |
dialog |
Partial | Open/save/message/error dialogs wired via rfd (Rust). Native dialogs work |
clipboard |
Full | Full API: text/HTML/RTF/image/bookmark/find-text, clear, availableFormats, has. Sync FIFO (macOS/Linux) or async bridge (Windows) |
screen |
Partial | getPrimaryDisplay/getAllDisplays/getCursorScreenPoint via tao bridge. Missing: display event listeners |
nativeTheme |
Partial | shouldUseDarkColors, themeSource, shouldSystemUseDarkColors via Rust bridge |
shell |
Partial | openExternal, openPath, showItemInFolder, moveItemToTrash, beep via bridge (open crate, trash crate) |
Notification |
Partial | API surface complete, shows via browser Notification API. No native OS integration yet |
nativeImage |
Partial | createFromPath/Buffer/DataURL, toDataURL, getSize. Missing: resize/crop pixel transform |
webContents |
Partial | loadURL/loadFile/send/executeJavaScript/reload. Missing: navigation history, DevTools CDP, zoom |
ipcRenderer |
Partial | invoke/send/sendSync/on/once/removeListener. Bridge not always wired |
contextBridge |
Partial | exposeInMainWorld with deep freeze. No real world isolation |
net |
Partial | fetch delegates to globalThis.fetch. Missing: net.request(), ClientRequest API |
process |
Partial | pid/argv/env/platform/versions/cwd/nextTick. Missing: memoryUsage/cpuUsage/uptime/kill |
What We Don't Have
These modules exist as stubs (API calls do nothing) or haven't been started at all.
Stubs (API exists, does nothing)
| Module | Why It's a Stub |
|---|---|
Tray | No native system tray support yet |
safeStorage | Base64 encoding, not real encryption |
session | All methods are no-ops |
systemPreferences | isDarkMode linked to nativeTheme, rest no-ops |
powerMonitor | getSystemIdleState always returns 'active' |
globalShortcut | register() always returns true |
contextIsolation | Stored but no real V8 isolate separation |
Missing (not started)
33 modules haven't been touched yet:
Check the full progress page for the complete list.
Where We Win
Gelectron beats Electron on the metrics that matter most for shipping and scaling.
131 MB vs 586 MB total RSS. No Chromium multi-process overhead.
3 MB vs 296 MB on disk. Changes how you ship software.
Servo's Stylo engine computes CSS in parallel. Effectively instant.
Servo's parallel layout engine handles new DOM nodes faster.
SpiderMonkey's IonMonkey JIT beats V8 on deep call stacks.
Gelectron 5.60s vs Electron 5.67s. Close, but consistently ahead.
Where We Lose
Honest admissions about where Electron is still the better choice.
Chromium's hash-based selector matching is decades mature. Servo's will catch up.
Electron has ~143k npm packages, decades of Stack Overflow answers, and enterprise tooling.
Native Node.js modules (node-canvas, node-webgpu, better-sqlite3) may not compile against Gelectron's Node.js runtime.
autoUpdater now works for packaged apps (hosted feed + atomic swap on relaunch), but there's still no crash reporter.
No require(), no fs, no native modules in the renderer. Secure by default, but less flexible.
Early stage. Fewer contributors, fewer third-party tools, less documentation.
The Trade-Offs
Architectural decisions that cut both ways.
No Node.js in the renderer
Pro: Dramatically smaller attack surface. No require() injection, no fs access from page scripts. Closer to how modern web apps run.
Con: Can't use Node.js libraries directly in the renderer. Must use IPC for everything. Porting existing Electron apps may require restructuring preload scripts.
Rust core, not C++
Pro: Memory safe by default. No buffer overflows, use-after-free, or dangling pointers. Servo's parallel style engine is a genuine innovation.
Con: Rust has a steeper learning curve and smaller contributor pool than C++. Fewer existing native modules to draw from.
Platform WebView (for now)
Pro: Uses the OS native WebView (WebKit on macOS, WebView2 on Windows). Stable, well-tested, hardware-accelerated.
Con: Not Servo in the actual window yet. The Rust rendering engine is the long-term goal; today you get the system WebView with Gelectron's API layer on top.
Smaller community
Pro: More opportunity to make a real impact. Architecture decisions are still flexible — your contributions shape the project.
Con: Fewer bug reports, less documentation, slower issue resolution. You'll likely need to read source code to solve problems.
Should You Use Gelectron?
An honest verdict based on what we know today.
✅ Yes
- You're building a new desktop app from scratch
- Binary size and download speed matter (Docker, CI, distribution)
- You want minimal memory overhead
- You're building a kiosk, utility, or single-purpose app
- You're excited about Rust and Servo
- You don't need crash reporting or guaranteed update infrastructure
❌ No
- You need production-grade crash reporting and enterprise update infrastructure
- Your app depends on native Node.js modules in the renderer
- You need mature DevTools and debugging
- You can't afford API instability
- You need multi-window management with complex session handling
- You rely on Chromium-specific rendering features
🤷 Maybe
- You want to experiment and contribute to an early-stage project
- You're building internal tools where stability isn't critical
- You value memory safety and Rust's security guarantees
- You're tired of 300 MB download sizes and want something leaner
- You're willing to work around missing APIs with IPC workarounds
Gelectron is non-commercial, community-driven, and not affiliated with Electron or Mozilla. If this sounds like your kind of project, we'd love your help.
Contribute on GitHub →