I'd put it slightly differently, but I guess it is the same idea.
There are two major approaches to software development: 1) powerful text editors (vi, Emacs) or 2) IDE.
Powerful text editors are universal, but up to now their language support was often subpar compared to IDEs. They tend to do well for niche languages with no dedicated IDE, as then they're the reference editors. But for mainstream languages on can usually find IDEs with better language specific support. Still, they shine in pure editing power and after an initial investment you can use them for anything text based.
Then an IDE can have the best language support for some usually small set of languages, but is not as powerful as a vi or Emacs for pure editing.
That's the situation so far, but I see this changing thanks to the language server protocol [1]. It's the pattern seen in portable compilers, where a universal IR avoid a MxN explosion with M languages front-ends and N target ISA. Except here one avoids the M editors times N languages by having a universal protocol between an editor and a LSP server for a language. What the LSP allows is decoupling your editing front-end from the language support back-end (the LSP server).
All this is a bit young, and moving fast, but in time it offers the possibility of a no-compromise experience: use the best editor for you, and still get the best language support available. It's already possible to extract Eclipse Java support, or Microsoft Python support, and use it with any LSP compliant editor for example, with some ad-hoc work. In time, all this should get more streamlined. Which makes me happy to have invested into Emacs ;)
Also, IDEs tend to have better framework support (it's nearly impossible to write Java code without one because you want an IDE that knows about Spring or Hibernate and can make all the Gradle stuff work), but that's economics - it's easier to sell an IDE than to sell an Emacs minor mode (which would end up having to fit in a with set of other things that may or may not conflict with what you have).
> That's the situation so far, but I see this changing thanks to the language server protocol
It’s really interesting how LSP shifts what I’ll call “Visual Studio only features” into all editors, while at the same time you had Microsoft being the ones who initially pushed for LSP-adoption.
I wonder how many internal discussions they had on this subject before saying “Go”.
It’s a fantastic initiative and I’m glad it’s there for me, in my Emacs today.
LSP is fine and all, but as a one-size-fits-all protocol I'm guessing it will never reach the level of flexibility and extensibility required to implement something like IDEA/Rider level refactorings, hints, and the general level of "code understanding" by the editor. It's a bit hard to explain, but JetBrains' IDEs really feel like they understand your code. It feels more like editing an engineering diagram, or tinkering with a mechanical contraption, and less like editing free-form text (which code is definitely not). That's how it should be, I believe.
Visual Studio-like IDEs are a dead end. There is little revenue opportunity in them and a huge downside in losing relevance in the overall developer mindshare.
How many of us would be using a Microsoft IDE/text editor if it were not for VS Code?
So, you propose to give up on Visual Studio because in 20 or so years maybe Windows and XBox won’t exist? Or?...
Also, speaking of IDEs. There are also Jetbrains’ IDEs and XCode. Can’t speak for XCode, but IDEA offers capabilities that Emacs can’t even begin to approach.
And ironically, I'd argue that Visual Studio Code despite the name is more of a member of the former (it is basically an Atom clone) than it is like traditional Visual Studio.
There is no right or wrong answer, but I like the Emacs way.