This part of your comments nails 100% why, for me (web developer, 90% in typescript these days), it's nearly impossible to justify paying for an IDE.
Visual Studio code has almost everything that I need, and what it's not baked in, is easily done with a plug-in, which in the worst case I can write myself. But that's really a worst case scenario, since to this date it has never materialized as all my needs are covered by existing, and excellent, plugins.
I’m flipping between Jetbrains and VS code a bit, but Jetbrains is by far the superior experience.
If you're going to roll Jetbrains then the more RAM the better and a good CPU also helps.
Obviously, this means MacBooks that aren't fully kitted out are bad picks.
In my experience, the lazy autocomplete takes less resources at start but the result is that autocomplete suggestions are loaded in as files are being parsed. The larger projects grow, the slower this process is.
I suppose slower CPUs like the i3 series and low i5 series Intel chips will probably have a lot of trouble with the indexing. You need a laptop with a decent sustained core speed to do the work (which can be a major deal breaker in cheap Windows laptops and the lower tier Macbooks), but the few seconds wait you get on a professional machine when a project gets loaded in is well worth the wait to me.
Shitting on tools because you read a couple disgruntled comments about indexing without honestly evaluating the tool yourself says a lot.
VS has now mostly caught up with their feature set, and the only thing I miss is namespace refactoring (which I could implement myself with Roslyn.)
Is R# just an exception, perf-wise, to their track record?
The reason I pay for IntelliJ IDEA is exactly the fact that I don't have to install any plugins, or fiddle with config settings, or really do much of anything; the product works extremely well out of the box with all of the IDE features I would ever want (and then some). The last time I seriously tried VS Code[0], I felt like I was constantly trying different plugins and changing various settings in order to get it working the way I want, and many of them weren't quite as polished as what I get immediately with IntelliJ.
[0]: Admittedly, this was over a year ago, so it's possible things have improved. But I'd rather pay $89/year than spend the time to find out.
Some of them are for minor customization like hot keys to move tabs. But the product doesn’t support Environment Variable configuration very well.
For example, Pycharm can’t injest a .env file. The devs point at a plug-in, but that doesn’t cover runtime and terminal / python shell.
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 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.)
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.
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.
Emacs 27 (released recently) with native JSON support was reportedly a huge improvement.
The `native-comp` branch on master is receiving great feedback too.
It really depends on you wanting to use something like Emacs, of course.
The text editor in VSCode is better than VS (multi cursor support isnt great in VS). I would love to see VSCode get the smart refactor features from Visual Studio, working with Typescript.