> It's Emacs for Javascript people
I'll accept this premise.
> a good thing since Emacs is moribund
And here we part ways.
> and most programmers are at least a little bit Javascript people.
You might be living in a bubble.
> A highly programmable, cross-platform editor with zillions of extensions/modes that support all sorts of languages and environments.
Agreed; I think you're actually underselling how helpful it is that it's apparently a lot easier to get started with than emacs or the vi family. Power tools with a lower learning curve is a good thing.
> People complain about its resource requirements and performance, just like they did with Emacs.
And they're right to do so, especially with Moore's law wearing thin. Besides which, emacs (and n/vim, for that matter) are still around, and are just as functional in a much smaller resource footprint.
> Vi(m) users are the natural enemy of VSCode, just like they were the natural enemy of Emacs, continuing their long proud tradition of being wrong about everything.
LOL, that's... semi-fair, even if you're on the wrong side, of course;)
> I think that's roughly where it fits 'philosophically'.
I think it's fair to call VSCode "EMACS but with JS", but I think you're really glossing over the issues that it has in practice; maybe with a decade of maturation it'll be on par, but today I would argue that it is a resource hog, and still suffers from some poor design choices (such as letting extensions trample eachother, per the upthread discussion).
The difference between VSCode and Emacs is the difference between an extensible editor and a software omnitool intended to be extended, shaped, and refined as you work with it. Writing short programs in Emacs Lisp, seeing their effects immediately in the live editor environment, and then (should they prove generally useful) refining them into full-fledged modes or commands is quite a bit different than writing a packaged extension.
There is, still, nothing like Emacs in the editor world today. As much as Visual Studio Code gets right, it has a long way to go to get within spitting distance of Emacs in terms of adaptability and power (to say nothing of resource consumption).
I think the relative sizes of the 'Most programmers have at least some minimal familiarity with Javascript' bubble and the 'Emacs is not moribund' bubble speak for themselves and offer sufficient retort :)
If it work for you good, if not, fine. Just don't get crazy about it. It's just an editor!!
Why do you think that Vim users were/are wrong about everything?
But I think Vim bindings in an IDE or Vim with a LSP plugin is the killer combo.
The alternative used to be writing code over VNC (not fun!), but we’re now moving towards VS Code Remote. I don’t see myself changing to it anytime soon, though.
e.g. Would anyone take a plane that has modal cockpit buttons?
The big thing that classic vi got wrong with modes from a usability perspective is that changing modes is mostly invisible. In vim, however, you can configure it to change the cursor shape in different modes, and this is a pretty effective cue. (It's also the default behavior in gvim.)
(But ok, thats maybe just me - thought this is a common experience, and I just wouldn't like to sit behind a pilot doing the same...)
Pros: - Has plugins for anything.You're doing C++, just install C++ plugin and you're good to go. Want vim key bindings there's a plugin for that as well. I use a plugin that can scrape competitive coding websites and automatically create tests for a problem. - Git, snippets, etc all modern IDE features built-in. - It is also found on many websites as an editor.
Cons: - Since it's electron. System requirements are on the higher end.
Idle, it takes up a third of a gig of RAM on my laptop. Language server extensions are responsible for the majority of the load users encounter. That's certainly a good 2-3 times more than Sublime Text, but it's not going to be a deal breaker for a majority of people.
sharing part of OP's sentiment. in fact, i flipped the table a few weeks back because an extension downloaded a tool to my system and guess what? the installation got stuck. and guess what? my text editor hung!
all i wanted was to edit text. i didn't even ask for an extension. i was presented with one that supposedly would make my text editing experience better.
tiring...
* Tons of quality extensions, incredibly easy to install and manage
* Good color schemes
* ssh extension - remote vscode with all your plugins, themes, etc. with basically zero setup
* integrated terminal
I have no doubt that you can get a better vim setup, but getting vim fine-tuned takes a while for me and figuring out what I like. VSCode is convenient and easy, and works on everything, no suprises. Don't have to worry about fonts, terminal colors, config files, etc. I do think the vim plugin for VSCode is garbage compared with the terminal.
The worst behaviour of any editing environment is a lagging keyboard response.
In this COVID-19 era I've found myself working remotely over VPN and on some occasions the response times become very slow.
The most noticeable observation for me is how frustration writing code becomes whenever my editing environment slows over that lagging VPN.
Tasks that are normally subconscious suddenly turn into mental challenges as you find yourself constantly checking if these subconscious actions actually complete.
This is using a real neovim instance rather than emulation, and performance is excellent for me.
This issue is described in the link but I thought it deserves highlighting
On Mac/Linux I just use neovim with coc[1], which works beautifully.
I just switched after using vs vim and got much better performance.
I had neovim installed anyway for the EX commands
All extensions have to run on the same thread in a background process and intercepted keystrokes are passed to that process over IPC. So if other extensions (like the TS language tools) are tying up the extension host process, the Vim extension can't respond to your keyboard input until other extensions yield.
Performance issues come and go but for awhile I was stuck waiting for several seconds any time I typed a < after an identifier.
A lot of us have tried to demand a separate process for extensions that intercept keystrokes to solve this issue permanently. But the maintainers don't really care.