Zed. The editor that treats speed as a feature.

Every keystroke in VSCode or WebStorm goes through a browser or a JVM.

Not a knock on either — both are excellent, mature tools. But the render path has extra stops most people never think about, because they've never felt the alternative.

Built by the people who made Tree-sitter.

• Zed Industries was founded by Nathan Sobo and Max Brunsfeld — both came off building Atom at GitHub, and Brunsfeld also created Tree-sitter, the incremental parser now used by half the editor ecosystem, Zed included.
• Atom taught them exactly where Electron's ceiling was. Zed is the rewrite of those lessons in Rust, from scratch, with none of the constraints an HTML/CSS UI imposes.
• The editor's source is published on GitHub — you can read the rope, the CRDT layer, and GPUI itself, not just file issues against a black box.

Speed isn't a patch here — it's the architecture.

• Single native binary. No Node.js runtime sitting under the hood the way Electron apps need one.
• Startup is a process launch, not a browser boot plus an extension-host boot behind it.
• Large files and long lines stay smooth — the Rope-backed buffer (more in the deep dive) doesn't re-lay-out the DOM on every keystroke, because there is no DOM.

AI wired into the buffer, not bolted on top.

The difference that actually matters: because AI features share the same Rope/CRDT buffer model as everything else, streamed edits apply as incremental patches — not a full-file rewrite dropped on top of whatever you were mid-typing.

Multiplayer was never an afterthought.

Zed's buffers are built on CRDTs — Conflict-free Replicated Data Types — from day one, not retrofitted for a "Live Share" feature later.

One native process, not three glued together.

• No Chromium renderer process, no separate Node.js extension-host process, no JVM heap sized for a whole project index — one multi-threaded Rust binary.
• Battery and fan noise on a laptop track this directly: fewer processes doing overlapping work means less to schedule and less to keep warm.
• The full mechanism — why this holds up under load, and where each competitor's model actually goes — is the deep dive, not this slide.

What you'd actually be giving up.

A tool worth switching to is worth describing honestly. Here's where Zed still loses to what you're using today.

Coming from VSCode: most of the muscle memory transfers.

• One setting gets you VSCode's keybindings on day one — native, no keymap.json to hand-write.
• settings.json is still just JSON with per-language override blocks — the mental model doesn't change, only some key names do.
• No .code-workspace file: Zed remembers whatever folders were open in a window and restores that layout automatically. Add a second project root anytime via File → Add Folder to Project — same idea as VSCode's multi-root workspaces, no file to maintain.

Coming from WebStorm: one real gap, everything else transfers.

• The keymap is a first-class option — no relearning `⌘.`-era muscle memory from scratch.
• The real adjustment: WebStorm's instant, whole-project "Find Usages" and refactors come from an in-memory semantic index (PSI) built at project open. Zed relies on the language's own LSP instead — for TypeScript/JS that's the same tsserver WebStorm ultimately talks to anyway, so quality is close; for less-tooled languages, it can be thinner.
• No bundled database client or HTTP client — if those are daily tools, keep WebStorm open in a second window for now.

Setup on macOS.

1. The Homebrew cask links the zed CLI into your PATH automatically — no separate "install shell command" step.
2. Open a project from the terminal: zed .
3. First run: Cmd+Shift+X to install language extensions you actually use (see slide 16).

Setup on Ubuntu.

• One command, no PPA to add. The installer also offers preview builds if you want to track pre-release features.
• Open a project the same way: zed .
• Same first-run step as macOS — install the language extensions your projects actually need.

The first ten minutes, in order.

1. Set base_keymap to whatever you already type without thinking — VSCode or JetBrains.
2. Open your real project: zed . — not a scratch folder. First impressions on toy code lie.
3. Install the two or three language extensions you'll actually use today (slide 16) — don't install a marketplace's worth speculatively.
4. Wire up formatting/linting to match what your team already enforces (slide 14) — this is the setting most people skip and then blame the editor for.
5. Connect an AI provider in the agent panel if you use one, then leave it alone for a week before judging.

A real config, from a multi-package TypeScript + Vue project.

Genericized from an actual monorepo (server + client + shared packages) — the shape, not the specifics.

Why it's shaped exactly like that.

• formatter: [] + code_actions_on_format: {"source.fixAll.eslint": true} — ESLint's autofix is the only formatting action. Matches VSCode's codeActionsOnSave: fixAll plus formatOnSave: false exactly, because it's respecting the same one source of truth: whatever this project's own ESLint config says.
• No chained Prettier step — deliberately. An earlier version of this config ran npx prettier after the ESLint fix "for projects that use it." A project with no .prettierrc at all still had prettier resolvable via npx (a transitive dependency), so it silently reformatted with Prettier's generic defaults on every save — fighting the project's real Airbnb/ESLint style. fixAll.eslint alone already covers projects that use Prettier through eslint-plugin-prettier too. Don't chain a formatter your config can't confirm the project actually wants.
• workingDirectories: [{mode:"auto"}] — ESLint resolves the right package's config per file by itself. In a packages/* monorepo that means zero hardcoded package paths to keep in sync as packages come and go.
• The "Vue.js" entry is not optional in a Vue project — languages blocks match Zed's language name, and a .vue SFC is Vue.js, not TypeScript. Leave it out and the TypeScript block silently never applies: the SFC falls back to the default formatter, where Volar formats through Prettier's generic defaults — double quotes, collapsed attribute lines — and undoes eslint-plugin-vue's style on every single save. Same trap for any other embedded-language file; name the language the file is, not the language inside it.
• project_panel.dock, tabs.file_icons/git_status, minimap.show — the visual-parity knobs from slide 09. None of these touch behavior; they exist purely so the tree and tab bar don't feel like a step down from what you're used to.

Extensions worth grabbing — and the ones you don't need.

Zed's own habit is minimal-by-default — most core language support (TS, Python, Go, Rust, Markdown) ships without an extension at all. Install what a project actually needs, not a marketplace's worth up front.

Workspace = whatever folders are open in that window.

• No named workspace file — Zed remembers a window's exact folder combination and restores its layout (splits, tabs, panels) automatically when you reopen it.
• Two related repos, one window: zed ~/repo-a ~/repo-b, or inside Zed, File → Add Folder to Project. Both show as separate roots in the same project panel — search and AI context span both.
• Switching projects: Ctrl+R — Open Recent, same key on macOS and Linux. Plain click reuses the window; Cmd/Ctrl+Enter or Cmd/Ctrl+Click opens a new one instead.

Two settings people keep asking about, side by side.

Shortcuts you'll use every single day.

Straight from Zed's own default keymaps on GitHub — default-macos.json / default-linux.json — not guessed. Select the table to copy it as-is, or use the buttons.

Cursor handling — multi-cursor, the fast way.

The same gesture VSCode and Sublime trained your fingers on. Copy or save this one too.

Where you'll still want the old tool nearby — for now.

• Heavy JVM/Java refactoring spanning a huge project — WebStorm's PSI index is still deeper here.
• A must-have niche extension with no Zed equivalent yet.
• Built-in DB/HTTP tooling you rely on daily rather than occasionally.

None of that is a reason to skip Zed for everything else — it's a reason to keep the old tool one Cmd-Tab away for those specific jobs, and let Zed take the daily driving.

When Zed feels broken, it's usually reporting something real.

Two failures that look like editor bugs but aren't. Both start the same way: open ~/.local/share/zed/logs/Zed.log and read what Zed already knows.

• Symptom — quick-open lists the files, selecting one stalls. The project sits on a FUSE-mounted filesystem (the default Linux NTFS path, ntfs-3g, plus sshfs and friends). FUSE can't emit inotify events, so Zed's file watcher falls back to polling: a full directory walk every cycle — and node_modules alone can be a hundred thousand entries. The log says it outright: fs_watcher watcher error for Poll.
• Fix the mount, not the editor. Point the fstab entry at the kernel-space ntfs3 driver: inotify works through it, so the poll fallback never starts, and I/O stops round-tripping through userspace.

• Then shrink the walk anyway. file_scan_exclusions with **/node_modules, **/dist, build output. The list replaces the defaults (VCS dirs, .DS_Store…), so repeat those before appending — exclusions cost nothing on a healthy filesystem either.
• Symptom — every save reformats the file against the project's own lint style. A settings problem wearing a formatter costume. languages blocks match Zed's language name: a .vue single-file component is "Vue.js", not TypeScript — and a block that never matches fails silently, no error anywhere. The file falls through to the default formatter (Volar → Prettier's generic defaults), which undoes the project's ESLint style on every save. Slide 14's config names the language the file is; slide 15 has the full story.

That's the surface. Want the mechanism?

GPUI, the Rope, Tree-sitter, and the CRDT layer that makes multiplayer work — and how each compares to what VSCode and WebStorm actually do under their own hoods.