Zed 1.0 Is Out — And the Guy Who Built Electron Just Proved It Was a Mistake

Nathan Sobo spent nine years at GitHub. From December 2011 through 2020, he built Atom — the editor that introduced millions of developers to the idea that you could write a desktop application using web technologies. He also co-created Electron, the framework that turned that idea into an industry standard.

Then he watched VS Code eat Atom alive, watched Microsoft kill Atom in 2022, and watched every developer tool company in the world ship bloated Chromium wrappers that consumed gigabytes of RAM to do things that native applications had been doing in megabytes for decades.

So he started over.

Zed 1.0 released yesterday, April 29, 2026. Nathan Sobo now says web technology offered "an easy path to shipping" but also limited performance and capabilities. He built Zed to fix what he built before.

The performance gap is not subtle. VS Code spawns 23 processes consuming 3,549MB of RAM to open a project folder. Zed does the same with 5 processes and 222MB. Cold startup: 0.12 seconds versus 1.2 seconds. Input latency: 2ms versus 25ms.

That's not a benchmark. That's a reckoning.

Why Electron Applications Are Destroying Your System Resources

Before getting to Zed, you need to understand what Electron is actually doing to your machine, because most developers have normalized the damage.

What Is Electron and Why Does It Use So Much Memory?

Electron is a framework that lets you build desktop applications using HTML, CSS, and JavaScript. The pitch in 2013 was compelling: web developers could ship cross-platform desktop apps without learning Swift, Objective-C, C++, or Win32. One codebase, all platforms. GitHub shipped Atom on it. Microsoft shipped VS Code on it. Slack, Discord, WhatsApp Desktop, Figma, Linear, 1Password 7, and hundreds of other applications followed.

The mechanism: Electron applications mirror Chromium's multi-process architecture. A single main process controls the application lifecycle. Each window spawns a separate renderer process. There's a GPU process, utility processes, and potential additional child processes.

Each renderer process maintains its own JavaScript heap and can hold large cached objects. That multi-process design improves robustness in a web browser, but when the same model is embedded into a long-running desktop application, its memory behavior becomes persistent system overhead rather than ephemeral tab usage.

And every Electron app ships its own copy of Chromium. Not a shared Chromium. Not a system WebView. Electron apps include a full Chromium browser and Node.js runtime for each window. This baseline overhead means even simple apps use 50-100MB before your application code runs a single line.

Open VS Code, Slack, Discord, and Figma simultaneously and you have four complete Chromium installations loaded into RAM. On a 16GB machine, those four applications alone can consume 6-8GB — half your system memory — before you've opened a database client, a browser, or a terminal.

How Does V8's Memory Architecture Make Electron Worse?

The Chromium baseline is only the first problem. Once your application runs, V8's JavaScript engine adds its own structural overhead.

V8 uses pointer compression, which limits the V8 heap to a maximum of 4GB. This applies to each renderer process independently. For typical applications this ceiling isn't a constraint. But the pointer compression itself — and the garbage collector that manages the heap — runs continuously, pausing application threads to collect dead objects.

In a browser, those GC pauses are invisible because they happen in the background of a tab you're not focused on. In a code editor that processes every keystroke, every cursor movement, every file system change, and every language server response in the same V8 heap, those pauses register as input lag. The 25ms input latency VS Code exhibits versus Zed's 2ms isn't a rendering optimization problem. It's a fundamental consequence of routing user input through a garbage-collected JavaScript runtime.

Electron combines Chromium with Node.js to provide access to native OS APIs. That creates additional runtime contexts: Node native modules, background IPC listeners, long-lived timers, and native allocations for codecs. Each of these raises the baseline memory substantially, and leaks in any of them are harder to recover from automatically.

What Happens to CPU When Electron Apps Run?

Memory is the problem you can see. CPU is the problem you feel.

Every Electron application runs a V8 JIT compiler that profiles hot code paths and recompiles them during execution. This is necessary — JIT compilation is what makes JavaScript fast enough to use as an application language at all. But it means CPU cycles are continuously consumed by compiler work that has nothing to do with what your application is doing.

The GPU process in Chromium handles compositing. The renderer process handles layout. The main process handles IPC. When a handful of Electron apps are open, the per-process overhead adds up quickly — and sometimes it grows over time because of retained caches or genuine memory leaks.

The developer experience consequence: VS Code's UI noticeably stutters when navigating large files. Extension installations introduce lag spikes as additional JavaScript modules load into the heap. Language server responses create microstutter because the IPC round-trip between the extension host process and the renderer process adds latency on every completion request.

Multiple MacBook users describe being able to code without hearing their Mac's fans screaming at them after switching away from VS Code — a problem they'd accepted as normal.

You've accepted it as normal too. You've had task manager open, seen VS Code consuming 800MB with two files open, and thought "that's just how software works now." It isn't.

What Zed Does Differently at the Architecture Level

Zed's performance advantage isn't the result of optimization. It's the result of a completely different foundation.

How Does GPUI Work and Why Does It Matter?

GPUI is Zed's custom, GPU-accelerated UI framework. Instead of relying on a web engine or other abstraction layers, GPUI renders pixels directly to the screen. On macOS it uses Metal. On Linux it uses Vulkan. On Windows it uses DirectX 11 or 12.

There's no browser engine in the call stack. There's no HTML parser, no CSS layout engine, no JavaScript runtime interpreting your UI description into DOM nodes. This architecture achieves a consistent 120 FPS refresh rate by bypassing the inherent inefficiencies of traditional desktop UI frameworks.

The practical consequences:

Input latency is 2ms in Zed versus 25ms in VS Code. That difference is below human perception thresholds for discrete actions, but above threshold for continuous interactions like scrolling and typing. Typing in VS Code on a large file has a subtle but real mushiness that disappears the moment you open the same file in Zed. After a week in Zed, going back to VS Code feels like typing through a pillow.

For large projects with 10,000+ files in a monorepo scenario, Zed opens in 0.25 seconds versus VS Code's 3.8 seconds — 15x faster. This comes from GPU-accelerated file tree rendering and parallel file system indexing versus VS Code's sequential loading and JavaScript-based indexing.

Why Does Writing an Editor in Rust Specifically Matter?

Rust gives Zed two things that neither C++ nor JavaScript can simultaneously provide: memory safety without a garbage collector, and zero-cost abstractions.

Memory safety without GC means no pause-the-world collection events. Every allocation in Zed is tracked by the compiler's borrow checker at compile time. Memory is freed deterministically when the value that owns it goes out of scope. There's no GC thread consuming CPU cycles in the background. There's no heap compaction pausing the main thread at inopportune moments.

Zero-cost abstractions means the high-level Rust code that describes "render this text with this syntax highlighting at this position" compiles to machine code that does exactly that work and nothing else. No interpreter overhead. No JIT warmup period. Rust's memory safety and zero-cost abstractions minimize runtime overhead in a way that keeps Zed's minimal core at 87MB idle memory with no extensions loaded.

Zed leverages multiple CPU cores through Rust's ownership model — parallel file system indexing, concurrent language server communication, simultaneous syntax tree updates. GPU-accelerated rendering reduces CPU load for the UI layer and enables smooth scrolling. The optimization happens at the data structures and algorithm level throughout.

What Is Zed's Process Model Compared to VS Code's?

VS Code spawns 23 processes to open a project folder. Zed does the same with 5 processes.

Those five Zed processes are:

1. The main application process
2. The language server host
3. The extension worker (WASM-sandboxed)
4. The GPU rendering process
5. A background task worker for file operations
   That's it. No separate extension host per extension. No renderer process running a copy of Chromium. No GPU compositor layered on top of a JavaScript layout engine. Five processes with a combined memory footprint less than a single VS Code renderer.

What Zed 1.0 Actually Ships

Zed 1.0 features real-time collaborative editing, AI integration, GPU-accelerated rendering, Git integration, debugging support, and is available on Windows, macOS, and Linux.

Collaboration Built Into the Core

Zed's native real-time collaboration uses CRDT-based synchronization, voice chat, and shared cursors built directly into the core architecture, not bolted on as an extension.

Compare this to VS Code's Live Share: install an extension, sign into a Microsoft account, hope the connection doesn't drop, accept the 200-500ms latency that makes collaborative editing feel laggy. Zed's collaboration works at 120 FPS because it's built on the same infrastructure as the editor itself. Shared cursors render with the same latency as local cursor movement.

AI Integration That Doesn't Eat Your Resources

Zed supports multiple LLM providers — Anthropic, OpenAI, Google, Ollama, and Zed's own open-source model Zeta for edit prediction. It uses the Agent Client Protocol (ACP) and Model Context Protocol (MCP) for standardized AI agent integration. Inline assistants can refactor or document code blocks in place, while parallel agents can run simultaneously.

The MCP integration is relevant for readers running the self-hosted productivity stack. Zed can connect to a local Ollama instance the same way it connects to Anthropic's API — one configuration change, no internet required, no token costs. The editor that uses 16x less RAM than VS Code also lets you run your AI assistance locally without shipping your code to any external server.

What's New Specifically in 1.0

The 1.0 release is primarily a stability milestone rather than a feature drop. Notable additions include bookmark support for quick navigation to bookmarked text, a "view commit" command palette action for Git, animated GIF support in the Markdown preview, improved fuzzy matching, better SSH session reuse, and support for DeepSeek-V4-Pro and DeepSeek-V4-Flash AI models.

The SSH remoting improvement matters for developers who work on remote servers. SSH session reuse means reconnecting to a remote development environment doesn't create a new session from scratch — it resumes the existing one, preserving open files and scroll positions. VS Code's Remote SSH extension is mature and well-regarded. Zed's is now competitive.

Alongside the 1.0 milestone, Zed is introducing Zed for Business with centralized billing, role-based access controls, and organization management for teams.

What Zed Gets Wrong

Fair coverage requires saying this clearly: Zed 1.0 has real gaps.

The extension ecosystem is 700 versus 50,000. 83% of successful Zed switchers are solo developers or small teams with lightweight extension needs. If your workflow depends on specific VS Code extensions — Jupyter notebooks, remote containers, a proprietary enterprise tool, complex test runner integrations — you may hit walls. The extension gap is real. Zed uses a WASM-based extension system that isn't compatible with the VS Code extension API, so the 50,000 VS Code extensions don't port automatically.

Language server support is good but not universal. Because Zed uses the Language Server Protocol natively, any language that has an LSP implementation works. The quality varies. Rust and TypeScript are first-class. Some languages have rough edges in the extension implementations.

There's a Node.js download issue. There is concern about Zed downloading and running packages including Node.js without specific user consent. Several extensions require Node.js tooling and Zed fetches it silently. For developers who want full control over what their tools download and execute — the same developers who run local LLMs and self-host their email — this matters. The Zed team knows about it.

The licensing situation requires attention for enterprises. The core editor is GPL, server-side components are AGPL. GPUI is Apache 2. The copyleft nature of GPL/AGPL means derivative works or deep integrations may need to be open-sourced under similar terms. For most users this is irrelevant. For companies building tooling on top of Zed, this needs a legal review before you ship.

The Electron Situation Isn't Going Away

Here's the uncomfortable part of this conversation: Electron worked. That's why everyone uses it.

When GitHub shipped Atom in 2014, web developers who had never built a desktop application could suddenly ship desktop applications. One codebase. Three platforms. The velocity advantage was real. The ecosystem advantage was real. The talent pool of developers who knew JavaScript was orders of magnitude larger than the pool of developers who knew Cocoa, Win32, or GTK.

VS Code benefited from every one of those advantages. Electron's multi-process model made VS Code's extension architecture possible — you can install a broken extension and VS Code keeps running because the extension runs in its own process. A native crash in an extension renderer doesn't take down the editor. That robustness has genuine value.

Native rewrites are expensive. Rewriting a complex cross-platform application into native code requires substantial engineering investment and platform expertise — a cost many vendors avoid unless user pain and support costs make it unavoidable.

But the calculus is shifting. Rust has made native cross-platform development tractable. Tauri (the Electron alternative built on Rust + system WebView) has proven that you can build legitimate cross-platform applications without shipping a full Chromium copy. Zed built an entire custom UI rendering framework in Rust and shipped it on three platforms with first-class support on each. What required a team of thirty C++ engineers a decade ago is now achievable by a well-resourced startup.

The Electron apps you use daily are not going to vanish. Slack, Discord, and VS Code are not going to be rewritten in Rust next year. But the argument that Electron is the only practical approach to cross-platform desktop development is dead. Zed just shipped a production editor that proves otherwise.

Who Should Switch to Zed Right Now?

Switch now if you:

Work primarily in languages with strong Zed support — Rust, TypeScript, JavaScript, Python, Go, C, C++, Ruby, PHP. Have a workflow that relies on 10-15 or fewer VS Code extensions. Work on a MacBook and hear your fans spinning during normal coding sessions. Build on large codebases where VS Code's file tree becomes sluggish. Want local AI integration that doesn't require sending code to external servers. Care about using tools that don't treat your hardware as an infinite resource.

Stay on VS Code if you:

Rely on specific extensions with no Zed equivalent. Do data science work with Jupyter notebooks integrated into your editor. Use remote container development heavily. Work at an enterprise where tooling standardization matters more than individual performance.

The pragmatic move: keep VS Code installed, run Zed as your primary editor for a month on current projects. Use VS Code as the fallback for workflows Zed can't handle. The two editors can coexist on the same machine, and the performance difference in Zed is worth experiencing even if you don't switch entirely.

The Numbers One More Time

VS Code spawns 23 processes consuming 3,549MB to open a project folder. Zed uses 5 processes and 222MB.

Cold startup: 0.12 seconds versus 1.2 seconds. Input latency: 2ms versus 25ms.

Large project with 10,000+ files: Zed opens in 0.25 seconds. VS Code takes 3.8 seconds.

In benchmark tests across 12 production codebases ranging from 80,000 to 240,000 lines of C, Rust, and Zig, Zed delivers 2.1x faster LSP response times and 47% lower idle memory usage.

The man who built Electron looked at those numbers, spent years building something that doesn't produce them, and shipped it yesterday. That's not an endorsement of Zed specifically. It's a verdict on the decade of damage that shipping Chromium as a desktop application runtime has done to developer machines everywhere.

Download it. Open your largest codebase. Notice that your fans don't spin up. You've been accepting that as normal for too long.

The JavaScript fundamentals series covers V8 — the engine that powers Electron — in depth, including the event loop, call stack, and the JIT compilation model that makes Electron's GC pauses inevitable. The TypeScript 7.0 beta article covers the TypeScript compiler's own native rewrite for similar reasons — JavaScript runtimes have a performance ceiling that matters at scale. The Rust overview covers the language Zed is written in and why its ownership model specifically makes the memory safety without GC tradeoff possible.