They always have had. It just depends on what people perceive to be advantageous. For me, VSCode's and IntelliJ's closed model for extensibility is a huge downside.
By "closed" I mean - restrictive plugin APIs, sandboxed execution environment, corporate gatekeeping, opaque core, etc.
I don't even try to "shop for more features" anymore, learning Emacs allows me to remain "goal-oriented", and more often than not, it enables me to get the shit done in a far more satisfactory manner. Meanwhile, almost every time I switch to IDEs, I hit some limitations. It's not even "skill-issue" or unfamiliarity, I do remember my days of using IntelliJ, of which I was a devoted user for almost a decade. The way how I solve problems with Emacs, is just not even close.
More and more they've become just another IDE with too-much-to-do. Still one of (the?) best, but as soon as your editor becomes impractical to use to edit a text file... (because it really just likes to work on projects...).
But yeah, emacs remains functional in a way that JetBrains...probably won't. I'm already more than several years behind on their releases because they stopped putting a decent product...
WebStorm was probably the biggest reason why it took me so long to switch to Emacs. My biggest fear was that if I invested in learning Emacs, and at some point I'd inevitably find that something simply couldn't be done in it, and I'd be forced to go back and my idyllic life would be ruined. God, how wrong I was. Not only have I found _everything_ I needed, I actually discovered radically different ways of solving problems.
In the end, turns out one thing jetbrains did right - they have nailed the marketing - I surrendered without resistance. My biggest regret is not trying out Emacs sooner. I wish someone very persuasive showed me things I did not know were possible. That's why I get very vocal about it - kids have zero idea what they'd be missing.
Pretty much the only advantage is that you get access to logic available in the claude code CLI - which in large parts probably already exists in emacs or extensions. On the downside it'll bind you to claude code.
I'm generally using a generic LLM wrapper - emacs has two good ones, gptel and llm. I have both configured, as both are required by some of the extensions I'm using, but currently prefer gptel: It seems to be more advanced, especially when it comes to tool use.
Advantage of that approach is that when you're hitting a wall with one LLM being stupid with one specific issue you can just switch to a different one. Or you can use the same environment with locally hosted LLMs.
Disadvantage is that the IDE/project functionality is not tied up that nicely yet - there are a few attempts (like minuet or evedel), but nothing I really got into.
Currently I'm mostly doing a chat buffer, and the LLM has tools available to inspect and to some extend alter the current state, published here: https://github.com/aard-fi/gptel-tool-library - that works pretty well on a per file basis, and to some extend it can figure out project details, but overall it lacks project info - in part that's a context limitation thing, where that info should be provided as additional context for each instruction (which I assume the CLI is doing).
What this approach also nicely enables is fun experimentations:
- https://github.com/aard-fi/buffer-turtle implements simple turtle graphics in an emacs buffer, and has bindings for the LLM to control the turtle - https://github.com/aard-fi/arch-installer has the glue to have the LLM interact with a serial port, and some glue (like basic ANSI escape parsing) to make the result look somewhat reasonable in an emacs buffer. That allows it to do stuff like trying to install Arch linux in a VM
Both repos have links to youtube videos with some runs.