Zed hit 1.0 this week and immediately topped Hacker News. If you've been half-watching it since the 2022 preview — built by ex-Atom core team members, written in Rust, GPU-accelerated — now is the right time to actually benchmark the zed editor against VS Code on the things that matter for frontend work.
Short version: Zed is genuinely fast, the AI story is better than Copilot's, and the extension ecosystem will block most of you from switching today. Here's why.
Cold Start and TypeScript LSP: Where Zed Actually Wins
The performance advantage is real. On an M3 MacBook Pro opening a 40,000-line TypeScript monorepo, Zed cold-starts in roughly 0.4 seconds. VS Code takes around 2.1 seconds to the same state — editor open, files indexed, LSP warm. That's not a marginal gap.
The reason isn't magic. Zed is built on GPUI, a custom GPU-accelerated UI framework written in Rust. It renders at 120fps and skips the Electron overhead VS Code has carried since 2015. Every keypress, every completion popup — it all feels materially snappier than even a well-tuned VS Code setup.
TypeScript LSP responsiveness is where the difference becomes sticky. Both editors use typescript-language-server under the hood, but Zed's threading model keeps the UI thread from blocking on LSP responses. Type errors surface faster, completions don't lag after large edits, and cross-file rename operations don't freeze the editor. After two weeks on a large Next.js project, the LSP alone was almost enough to make me stay.
Almost.
The Extension Gap Is Real
This is where Zed's 1.0 badge does some heavy lifting. The extension ecosystem sits around 200 extensions versus VS Code's 50,000+. For general editing that's manageable. For frontend work specifically, the gaps hurt:
- ESLint integration — there's a community extension but it doesn't match VS Code's on-save fix actions or rule-level configuration from the command palette.
- Tailwind IntelliSense — the VS Code extension is exceptional. Zed's community port exists but arbitrary value previews and class sorting aren't there yet.
- Debugger — Zed has no DAP (Debug Adapter Protocol) support. None. For React component work this is survivable; for anything involving complex async state or server-side code, it's a dealbreaker. For production errors, Sentry fills part of the gap — it integrates at the framework level and doesn't require a local debugger — but step-through debugging has no substitute.
- GitLens equivalent — Zed has inline git blame but nothing approaching GitLens's history, PR annotations, or commit graph.
Extensions in Zed compile to WebAssembly rather than Node.js. VS Code extensions don't port directly — they need to be rewritten from scratch. The ecosystem will grow, but the WASM constraint slows contributions from developers used to the Node.js model. The docs don't make this friction obvious, which cost me 20 minutes when a promising-looking extension turned out to be an empty stub.
If you're already standardising on Biome instead of ESLint + Prettier — a decision that's increasingly defensible, see our head-to-head Biome benchmark — Zed's formatter integration becomes much simpler. Biome ships a language server and Zed picks it up cleanly via LSP config with no extension required. That's one less gap to worry about.
AI Features: Baked In vs Bolted On
Zed's clearest structural advantage over VS Code is AI integration. Copilot is bolted on — a background extension that intercepts keystrokes and fires HTTP requests. Zed AI is a first-class panel built into the editor's architecture, and the practical difference shows up in context handling.
Zed's assistant panel can reference your entire open project, not just the current file. Highlight a component, open the assistant, ask it to refactor with full cross-file context — it works without the awkward "include these files" prompting you do with Copilot Chat. The inline diff workflow is genuinely better. And Zed supports multiple AI providers from a single config file:
// ~/.config/zed/settings.json
{
"assistant": {
"default_model": {
"provider": "anthropic",
"model": "claude-sonnet-4-5"
},
"version": "2"
}
}Switching between Claude and a local Ollama model is a dropdown, not an extension reinstall followed by keybinding conflict resolution. For VS Code to match this you need Copilot, possibly the Continue extension on top, and they'll fight over the same shortcuts.
The gap: Copilot's inline ghost text completion is still sharper than Zed's equivalent. GitHub's model training on public code gives it an edge on common library API patterns. If inline autocomplete is your primary AI use case, VS Code still wins that specific race.
Multi-Buffer Editing: The Feature Nobody Talks About
Zed's multi-buffer view — where you open excerpts from multiple files in a single editor pane, stitching together relevant functions across a codebase — has no VS Code equivalent. After using it for a refactor spanning five files, going back to tab-switching felt genuinely regressive. It's not a reason to switch on its own. But it's a glimpse of what an editor built from scratch in 2024 gets to do when it isn't carrying Electron architecture debt.
The Verdict
Switch to Zed now if your stack is TypeScript, you use Biome or are ready to (our pnpm monorepo + Biome setup guide covers a workflow that pairs cleanly with Zed), and you don't depend on a step-through debugger or specialist extensions like Tailwind IntelliSense.
Stay on VS Code if you rely on a DAP debugger, GitLens, Tailwind IntelliSense, or any framework-specific extension that doesn't have a Zed equivalent yet. The performance gains won't compensate for a broken workflow.
Zed 1.0 is ready for developers who've stripped their editor setup to the essentials. It's not ready for the developer who's accumulated 40 extensions over three years. Give it two or three major releases and the extension story will close meaningfully. At that point VS Code's main defence will be inertia — which is a fine defence, but not a technical one.
The zed vs vscode question finally has a clear answer for a specific kind of frontend developer. For the first time, that answer isn't simply "wait."