This is what happens when you build software on another company's platform. Why put your time making plugins for VS Code when rug can be pulled from under any time?
Because VSCode is a huge step forward for the vast majority of people.
For example, it took the might of Microsoft to force everybody onto a Language Server Protocol which is how things should have been done everywhere but nobody wanted to work together to implement it until they were forced to by VSCode eating their market share.
As a further example, VSCode is sweeping aside a whole bunch of absolutely garbage embedded programming environments, and I assure you nobody is crying any tears for them.
Furthermore, if you make your own plugin and distribute it, Microsoft can't pull the rug out from under your plugin. The core of VSCode is open source.
Unfortunately, the most popular plugins are proprietary and Microsoft can and will rip the rug out from under people at some point.
However, the problem is that nobody is throwing the resources behind the open source plugins that Microsoft is throwing behind the proprietary ones. While I find the current situation distasteful, I also see it as "Pony money up or shut the hell up."
Sadly, the world of open source seems to be populated by a bunch of cheapass whiners. So, yeah, Microsoft gonna pwn.
Quick point about embedded: in my short summer internship where I was working on some STM32 hardware, I was quickly exposed to the plethora of semi-proprietary embedded IDEs which were themselves based on FOSS IDEs and editors (STM32CubeIDE, MBED Studio, etc).
Why do these even exist? It boggles the mind. These companies (NXP, STM, Infineon, TI, Nordic, MBED, etc) spend money on maintaining all this software and paying their own developers/contracting this IDE development work out. In the end, they're just glorified Makefile + C/C++ linters and editors.
On the other hand, I had a particularly pleasant time writing embedded and remote C++ with CLion (it's still proprietary, but it's really good). I was writing a client C++ application running on the Raspberry Pi (cross-compiled, and remotely debugged) to communicate with an STM32 (also cross-compiled, and debugged with a probe).
The debugging experience was glorious. One breakpoint in the client triggered another in the STM32, and everything was just completely seamless.
Because there existed a time before ARM, 32-bit processors, and gcc made embedded a monoculture like x86. Because there existed a time before IDEs converged via Language Server Protocol.
This was predictable back when VSCode first came out. Microsoft was pouring more development resource into VSCode that many of those semiconductor companies entire revenue. Either you got on the VSCode train or you were going to get swept aside.
The fact that everybody is whining about proprietary Microsoft remote development plugins while emacs tramp lsp-mode remains broken for an enormous number of cases for years says it all (this is finally what pried emacs out from under my fingers as I got tired of debugging it).
But that's a different aspect of the platform -- the browser itself.
At least for the time being, on the Web side, there are so many different other browsers, that Chrome cannot break step with all of them at once.
And so if I write basic HTML and test it thoroughly, I can accommodate almost any user on any device, browser, and configuration. And this makes me very happy.
i dont think this is true any more - chrome has such a high market share that they can basically dictate the standards, and force other browser vendors to follow suit.
I personally use test with over 50 different browsers, most of which are quite usable.
The web is now big enough that I can build my own little nooks and use the sites I like while avoiding others.
It's so freeing to realize that anytime a site gives me a newsletter modal, or an ad, or a cookie consent, I can just close it and move on.