I used Emacs for 10 years. When I started writing JS almost exclusively at my current job, I switched finally to VSCode (albeit with emacs keybindings).
The plugin/extension experience between emacs and vscode is, of course, almost an apples to oranges comparison. But VSCode is much better in that regard in my opinion.
I want yak-free IDE. After ten years my Emacs config is a herd of beautifully shaved yaks. VSCode is yak-free, for me, right now.
The problem I've had with VSCode - and also Sublime, as it happens - is that on a moderately large JS project it's something of a CPU hog. Both editors seem to do a lot of indexing, and this is even with loads of ignore folders configured.
The irony is that this has driven me to try emacs. I am being driven nearly to distraction by the fact that every single operation seems to almost glory in using a different key combination than any other editor I've ever used. Even TAB can't be used for indentation because emacs is "opinionated" (or, as I prefer to call it, "a twat") about it in most modes, but you can get what you want with M-i.
The thing it absolutely seems to nail is performance. I'm getting zero CPU thrashing on the same project, and auto-complete-mode, whilst not quite as good as VSCode's autocomplete, is much better than Sublime's. For one thing it seems to work well across files, even when using ES5 with no typing hints.
The payoff in a cooler laptop and longer battery life is worth the sometimes seething frustration in the meantime.
(Of course, at the moment I'm squandering most of that extra battery life looking up keyboard shortcuts, but that will pass.)
> The thing it absolutely seems to nail is performance. I'm getting zero CPU thrashing on the same project, and auto-complete-mode, whilst not quite as good as VSCode's autocomplete, is much better than Sublime's. For one thing it seems to work well across files, even when using ES5 with no typing hints.
Speaking of ironic, yeah. Emacs used to be the massive resource hog, compared to it's competition (BSD vi?) back in the day -- the joke was that EMACS stood for "eight megs and constantly swapping", back when 8MB of RAM was a lot. It's just that, after that, they failed to keep up with Wirth's law.
Ha! I remember that. The joke had started to come unstuck a bit by the time I first used emacs in 1999/2000 (my own machine had 128MB, quickly upgraded to 256MB of RAM), and we weren't making much use of the multi-user aspects of UNIX, but it still had some currency amongst older hands in the department (and in my first job or two).
One would imagine that most CPU load because of rescanning would happen in the language server, and those should be the same between VS Code and Emacs.
Yeah I tried to use Emacs, but the LSP had way worse performance than in VSCode and was very glitchy. I was disappointed because I really enjoyed Emacs in other ways, but I couldn't get that to work reliably. Maybe I was doing something weird.
The plugin/extension experience between emacs and vscode is, of course, almost an apples to oranges comparison. But VSCode is much better in that regard in my opinion.
I want yak-free IDE. After ten years my Emacs config is a herd of beautifully shaved yaks. VSCode is yak-free, for me, right now.