VS Code, for better or for worse, has evolved into something like an operating system or programming language VM, capable of running apps (extensions) which do useful things while only interacting with the VS Code extension API. This allows one to use such "apps" without installing VS Code.
Theoretically, one could run code in vscode.dev if an extension provides a programming language runtime. I'm not sure if there are any extensions which do this yet.
It is interesting to think about how many general-purpose VM-like abstraction layers are sitting on top of each other to run this — the operating system provides an interface which the browser uses, the browser provides an interface which vscode.dev uses, vscode.dev provides an interface which an extension implementing a programming language runtime uses, and the program uses the runtime interface.
Github Codespaces has the downside that you need to connect to a cloud computer and do all your development remotely on the cloud computer, which causes issues such as lag, the need to pay money for the service, inability to use it without an internet connection, etc. This provides the benefits (however small) of a development environment running in the browser without those downsides.
> VS Code, for better or for worse, has evolved into something like an operating system
Microsoft fully understands how valuable VS Code is and they are doing everything they can to keep developers interested, which is shaping its evolution. I have yet to find another open source project that has the same community involvement as vscode (https://devboard.gitsense.com/microsoft/vscode). The closes that I have found is vercel's next.js https://devboard.gitsense.com/vercel/next.js
VsCode is basically Javascript-Emacs but people really react with something between bother and disgust to that comparison. The extensibility on top of a very generic core has even encouraged a lot of comparable extensions. Like Roam/Org clones that basically function like org-mode or bespoke git clients. VsCode is very quickly becoming a platform for software.
From an XEmacs user during its glory days, where VSCode wins over plain old Emacs, is not only the JavaScript (more appealing to the masses than Elisp), it embraces graphics mode, and since the Browser is the new X Windows terminal, the experience feels much better.
However due to Electron, I feel we need to update the Emacs jokes to something more akin to Electron.
Superficially VSCode might share some similarities, but when you look at how Emacs works and how concepts differ, you very quickly will find, that VSCode is very far from being JS-Emacs. The whole focus of concepts is completely different. From buffers, to tabs, to keyboard focus, to plain text focus, to extensions/package and to inspectability.
That might be true, but I found it easy 30 years ago to learn how to modify Emacs, but spent 100s of hours trying to learn how to exert a similar level of control over VSCode, and never saw any significant signs I was getting close to my goal.
Profession web developers might have a different experience.
I agree with you that extending Visual Studio Code is a quite different experience, more akin to pulling teeth or writing COM controls in C++ in the 90s than to extending Emacs, which can be done live in your editing session as you work.
But. Seventy-five percent of developers use Visual Studio Code, with most of the rest being vim, neovim, or JetBrains holdouts. All of the brainpower for extensions and tooling integration is going into Visual Studio Code, not Emacs. Soon, Emacs will simply be left behind.
Emacs doesn’t have to be the most popular editor in order to find contributors. It is under active development and I don’t see signs that it would be left behind anytime soon.
While having the largest community is certainly a benefit to an IDE, it's not a death blow to the others. JetBrains is a paid editor so they have more resources per-user than an free editor. Also many tools are relatively easy to integrate or follow a standard (such as the language server protocol or dev containers) so all editors can benefit from those ecosystems.
It's not a walled garden like the mobile OSs work in building up tooling for one editor can transfer over to others.
That’s 75% using VSCode, not exclusively using VSCode. Combining all IntelliJ forks will yield at least half of the market and given how heavyweight they are, it’s reasonable to assume that VSCode is used as a “dumber”, “faster” for quick edits while actual work is done in “real” IDEs (that’s what I and my colleagues do anyway, I personally know at least 7 people with setup like that).
I'm definitely one of those vim holdouts, even though vscode vim support is pretty good. If vscode ever supports ctrl-z to jump into a full terminal and fg to jump back into editor mode, then I'll definitely convert.
VS Code certainly can be configured to have a keyboard shortcut to switch to a terminal and another shortcut to switch back and/or close the terminal. In fact probably every popular editor with a built-in terminal can do that.
