If you've ever wondered why opening Slack takes four seconds when a native iOS app opens in under one, or why VS Code idles at 350MB of RAM while a basic text file is open, you've encountered the Electron problem firsthand. It's not a mystery — the architectural reasons are well understood — but it's worth examining precisely, because the tradeoffs involved explain both why Electron became so dominant and why alternatives like Tauri now exist.
This post explains how Electron works, what the performance costs actually are, and why we chose Rust and Tauri to build ZITEXT instead — along with real numbers that show what that choice achieved.
What Is Electron and Why Is It So Popular?
Electron is a framework created by GitHub in 2013 (originally for the Atom editor) that lets developers build desktop applications using web technologies: HTML, CSS, and JavaScript. Its core insight was that web developers vastly outnumber native desktop developers, and that the tooling, libraries, and design systems built for the web could be redirected toward desktop app development without requiring teams to learn Swift, Objective-C, C++, or C#.
The value proposition was immediate and compelling. A team building a web application could ship a desktop version using most of the same codebase. Cross-platform support — macOS, Windows, Linux — came essentially for free, since the same HTML and JavaScript renders the same way in every browser. UI frameworks like React, Vue, and Angular worked unchanged inside an Electron app. The npm ecosystem — millions of packages for every conceivable task — was fully available.
The adoption was rapid and deep. GitHub's Atom editor (the first major Electron app), VS Code, Slack, Discord, Figma's desktop app, 1Password, Notion, Obsidian, Hyper terminal — the list of significant Electron applications is enormous. By the mid-2020s, Electron was one of the most widely deployed desktop application frameworks on the planet.
The tradeoff was performance. And not a small tradeoff — a fundamental one, baked into the architecture.
The Real Cost of Bundling a Browser
Electron achieves its cross-platform web rendering by bundling a full copy of Chromium — Google's open-source browser engine — inside every application. Not a reference to the system's installed browser. Not a shared framework. A full, private copy of the browser engine, bundled into the application binary.
Why does this matter? Because Chromium is large. A modern Chromium build is approximately 90–130MB of binary code. It includes a full JavaScript engine (V8), a full HTML/CSS rendering engine (Blink), a networking stack, a graphics compositor, sandboxing infrastructure, and much more. All of this is present in every Electron application, regardless of whether the application uses 1% or 100% of those capabilities.
When a user installs both VS Code and Slack, they now have two complete copies of Chromium on their machine. Install Discord as well, and there are three. Each copy is slightly different — frozen to the version of Chromium that was current when the application was built — and each occupies its own disk space, loads its own processes into memory, and maintains its own cache.
The process architecture compounds this. Electron uses Chromium's multi-process model: there is a main process (the application's backend) and one or more renderer processes (the windows, which each run in an isolated Chromium renderer process). Each renderer process carries overhead from the browser sandbox. A fresh Electron application with one window commonly has 4–8 processes visible in the system activity monitor before you've done anything.
The startup cost is also structural. To show the first window, Electron must:
- Start the main Node.js/V8 process
- Initialize the Chromium browser engine
- Create a renderer process for the window
- Load the application's HTML, CSS, and JavaScript bundle
- Execute the application initialization code
- Render the first frame
Steps 1–3 are essentially the same as starting a web browser. On modern hardware this takes 1–3 seconds. On older hardware or spinning disk drives, it takes considerably longer. The user's perception is simple: this app is slow to open.
Memory Usage: Electron vs Native Apps
The numbers below were measured on Apple Silicon (M2, 16GB RAM) running macOS 15, with each application open with its default state and a single document or view. Electron baseline values are from fresh launches with no extensions or plugins loaded.
| Application | Memory at Startup | Binary / Install Size | Startup Time | Uses Electron |
|---|---|---|---|---|
| VS Code | ~340 MB | ~380 MB | ~3.2 s | ✓ Yes |
| Atom (archived) | ~290 MB | ~310 MB | ~4.5 s | ✓ Yes |
| Slack | ~450 MB | ~280 MB | ~4.0 s | ✓ Yes |
| Sublime Text | ~40 MB | ~20 MB | <0.5 s | ✗ No (C++) |
| ZITEXT | ~75 MB | ~9 MB | <0.5 s | ✗ No (Rust/Tauri) |
These numbers reflect a genuine architectural difference, not just optimization work. You cannot optimize an Electron app to use 75MB of RAM because the browser engine alone requires more memory than that to operate. The overhead is foundational.
What We Built Instead: Rust + Tauri
When building ZITEXT, we evaluated the available options for a cross-platform desktop text editor. A native application written in Swift or Objective-C would perform well on macOS but require entirely separate codebases for Windows (C# / WinUI) and Linux (GTK / Qt). That's three teams, three codebases, three sets of UI behavior to keep synchronized. For a small, focused product, that's not viable.
Electron was the obvious alternative — use the web stack, get cross-platform for free, access the npm ecosystem. But the performance floor was unacceptable for a text editor. A text editor is a utility. It should open instantly, stay out of your way, and consume minimal resources. An editor that takes three seconds to start and idles at 350MB defeats its own purpose.
Tauri provided the third path. Tauri is an open-source framework (Apache 2.0 / MIT licensed) that lets you build cross-platform desktop applications using web technologies for the frontend, but with a Rust backend instead of Node.js, and — critically — using the operating system's native WebView instead of a bundled Chromium instance.
The implications of using the system WebView are significant:
- Binary size: No Chromium to bundle means the application binary contains only the application code and its Rust dependencies. ZITEXT's installer is approximately 9MB, compared to ~380MB for VS Code.
- Memory usage: The WebView is a shared system component. Multiple Tauri applications running simultaneously share the same underlying rendering engine memory, rather than each maintaining their own private Chromium instance.
- Startup time: The system WebView is already initialized as part of the operating system's graphics stack. ZITEXT doesn't need to boot a browser to render its first window — the WebView is effectively pre-warmed.
- Security: Tauri's architecture uses Rust's ownership model to enforce strict separation between the frontend and the system. IPC (inter-process communication) between the UI and the Rust backend is typed and explicitly declared. There is no unrestricted Node.js API surface available to the web layer.
Tauri's Architecture: How It Achieves Native Performance
Understanding Tauri's architecture helps explain why the performance characteristics are fundamentally different from Electron, not just incrementally better.
A Tauri application consists of two parts that run in the same process:
The Rust core
This is the application's backend, written in Rust. It handles system operations: reading and writing files, managing application state, window management, and exposing a command API to the frontend. Rust is a systems programming language that compiles to native machine code with no runtime overhead. There is no garbage collector, no virtual machine, no interpreter. The Rust binary runs with performance comparable to C/C++ applications.
For ZITEXT, the Rust core handles file I/O, the application menu system, window lifecycle, and communication with Monaco Editor. When you open a 5MB file, the Rust layer reads it from disk and passes it to the editor component — a straightforward, fast operation that doesn't route through a Node.js event loop or a browser sandbox.
The WebView frontend
The user interface is an HTML/CSS/JavaScript application rendered in the system's native WebView. On macOS, this is WKWebView (the same component used by Safari). On Windows, it's WebView2 (based on a shared Chromium runtime that Windows installs alongside Edge — distinct from Electron's per-app bundling because it's shared across all WebView2 applications). On Linux, it's WebKitGTK.
This means the UI can use any web framework — React, Vue, Svelte, vanilla JavaScript. ZITEXT's interface uses React, and Monaco Editor (Microsoft's open-source editor component from VS Code) provides the actual code editing surface. The editor quality is identical to VS Code's because it literally uses the same editor engine — just without the Electron wrapper around it.
The IPC bridge
Communication between the Rust backend and the JavaScript frontend happens through a strictly typed IPC layer. The frontend invokes named Rust commands (invoke('open_file', { path })) and receives responses. The Rust side defines which commands are exposed using the #[tauri::command] attribute. There is no way for the JavaScript layer to call arbitrary system APIs — only the explicitly exposed Rust commands are available. This is a meaningful security improvement over Electron's Node.js integration.
Does It Actually Matter? Real-World Impact
Performance benchmarks are useful context, but the more important question is: does the architectural difference produce a meaningfully better experience for real users doing real work?
The answer is yes, in three specific ways:
The utility app experience
A text editor is often a utility application — you open it to do one specific thing (check a config file, edit a script, format some JSON), and then you close it. For this use pattern, startup time is the most important metric. If your editor takes three seconds to open, you might leave it open all day just to avoid the startup cost, and it eats memory even when you're not using it. If it opens in under half a second, you open and close it freely — it behaves like a file system tool, not an application you have to manage.
Multi-application workflows
Developers typically run many applications simultaneously: a browser, a terminal, a database client, a communication tool, a code editor, perhaps a design tool. On a machine with 16GB of RAM, the difference between a 75MB and a 350MB text editor is meaningful when the other tools also compete for memory. ZITEXT leaves more headroom for everything else.
Older and lower-spec hardware
Not every developer works on a current-generation machine. Electron's performance penalty is much more severe on hardware from 3–5 years ago. An Electron app that starts in 3 seconds on an M3 MacBook may take 8–10 seconds on a 2019 Intel MacBook or a budget Windows laptop. ZITEXT's sub-half-second startup on Apple Silicon remains well under two seconds on older x86 hardware, because it's not dragging the weight of a browser engine through initialization.
The broader lesson isn't that Electron is a bad technology — it's been the right choice for many applications with the right constraints. Slack, Discord, and VS Code are not "lightweight utility apps." They're rich, complex, heavily extensible environments where developer productivity via the web stack genuinely outweighs the performance cost, and where users are willing to leave the app open all day.
A text editor is different. It should disappear into the background of your workflow. The best compliment you can give a text editor is that you never think about it — it's just there when you need it, and it doesn't ask for anything in return. That's what guided the decision to build ZITEXT on Rust and Tauri rather than the easier path of Electron.
The 9MB install size, the sub-500ms startup, and the 75MB memory footprint aren't marketing numbers. They're the natural consequences of an architectural decision made at the beginning: to build a tool that gets out of your way.