Void dev here! As others have mentioned, VSCode strongly limits the functionality that you can build as an extension. A few things we've built that aren't supported as an extension:
- the Accept|Reject UI and UX
- Cmd+K
- Control over the terminal and tabs
- Custom autocomplete
- Smaller things like ability to open/close the sidebar, onboarding, etc
It's been a lot harder to build an IDE than an extension, but we think having full control over the IDE (whether that's VSCode or something else we build in the future) will be important in the long run, especially when the next iteration of tool-use LLMs comes out (having native control over Git, the UI/UX around switching between iterations, etc).
>Smaller things like ability to open/close the sidebar
Are you sure about this one? I'm sure I have used an extension whose whole purpose was to automatically open or close the sidebar under certain conditions.
As an (ex) VSCode extension developer, VSCode really does lock down what you can do as an extension. It's well intentioned and likely led to the success of VSCode, but it's not great if you want to build entirely new UI interactions. For instance, something like the cmd-k inline generation UI in Cursor is basically impossible as a VSCode extension.
The restrictive extension ecosystem was a big part of VSCode's success. You can compare to Atom, which allowed extensions to do whatever they wanted: Atom ended up feeling exceptionally slow and bloated because extensions had full latitude to grind your IDE to a halt.
But since there seems to be a need for AI-powered forks of VS Code, it could make sense for them all to build off the same fork, rather than making their own.
Eclipse Theia can host VSCode extensions, but it also has its own extension mechanism that offers more customization, it could be a viable alternative: https://theia-ide.org/docs/extensions/
You're right that extensions do manage fine - the main differences right now are UX improvements (many of them are mentioned above). I can see the differences compounding at some point which is why we're focused on the full IDE side.
One of the big _disadvantages_ is that it prevents access to the VSCode-licensed plugins, such as the good C# LSP (seems EEE isn't completely dead). That's something to pay attention to if you're considering a fork and use an affected language.
Since these products supposedly make developers 1000x more productive it should be no problem to just re-implement those proprietary MS plugins from scratch. Right? Any volunteers...?
MS will be tuning Copilot to the point it’s the best agent for C#, for sure. It might take a little longer ofc. But Nadella mentioned to Zuck in a fireside chat that they are not happy with C# support in LLMs and that they are working on this.
Did you mean to say a debugger? That one has an open alternative (NetCoreDbg) alongside a C# extension fork which uses it (it's also what VS Codium would install). It's also what you'd use via DAP with Neovim, Emacs, etc.
Omnisharp is what the base C# extension used previously. It has been replaced by Roslyn LS (although can be switched to back still). You are talking about something you have no up-to-date knowledge of.
I wish all these companies the best and I understand why they’re forking, but personally I really don’t want my main IDE maintained by a startup, especially as a fork. I use Cursor, and I’ve run into a number of bugs at the IDE level that have nothing to do with the AI features. I imagine this is only going to get worse over time.
Of course I got downvoted (but it’s gone back to four now) because this is HN, where somehow a group of otherwise seemingly intelligent people are all patting themselves on the back about the latest Y Combinator AI slop funding.
