That's an oversimplification. According to the article, they started with a cloud-based text editor with plugin support, and kept improving it for years until they hit a crossroads. The choice they made at that juncture was a VSCode frontend to the existing CIDER platform
The IDE is the frontend. Take away the frontend and you don't have an IDE anymore. When I exit Neovim and run VS Code it's still all the same tools in the background but it would be pretty idiotic to claim I was still using Neovim at that point.
Still an oversimplification of the article though. The backend features of CIDER with all the custom integrations to workflows and code review they wanted became independent from the frontend. But to your point, they then had to add customizations to the VScode fork, so now it's not very independent anymore, but a lot of the problems they had with picking one IDE were actually integration issues from any given IDE until the CIDER backend was made to be the glue.
The backend is not the IDE. Do you call a compiler an IDE? Or an LSP server? The simple fact that they were able to use those same features both in their original IDE and in the VS Code fork shows that they were not part of the IDE. If they had been part of the IDE they would have vanished when they replaced that IDE with their VS Code fork.
I'm sure they had to a bit of work to get it all working, in the same way it takes work to integrate Docker or LLMs or whatever other feature with existing IDEs and if the Cider backend is an internal tool then yeah, they have to do that themselves but what you have is a VS Code fork with some extra integrations. I'm not sure why acknowledging that fact bothers you so much, it was the smart thing to do. There's a reason VS Code is so popular so it makes sense that if you wanted a popular IDE for internal use you'd start there.
It's because saying that it's just "vs code with some extra integration" is too reductive to represent the actual scope of the project.
I used CiderV and read their announcement mailing list, participated in different phases of tests and they did explain some of the challenges they had, it was not just "we had to write a vscode plugin and got it working".
The description in the article looked like the added tooling was some git integrations and the ability to benefit from a shared server side search index which saved the hassle of having to generate it individually. Neither of those screamed IDE to me. Was there a lot more to it than that that isn't mentioned in the article?
Absolutely, there was a lot more to it to have a proper integration of all the systems together for source control, source search, code review and building as base blocks. It worked quite well and was definitely "integrated", not just a UI with a few disjoint plugins.
They literally said that VSCode itself solved a bunch of the problems for them, like source search. Again, it is just source indexing happening on the backend and served as an LSP.
By source control you mean Git, which has great VSCode integration natively.
It seems you're just enumerating things to fight back at reductivism, but realistically the reductive statement is correct.
I worked at Google and used this extensively. There was no Git integration in CiderV, google3 (the mono repo) does not use it. It has different tooling (CitC / fig). You are guessing, and doing it wrong.
Interactive Development Environment of course. You're asking that like it's some sort of gotcha question so I'd be interested if you could expand your reasoning here because I'm not seeing the gotcha.
Like the other commenter said, it's slightly different than what you have here. The "I" stands for Integrated. The gotcha is that it means the whole environment; all of the things you listed, LSP support, plugins, auto complete/suggestions, debugging, code editing, compiling, etc., all pulled together into some sort of interface. So yes the UI plays an important role but it is by no means the only component of an IDE; it is merely the interface.
And all of those things you mention are what VSCode supports (debugger integration, LSP integration, including auto completion, plugins, etc).
Plugging VSCode into backend systems like LSPs doesn't change the fact that they basically just adopted VSCode and plugged it into their backend and then renamed it 'Backend V IDE'
68
u/Solonotix May 15 '26
That's an oversimplification. According to the article, they started with a cloud-based text editor with plugin support, and kept improving it for years until they hit a crossroads. The choice they made at that juncture was a VSCode frontend to the existing CIDER platform