When we started building ZITEXT, the first question we asked was not "what features should it have?" It was "why do all the text editors I use feel slow?" The answer to that question led us to Rust and Tauri — two technologies that most desktop application developers were not using for text editors yet. This post explains the full engineering reasoning behind those choices, what we measured, and what the architecture looks like in practice.
The Problem: Every Text Editor Was Too Slow or Too Heavy
The text editor market in 2024 had a strange bifurcation. On one side were the terminal editors — Vim and Neovim, Emacs, Nano — which are genuinely fast but require significant investment to configure and have a steep learning curve for developers who do not want to spend an afternoon wiring up a language server protocol client. On the other side were the GUI editors — VS Code, Atom (now discontinued), Brackets — which are convenient and feature-rich but built on Electron, giving them startup times measured in seconds and memory footprints measured in hundreds of megabytes.
In the middle were a handful of editors that had found partial solutions: Sublime Text, which is written in C++ and starts fast, but requires a paid license and has been in maintenance mode for years; Notepad++, which is genuinely fast and free but Windows-only; BBEdit, which is polished and macOS-native but is a paid product with an older interface aesthetic. None of these felt like the right answer for a developer who wanted something fast, modern, free, and available across all three major operating systems.
The specific pain point that crystallized the decision to build ZITEXT was routine: every morning, we would open a text editor to check a config file or inspect a log, and the editor would take three to five seconds to appear. That pause felt wrong. It violated the principle that tools should get out of the way of the work. A hammer does not take five seconds to pick up. A text editor should not either.
The goal we set was concrete: ZITEXT should open in under 300 milliseconds on any modern hardware — including Apple Silicon Macs, modern Windows machines, and mid-range Linux desktops. That meant the framework choice was not a UI preference; it was a hard engineering constraint.
Why We Chose Rust
Rust is a systems programming language with a compiler-enforced ownership model that eliminates entire categories of bugs — use-after-free, data races, null pointer dereferences — that plague C and C++ programs. It produces native machine code with performance comparable to C, and it has a modern package ecosystem (Cargo) and toolchain that makes cross-platform builds straightforward.
For a text editor, the performance characteristics of Rust matter in two specific areas. The first is startup time. A Rust binary initializes quickly because there is no garbage collector to initialize, no virtual machine to spin up, and no interpreter to load. The binary starts, allocates what it needs, and begins executing immediately. For ZITEXT, this translates directly into the sub-300ms startup target: the binary is loaded by the OS, the Tauri runtime initializes, and the editor is ready before a typical user has finished bringing the window into focus.
The second area where Rust matters is file I/O and text processing. A text editor that needs to open a 50 MB log file, apply syntax highlighting across tens of thousands of lines, or run a regex search across a large document needs to do so without blocking the UI thread. Rust's async runtime (Tokio) and its zero-cost abstraction model let us implement these operations efficiently without the overhead of a garbage-collected language. When you open a large file in ZITEXT, the rendering pipeline and the file loading pipeline run concurrently without either one starving the other.
Rust's memory safety guarantees also gave us confidence that ZITEXT would not develop the kind of subtle memory management bugs that accumulate in long-running C++ applications. For an editor that users might leave open for weeks at a time, avoiding memory leaks and use-after-free bugs is not just a correctness concern — it is a reliability concern.
Why We Chose Tauri Over Electron
Once we had decided on Rust for the application core, we needed a way to build a cross-platform GUI. The options were roughly: build a native GUI for each platform separately (too much work), use a Rust-native GUI framework like egui or iced (promising but not mature enough for production use in 2024), or use a webview-based approach to write the UI in HTML, CSS, and JavaScript while keeping the application logic in Rust.
Electron is the most established webview-based framework. It is used by VS Code, Slack, Discord, Figma, and dozens of other well-known applications. Electron's approach is to bundle a complete Chromium browser and a Node.js runtime with every application, giving developers a fully isolated web environment with no dependency on whatever browser the user has installed. This is reliable and portable, but it comes at a cost: every Electron application ships with roughly 100–200 MB of Chromium code that it has to load on startup, regardless of how simple the application is.
Tauri takes a fundamentally different approach. Instead of bundling its own browser, Tauri uses the operating system's native webview: WKWebView on macOS, WebView2 on Windows, and WebKitGTK on Linux. These webviews are already present on the system and are loaded into memory by the OS as part of normal system operations. A Tauri application uses the webview that is already there rather than loading a second, separate browser. The application core — the part that does file I/O, manages state, and communicates with the OS — is written in Rust and compiled to a native binary.
The practical consequence is dramatic: Tauri applications are typically 3–10 MB in size (ZITEXT's macOS installer is under 10 MB), compared to 100–300 MB for equivalent Electron applications. Startup time is measured in milliseconds rather than seconds. Memory usage at idle is a fraction of what Electron requires.
What Tauri Gives Us That Electron Can't
Beyond the raw performance numbers, Tauri's architecture provides several structural advantages that influence how ZITEXT works at a deeper level.
Security model. Tauri's permission system is explicit: Rust commands that the frontend JavaScript can call must be explicitly declared and allowed. There is no implicit capability for the JavaScript layer to access the file system, spawn processes, or make network requests unless the Rust core exposes those commands. This is a meaningful improvement over Electron, where the boundary between the renderer process and Node.js has historically been difficult to enforce correctly, leading to real-world vulnerabilities in major Electron applications.
IPC architecture. In Tauri, the frontend communicates with the Rust backend through a typed command invocation system. When the editor needs to open a file, the JavaScript calls a named Rust command like open_file with a path argument. The Rust handler validates the path, reads the file, and returns the content. This explicit, typed contract between the UI layer and the application logic makes the codebase easier to reason about than the loosely coupled JavaScript-to-Node.js communication typical in Electron applications.
Platform integration. Because Tauri uses the OS-native webview, it benefits from OS-level updates to the rendering engine automatically. On macOS, WKWebView improvements from Apple's OS updates are available to Tauri applications without any action from the developer. Menu bars, system tray integration, file association handling, and native dialogs are all handled through Tauri's plugin system, which wraps the platform APIs in Rust and exposes them to the frontend in a consistent way.
Bundle size discipline. The small bundle size is not just a nice marketing number — it enforces a kind of feature discipline. When adding a feature to ZITEXT requires shipping a library, the Rust ecosystem's compile-time nature means we actually see the binary size impact of every dependency. This discourages the "install npm package for everything" pattern that causes JavaScript-based editors to balloon in size and complexity.
The Performance Numbers: ZITEXT vs Electron Apps
The table below summarizes the measured performance differences between ZITEXT and equivalent Electron-based editors. All measurements were taken on an Apple Silicon MacBook Pro (M3, 16 GB RAM) running macOS Sequoia 15.3, with a cold start (no applications previously launched in that session). Memory measurements reflect idle usage with a single medium-sized file (approximately 200 lines) open.
| Metric | ZITEXT (Tauri + Rust) | Typical Electron Editor |
|---|---|---|
| Cold startup time | Under 300ms | 2,000–5,000ms |
| Idle memory (single file) | ~50 MB | 250–500 MB |
| Installer / bundle size | ~8 MB | 100–300 MB |
| Renderer engine | WKWebView (system-native) | Bundled Chromium |
| Node.js runtime dependency | None | Bundled (~50 MB) |
| Background process count | 1–2 | 4–8+ |
Note on VS Code specifically: VS Code is a full IDE, not just a text editor, which explains some of its resource usage. The comparison above is between ZITEXT as a text editor and other Electron-based tools used in similar text-editing roles. For IDE-scale tasks, VS Code's resource consumption reflects the breadth of its capabilities.
The startup difference is the most perceptible in daily use. Sub-300ms startup means ZITEXT effectively opens instantaneously — the window appears while your hand is still moving toward the keyboard. In practice this changes how often you use the editor: when there is no perceived cost to opening it, you open it for smaller tasks, stay in it longer, and rely less on workarounds like keeping a permanent editor window in the background.
The memory difference compounds over a full working day. A developer with five files open across two editor windows in ZITEXT uses roughly 150–200 MB of RAM. The equivalent in a typical Electron editor is 800 MB to 1.5 GB, depending on extensions and file size. For developers running memory-intensive build tools, local databases, or browser development sessions alongside their editor, reclaiming that memory is meaningful.
What's Next for ZITEXT
The current version of ZITEXT — v1.1.0 — represents the core editing experience: multi-cursor editing, column selection, 60+ language syntax highlighting, JSON/XML/YAML tools, split view, file explorer, command palette, and custom keybindings. The foundation is stable and the performance characteristics are what we targeted. Future development follows from a simple principle: add capabilities that a text editor genuinely needs, and resist adding things that belong in an IDE.
The areas we are actively working on for future releases include improved large-file performance (files over 10 MB currently have some rendering limitations that we are addressing in the Rust rendering layer), a plugin API that exposes Rust-side commands to third-party extensions without requiring forking the core, and git diff indicators in the gutter — the kind of lightweight SCM integration that is useful in a text editor without turning it into a full IDE. We are also improving the command palette's fuzzy search and adding a "recent files" list that persists across sessions.
On the Tauri side, we are tracking Tauri v2's improvements to the plugin ecosystem and the WebView2 backend on Windows, which in our testing has improved rendering consistency significantly. The architectural decisions we made — Rust core, Tauri shell, typed IPC — give us a clean path to extend the editor without accumulating the technical debt that affects editors built on more loosely structured frameworks.
If you want to follow the engineering closely, the community repository on GitHub is where we discuss feature requests, publish performance benchmarks for each release, and track known issues. For release notes delivered directly to your inbox, you can sign up at the footer of this page.
If you are curious how ZITEXT compares to other editors on a day-to-day level, see our comparisons with VS Code and Sublime Text. For a broader look at why Electron apps are slow and the underlying architectural reasons, see our post on why Electron apps are slow and what we did instead.