Electron bundles Chromium with every app. That's 150-300MB per app, hundreds of MBs of RAM. I thought there had to be a better way.
+Electron bundles Chromium with every app. 150-300MB on disk, hundreds of MBs of RAM. Native web views fix that without changing your code.
@@ -120,35 +120,30 @@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.
-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.
+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.
-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++.
- -Here's what got me excited. Servo's architecture is fundamentally more efficient than Chromium for the embedding use case:
+The efficiency gains come from not duplicating what the OS already provides:
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.
+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.
Gelectron is a drop-in replacement for Electron. You run gelectron . instead of electron ., and your app should just work. Under the hood:
The goal is zero changes to existing Electron apps. Same require('electron') imports, same APIs, same code. Just a different engine underneath.
The goal is zero changes to existing Electron apps. Same require('electron') imports, same APIs, same code. Just no bundled browser.
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.
@@ -156,7 +151,7 @@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.
+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.diff --git a/index.html b/index.html index 45998d7..6378415 100644 --- a/index.html +++ b/index.html @@ -620,7 +620,7 @@
The AI isn't a gimmick — it's actually useful. Summarize a page of notes in one tap. Transcribe voice memos automatically. Quiz yourself on what you wrote. Chat with your notes like they're a second brain. Cloud (OpenAI) or local (Ollama), your choice. No subscription nonsense.
My side project is Gelectron — a Firefox-engine alternative to Electron, powered by Servo. I'm focused on keeping file size and RAM usage really, really low. Electron apps are bloated — a basic Electron app can be 150MB+ and eat 300MB of RAM just to show a window. I want Gelectron to ship at a fraction of that.
-Drop-in replacement — just run gelectron . instead of electron .. Right now I'm filling out the Electron API compatibility layer (BrowserWindow, IPC, Menu, Tray) and getting the Servo rendering pipeline working. It's a Rust + Node.js project and it's teaching me a ton about browser engines, FFI, and systems programming. Every byte and allocation matters.
My side project is Gelectron — a drop-in replacement for Electron that uses native web views (WKWebView / WebView2 / WebKitGTK) instead of bundling Chromium. No 150MB+ binaries. No 300MB of RAM just to show a window. Just your app, running on the OS-native renderer.
+Drop-in replacement — just run gelectron . instead of electron .. Right now I'm filling out the Electron API compatibility layer (BrowserWindow, IPC, Menu, Tray). It's a Rust + Node.js project and every byte and allocation matters.
The Geometry Dash demon list is still going strong. Nearly 4,000 verified runs, 340+ ranked levels, and a community that keeps me busy. I'm working on better moderation tools and a cleaner submission pipeline.
diff --git a/projects/gelectron.html b/projects/gelectron.html index 0e82ee6..3dc9ab7 100644 --- a/projects/gelectron.html +++ b/projects/gelectron.html @@ -4,10 +4,10 @@Electron, but lighter. A Firefox-engine alternative powered by Servo. Drop-in replacement — just run gelectron . instead of electron .
+Drop-in replacement for Electron using native web views (WKWebView / WebView2 / WebKitGTK) instead of bundling Chromium. Just run gelectron . instead of electron .