Well it's a helluva lot faster to make for one. For two, just about everyone knows how to navigate in vscode by now. Reducing the barrier of entry has obvious advantages.
I just opened the app to see what else I can bring up, and while clicking through UI I noticed I had some crappy key bindings extension installed, which apparently caused many of my annoyances.
I've probably installed it very long ago, or even by accident.
For example, I was always annoyed that open file/directory shortcut (one of most common operations) is not assigned and requires mouse interaction -- fixed by disabling the extension.
Go to file shortcuts does something completely different -- fixed by disabling the extensions.
I likely won't adopt Cursor as my main IDE/Editor, but it's miles better than I thought just an hour ago.
Not the person you asked, but I hate how it screws up keyboard shortcuts.
It overrode the delete line shortcut with its own inline chat one, for example.
Decided to ditch it for claude code right after that, since I cannot be bothered to go over the entire list of keyboard shortcuts and see what else it overrode/broke.
I've found that annoying too, but you can always rebind them as you wish. It's only a few new keybinds that get in the way of my muscle memory.
That said I also have moved to CLI agents like Claude Code and Codex because I just find them more convenient and, for whatever reason, more intelligent and more likely to correctly do what I request.
> just about everyone knows how to navigate in vscode by now.
I don’t know and honestly I hate the assumption of the software industry that everyone knows or uses vs code. I stuck to sublime for years until I made the switch to Jetbrains IDEs earlier this year.
I quickly looked up the market share and VS code seems to have about 70% which is a lot but the 30% that don’t use it is not that small of a number either.
Like I get it it’s very popular but it’s far from the only editor/IDE people use.
These new editors are trying to differentiate themselves via their AI features. Working on the core editor may waste resources that could have been better spent improving the AI features.
Until someone finally figures out that we need to rethink editors from the ground up to support different sort of operations and editing experience, to better facilitate LLMs doing work as agents.
But we're probably 1-2 years away from there still, so we'll live with skinned-forks, VSCode extensions and TUIs for now.
It's actually weird to me how none of the big players put their money where their mouth is and vibe coded a new IDE built from the ground up for this paradigm shift regardless of tech stack.
Zed team is writing their own in-house GUI stack [1] that leverages the computer's GPU with minimal middleware in-between. It's a lot of work short-term but IMO the payoff would be huge if they establish themselves. I imagine they could poke into the user-facing OS sector if their human-agent interaction is smooth. (I have not tried it yet though)
I am very sensitive to input latency and performance but after comparing Zed and VS Code for a while I really couldn't find any reason to stick with Zed. It's been a year or so since I last tried it but VSC just lets me do way more while still, IMO, having a nice, clean UI. I never notice any performance or key input latency with VSC.
> I wonder why they are not trying to fixup something extremely complex that only a handful players managed to get right using gui stacks made with only mobile in mind that are desperately trying to catch up to desktop now
We need a VS Code fork that just exposes more interfaces, and does nothing else. Then all these forks could just use that with power extensions, and it'd force Microsoft to change its behavior.
The issue with Eclipse and that approach is the complexity of mixing plugins to do everything, which kills the UX.
When VSCode started, the differentiator from Atom and Eclipse was that the extension points were intentionally limited to optimize the user experience. But with the introduction of Copilot that wasn’t enough, hence the amount of forks.
I think that the Zed approach of having a common protocol to talk with agents (like a LSP but for agents) is much better. The only thing that holds me from switching to Zed is that so far my experience using it hasn’t been that good (it still has many rough edges)
Microsoft just fork Atom, and Atom had already good and a lot of extensions.
Before Microsoft buy Github, there was no reason to switch to VSCode instead of Atom.
When Microsoft buy Github, it received Atom from the Github team, and Microsoft stops the development of Atom.
VSCode was just Atom with the Microsoft brand, and some little tweaks from Microsoft, never a game changer compared to Atom, like Atom was in it's time.
Now Antigravity is again a fork with some little tweaks from VSCode, no game changer, just with the Google branding.
I guess we have different perspectives and information about the “rise” of VSCode.
I was an Atom user. Even before the acquisition of GitHub the major feature of VSCode was its speed and TS integration. AFAIK, the only common part between Atom and VSCode is Electron. Other than that, VSCode started with a different codebase based on TypeScript, while Atom was originally written in CoffeeScript.
Multiple design decisions helped VSCode to thrive (btw Erich Gamma was also part of Eclipse):
- The creation of the LSP. Each release of VSCode is also tied to TypeScript releases and improvements. There is a lot of collaboration between the two teams. That gave VSCode the best support for TS and JS. I used Atom and WebStorm regularly when VSCode came out, and VSCode auto-complete and TS support were orders of magnitude better. Everybody caught up since then, but I guess many users like me switched because of that.
- Unlike Atom, VSCode was designed with web integration in mind. A lot of sites started to use Monaco for code editing, and a lot of web-based IDEs use parts of it (CodeSandbox, StackBlitz, etc).
- Gradual rollout of plugin integration. While Atom has the philosophy of everything is pluggable, VSCode was intentionally limited. Which was a good thing given the poor loading performance of Atom.
By the time MS acquired GitHub, Atom usage was already in decline.
* Note: my side of the history, comes from my experience of working in a company that did a custom Eclipse IDE. We evaluated Atom and then VSCode as alternatives to “modernize” our IDE. So I have experience in looking at both Atom and VSCode code bases: they are totally different. Also, the main problem with VSCode for us was the limited extensibility.
> By the time MS acquired GitHub, Atom usage was already in decline.
I wanted to second this: I compared both, with Atom experience starting before the first VSC release. Atom had performance and stability problems continuously through that period, and never really won any of my coworkers over. A lot of that was simple performance: I remember using Is It Snappy? to test my subjective impression and finding that input latency was a full order of magnitude worse, which is the kind of thing which really colors your impression of an editor.
Microsoft has very specific constraints on what extensions can and can't do, it's not a free for all. They're actively defending their mote by allowing Copilot to do things in a way that extensions couldn't. That's why all the serious contenders make a fork, it's simply not possible to have the same integration otherwise.
Because it just searches Google and HN is indexed regularly, nothing really noteworthy. If you copy paste the same quote into Google you get the same thing.
Still it would be a lot wiser if all the forkers would do one 'AI-enabled' fork together that exposes all the extras that copilot gets. The barrier for testing would be much lower and all the extension makers would also jump onto the train. Likely MS would finally give in and make all the extras available for everyone. But all the fragmentation only helps MS.
I've had a Github Copilot subscription from work for 1yr+ and switch between the official Copilot and Roo/Kilo Code from time to time. The official Copilot extension has improved a lot in the last 3-6 months but I can't recall ever seeing Copilot do something that Roo/Kilo can't do, or am I missing something obvious?
The Copilot extension uses proposed APIs, meaning it's on an allowlist bundled with VS Code. Roo likely enables these early. The API can stay proposed for years before Microsoft opens it up to third party users.
They're all going to have quite divergent opinions on how to structure the fork and various other design decisions that would inevitably lead to forks of the fork again.
I think forking VS Code is probably the most sensible strategy and I think that will remain the case for many years. Really, I don't think it's changing until AI agents get so ridiculously good that you can vibe code an entire full-featured polished editor in one or a few sessions with an LLM. Then we'll be seeing lots of de novo editors.
The Claude Code extension on VS Code does very little (too little in my opinion). The integration level with agentic functionality provided by Antigravity goes much deeper in my 20 minutes or so of playing with it. The biggest value pieces I see is: Agent Manager window which provides a unified view of all my agents running across all my workspaces (!) where I can quickly approve or respond to followup questions and quickly brings me to the code in context for each agent, additionally, I can select a piece of code and comment on it inline and that comment gets sent to the correct, active agent. These two things alone are items which I have been looking for... Too bad I only have approval to use Claude Code at work. This looks promising.
Well, you are entitled to your opinion but many people would disagree with you, and that's the crux of the issue, everyone has their own conflicting views on what the UX should be, hence all the forks.
I don't even know what the Claude Code extension does in vscode. I have it installed but hell if I know what it's doing. I run Claude in one of vscode's terminals, and do everything through there. I do see (sometimes) diffs pop up in the IDE, I guess that's the extent of this integration.
> AIUI the forks are required because Microsoft is gatekeeping functionality used by Copilot from extensions so they can't be used by these agents.
reply
I always wonder how this works legally. VSCode needs to comply with the LGPL (it's based on Chromium/Blink which is LGPL) ; they should provide the entire sources that allow us to rebuild our own "official" VSCode binary
Could you give an example of what they're gatekeeping for Copilot exclusively? I'm kinda confused because Copilot in VS Code isn't exactly a powerhouse of unique features in my experience, it still feels well behind Roo/Kilo Code in most ways I can think of, although much closer to the competition than it was a year ago.
I was going to ask why all these companies choose to fork the entire IDE rather than just writing an extension like every other sane developer, and this response is the most believable reason why.
But Microsoft made VSCode lol, I think being able to gatekeep things like that shouldn’t allow a billion dollar company just reuse all of your code instead of making their own IDE
> 2024: every day a new Chrome fork browser is announced
I think this was more accurate around 2012. My local tech magazine had their own fork and they attached CD with the magazine which included the browser.
2024: every day a new Chrome fork browser is announced
2025: every day a new AI IDE vscode fork is announced