It's the "when you do things right, people won't be sure you've done anything at all" phenomenon. <https://www.youtube.com/watch?v=VofkquwmT40&t=29s>
(Disclaimer: I actually have RAM to spare, in constrained environments the situation might be different)
VS Code is pretty much the only larger electron app I think is very well done. Discord is pretty good, but then it starts going downhill. MS Teams is mostly responsive, bottom-of-the-barrel apps like postman feel like you are on a thin client remoting over a slow internet connection. And most electron apps sit between Teams and Postman.
But - beyond the base Chromium "footprint", which to be fair isn't negligible - you absolutely _can_ build high-performance, resource-conserving (and not degrading-over-time) applications with Electron.
It probably can't quite match the fully native UX or performance, but with a little care you can definitely get close enough (especially given how common actual web/browser-based apps are anyway). The trouble is Electron is already a "lazy" way to build desktop apps, so many teams probably don't give it the level of care it requires or deserves.
Disclaimer of my own: I maintain a media-rich, processing-intensive and performance-sensitive Electron-based app, so I may be defensive (or arguably informed) about the performance. But I can also consistently achieve 40 to 60 FPS rendering of dynamic graphics (full-screen) and audio (multi-channel) simultaneous with non-trivial, near-real-time input signal processing, on typical hardware, across platforms, just using Electron and standard web APIs. (And I'm just some guy working solo. A larger or more capable team would probably do it better.) The rest of the app's UI/UX is noticeably not native, but that's probably (but not entirely) more the result of _my_ limitations rather than Electron's.
Truly native apps are always going to work and perform at least a little bit better (in the general case) but IMO Electron (when done correctly) is at least on par with any other cross-platform framework you can point to.
It's a compromise, but it doesn't _have_ to be a major one.
And assuming you are talking about FATpick, it’s certainly a lot faster than Postman, at least the logged out part I looked at ;)
But I agree with your core point. I use VS Code all the time, regularly switching between maybe a dozen different projects, and I personally don't run into performance issues or resource constraints very often. Certainly less often than with heavyweight IDEs like IntelliJ, Eclipse or XCode. But I felt the same way about Atom as well, so maybe my typical project/workflow/usage pattern is less resource intensive than others. (For one thing I hardly ever run apps from _within_ the IDE, I prefer to build/test/run from a terminal, so that might be a factor.)
VS Code isn't quite as responsive or quick to start as something like vim, or even emacs when run in a terminal, but its resource demands seem roughly on par with any other feature-rich IDE/editor in my experience.
I'm on a trip in Brazil, and so far I saw 1 commercial system built in Java at a grocery store cashier, and 3 Government systems: Border and Customs office's computer, Postal Office ("Correios") point of sale (a desktop), and the software that must be used for tax return by all citizens (IRPF).
All of them used by millions of people directly or indirectly, all of them implemented in Java Swing.
- Four that I maintain directly which integrate together, so even if I’m only working on one at a time I often have to cross reference. This is a good candidate for a workspace, but lots of my workflow broke when I tried it. It’s entirely possible that’s solvable but I had more pressing work to do.
- Two related projects which I seldom contribute to directly, but integrate with the prior four, and I cross reference frequently as well.
- One for organizing and tracking work, notes, various work-related detritus.
- Generally my top three personal projects. I’m not working on them nearly as frequently, but they too are useful for cross referencing. And with seven windows already open, it’s slower to open and close them on demand than to just leave them up.