I opened Zed for the first time on a Monday morning with a TypeScript monorepo containing roughly three hundred thousand lines of code. VS Code needed about eight seconds to fully index that repository on startup, and another two to three seconds every time I ran "Find in Files" across the project. Zed finished its initial scan in under a second and showed search results before I had finished typing the query.
That first impression — raw speed, no compromises — is the reason Zed exists. Nathan Sobo, Max Brunsfeld, and Antonio Scandurra built Atom at GitHub a decade ago, watched it get outmaneuvered by VS Code's performance and extension ecosystem, and decided their second attempt would be architecturally impossible to build slowly. Zed is written in Rust, renders through the GPU, and treats latency as a design constraint rather than an optimization target.
But speed is a feature, not a product. After four weeks of using Zed as my primary editor for TypeScript, Rust, and Markdown work, here is what the editor delivers and what you give up by leaving VS Code.
The Architecture: Why Zed Feels Different
Zed's performance is not the result of aggressive optimization layered on top of a web-based architecture. It is the result of a fundamentally different architectural choice: Zed is a native application built on its own GPU-accelerated UI framework called GPUI. Every pixel renders through the GPU rather than a DOM renderer. Every keystroke goes through a custom text buffer engine rather than a Monaco editor instance running in an Electron shell.
The practical effect is most visible in three places: startup time, large-file handling, and search. Zed opens in about 200 milliseconds on my M2 MacBook Air. VS Code typically takes two to four seconds. The difference sounds trivial — it is less than four seconds — but it changes when you open the editor. I used to keep VS Code open all day because restarting felt expensive. With Zed, I close and reopen it freely, sometimes between tasks, because the restart cost is invisible.
Large files expose the architectural gap more dramatically. Opening a 50-megabyte log file in VS Code triggers a warning and several seconds of loading. In Zed, the same file opens instantly with syntax highlighting and scroll position maintained. The text buffer engine uses a piece table data structure — the same approach that Sublime Text pioneered — optimized for the kind of incremental edits developers make thousands of times per day.
The GPUI framework renders the entire editor through the GPU, including text. This means scrolling through a 5,000-line file feels as smooth as scrolling through a native macOS app because it is one — Zed draws at 120 frames per second on ProMotion displays. VS Code's Electron-based renderer tops out at 60 FPS in ideal conditions and drops below that on complex files. The difference is not just aesthetic; smooth scrolling reduces the subtle eye fatigue that accumulates during long coding sessions.
Language Support: The Source of Zed's Friction
Zed's language server protocol (LSP) support is more aggressive than VS Code's, but less mature. Zed ships with built-in language support for Rust, TypeScript, Python, Go, and about a dozen other languages — each with tree-sitter grammars for syntax highlighting and preconfigured LSP integrations. The TypeScript experience feels native: IntelliSense, go-to-definition, find-references, and rename all work from the first keystroke without installing a single extension.
The difference is what happens when you step outside the built-in languages. In VS Code, the extension marketplace has a language pack for virtually every programming language in existence, and installing one takes two clicks. In Zed, community extensions exist but the catalog is smaller — roughly two hundred extensions compared to VS Code's tens of thousands. For mainstream languages (Ruby, PHP, Swift, Kotlin), the experience is good. For niche languages (Nim, Zig, OCaml, Elm), you may find yourself without syntax highlighting or LSP support.
Rust support deserves a special mention because Zed's development team writes Rust and treats the Rust experience as a first-class product. The rust-analyzer integration is faster than in VS Code — completions appear in single-digit milliseconds rather than the hundred-millisecond range — and the inline type hints, lifetime elision annotations, and macro expansion previews feel like a native IDE feature rather than an LSP integration. If you write Rust professionally, the Rust experience alone may justify the switch.
The configuration story is also different. VS Code exposes hundreds of settings through a JSON file and a settings UI. Zed uses a JSON configuration file stored at ~/.zed/settings.json, and the schema is deliberately smaller. Here is a typical configuration:
{
"theme": "One Dark",
"ui_font_size": 16,
"buffer_font_size": 15,
"buffer_font_family": "JetBrains Mono",
"vim_mode": true,
"autosave": "on_focus_change",
"tab_size": 2,
"soft_wrap": "editor_width",
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": { "command": "clippy" }
}
}
}
}
This is not a complaint — the smaller configuration surface means fewer settings to manage, and the defaults are sensible. But if you have spent years tweaking every corner of your VS Code setup, be prepared to let go of some customizations.
Collaboration: Real-Time Editing Without the Browser Tab
Zed's collaboration features are the editor's most ambitious bet. Channels let you share a project with teammates in real time, with each person's cursor visible and each person's edits streaming live. The implementation uses CRDTs (conflict-free replicated data types) rather than operational transforms, which means collaboration works peer-to-peer without a central server mediating every keystroke.
I tested this with a colleague on a Rust project over a two-hour pairing session. The experience was on par with VS Code Live Share — cursors appeared instantly, edits propagated without noticeable latency, and the follow mode (where you track another person's viewport) worked smoothly. The advantage over Live Share is that Zed's collaboration is built into the editor's architecture rather than layered on top as an extension. The disadvantage is that the collaborator also needs Zed installed — there is no web-based guest mode.
Channels also support text chat and screen sharing built directly into the editor. You can jump into a voice call and share your editor window without opening a separate tool. This is not a Zoom or Discord replacement — the audio quality is functional, not studio-grade — but for quick pairing sessions where you want to talk through a problem, having voice inside the editor eliminates the context switch of tabbing to a communication app.
Zed vs. VS Code vs. Cursor: The Developer Editor Landscape in 2026
VS Code remains the default choice for most developers, and for good reasons that Zed has not addressed: the extension marketplace, the debugging experience, and the integrated terminal. If your workflow depends on extensions for Docker management, database exploration, API testing, or cloud service integration, VS Code's ecosystem is the undefeated champion.
Cursor approaches the editor market from the AI direction rather than the performance direction. It is a fork of VS Code with AI autocomplete, inline editing, and chat deeply integrated into the codebase. Cursor's AI features are more polished than Zed's — Zed has AI assistant integration via API key configuration, but it is a chat panel rather than an inline editing experience that understands your entire codebase. If AI-assisted coding is your primary workflow, Cursor is the stronger tool.
Zed competes on a different axis: raw performance, native feel, and collaboration. It is the editor for developers who feel a subconscious friction every time VS Code takes a second to open a file or show a completion. It is the editor for Rust developers who want their toolchain to feel as fast as their compiler outputs. And it is the editor for teams that want real-time collaboration without managing a separate pairing service.
If your workflow depends on extensions that do not exist in Zed — Docker, GitHub Copilot Chat (as of mid-2026), database explorers, cloud provider toolkits — you will keep VS Code installed alongside Zed. The editor is replacing VS Code for core editing tasks, not for every tool that happens to run inside an editor window. Treat Zed as your code editor and VS Code as your development environment, and the division of labor makes sense.
Who Should Switch to Zed
After four weeks, I kept Zed as my primary editor for Rust, TypeScript, and Markdown writing but kept VS Code installed for database exploration, Docker management, and any workflow that depends on the extension ecosystem.
The developers who will get the most value from switching are Rust developers (the toolchain integration is the best available), developers working on large monorepos (the startup and search speed differences compound with codebase size), and teams that pair-program frequently and want an integrated collaboration experience without paying for a third-party service.
The developers who should stay on VS Code are those deeply embedded in the extension ecosystem, those who rely on AI-assisted coding workflows that Cursor handles better, and those working primarily in languages where Zed's LSP support is immature. There is no prize for switching editors early. Zed is an open-source project that improves monthly, and the cost of waiting is zero.
FAQ
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)