Why many developers still keep VS Code installed alongside Zed #59308
Replies: 2 comments
|
The things you mention there are things that would require the development of sort of internal software development platform. To include features that many of us believe have no business being inside a text editor even though VSCode has (almost uniquely) popularised this kinds of thought that the text editor should be a complete operating system and do all tasks. I want the Zed team to focus on developing a really good tool for editing source code. When I want to manage my Kubernetes cluster I will reach for a kubernetes tool. |
|
I think the difference comes down to how we define a development environment. I don't expect Zed itself to implement Kubernetes, databases, cloud management, or every other developer tool. What I am arguing for is the ability for extension authors to integrate those workflows into the environment when they are directly related to the code being written. For example:
These are not unrelated activities. They are often part of the same development loop. Every context switch—changing applications, finding the correct window, reconnecting to a tool, navigating back to the source code—adds friction. The goal is not to turn Zed into an operating system. The goal is to allow extensions to reduce unnecessary context switching for workflows that are already tightly coupled to the code being edited. Whether users want that workflow should be their choice. The editor itself doesn't need to ship those capabilities. It only needs to expose enough extension APIs for the community to build them. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This discussion is not about missing individual features including database clients, Docker tooling, Kubernetes integrations, or any specific extension.
It is about a structural limitation in the current extension system that prevents entire categories of developer tools from existing in Zed.
Today Zed already provides:
From an editor perspective, it is already competitive for core development workflows.
Yet in real-world usage, many developers still keep VS Code installed.
The gap is not editor capability
The gap is not in editing, syntax support, or core IDE functionality.
The gap is in what the platform allows third-party developers to build on top of it.
The current pattern
A significant portion of widely used developer tools in VS Code are not editor features.
They are full applications implemented as extensions:
These are not lightweight extensions. They behave like embedded applications inside the editor.
The underlying constraint
The common denominator across these tools is not the domain (SQL, Docker, Cloud).
It is the requirement for:
These are platform-level capabilities rather than language-level features.
Current fragmentation of discussions
Existing discussions already point to the same underlying limitation:
Individually, these appear as separate feature requests.
Together, they point to a missing extension platform layer rather than missing editor features.
The strategic model
There are two fundamentally different scaling models for developer tools:
(A) Vertically integrated editor
Most functionality is implemented and maintained by the core team.
(B) Platform-first IDE
Complex, stateful, UI-heavy tools are expected to be built by third-party extensions.
VS Code scaled primarily through model (B).
Zed today is still largely constrained toward model (A).
The practical outcome
As a result, developers who prefer Zed for editing still maintain VS Code for:
This is not due to missing editor features, but due to the inability to implement equivalent extension systems within Zed today.
Core question
The key gap is not feature parity with VS Code.
It is whether Zed intends to support an ecosystem where complex, stateful, UI-heavy developer tools can exist as first-class extensions.
Without this layer, entire categories of widely used developer tools cannot migrate from VS Code regardless of editor quality.
Question to the maintainers
Is Zed intended to evolve primarily as:
(A) a vertically integrated editor where most functionality is implemented and maintained by the core team,
or
(B) a platform-first IDE where complex, stateful, UI-heavy developer tools are expected to be built by third-party extensions?
This is not a feature request.
It is a strategic architectural decision that determines whether full categories of developer tooling can exist in the Zed ecosystem.
In practice, this will determine how Zed is adopted in real-world development workflows.
All reactions