Hacker News Reader

Comment by nm980 | Hacker News Reader

Is there some benefit from forking vscode instead of creating an extension?

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).

the Accept|Reject UI and UX , Continue as a VS Code extension also seems to manage this

>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.

Maybe someone should just fork VS Code in a more liberal way, then everyone can build their extensions on top of that.

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.

Yeah, I don't have a problem with that!

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.

Isn’t that what they’re doing by building off of vscode?

Yup, just rebased about a week ago

Ask Firefox how that went.

Hint: they dropped XUL because every update broke extensions

That's not comparable though, right? I'm suggesting a third party forks the main product.

Worse. The result is the same: an unmaintainable product, and now you also become increasingly incompatible with the source.

People keep saying that the extensions API is too limited or something, but Cline seems to manage fine with being an extension.

They've been changing that recently

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.

C# language server, being Roslyn Language Server, is plugin agnostic, it's MIT licensed and is essentially a part of the compiler: https://github.com/dotnet/roslyn/tree/main/src/LanguageServe....

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.

Nope, OmniSharp - which uses that AFAIK, is what I'm referring to. Something being open source doesn't automatically make it good.

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.

It gets them more slop funding if they can say they have an “AI IDE”.

well you got downvoted, but it's not wrong: funding attractiveness of an extension (Cline) vs your "own IDE".

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.

Reply on news.ycombinator.com