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.
Assuming developers avoid resource leaks (and to be fair some notable Electron-based apps tend to be both leaky and long-running) the main drawback of Electron seems to be the non-native look-and-feel. But that _could_ be worked around (for the most part) with some effort, and I suspect most users don't actually care that much. The web browser is still probably the most-used desktop app. The web look-and-feel is familiar and intuitive to users, even if it stands out a little from the UI of native apps.
Poor resource management aside, something like Electron is probably good _enough_ for most applications.
I have nothing intrinsic against electron, and I'll take everything back if I see these "natural fits" actually fit.
On the other hand, vim or Emacs with all features I personally currently use in vscode come in at a fraction of the memory usage, and it is a bit dumb to have to use that much ram for slack or discord considering how light IRC clients used to be.
VS Code is unusable on my laptop. I tried it, it's way too slow to be usable. I've used vim with a few plugins that got it to the same feature set as VS Code and it's actually usable. At some point I tried Lite XL, and it was incredibly fast with the same features. More recently, I tried helix and I can say that I've never used such a fast editor with auto complete and all that.
Most electron applications waste me time and energy (both human and electricity), and if software keeps going this way it'll start wasting me money. I'm not thrilled, but like you said, what are you gonna do?
That's the problem though: it won't. There is no modern system on which Electron apps run without being irritatingly slow.
Contribute more to e-waste! Pollute more! Consume! Consume!
A bog-standard 8-year old computer would be considered a supercomputer by the standards of the '80s, so at some point we ought to put some effort into making computers feel like the insanely powerful beasts they are. And Electron won't help with that.
Most people in this world would rather spend the required 400usd needed to get a >=8GB computer on fixing their vehicule/home and pay their monthly bills.
This +environment damage limitations.
Apart from the software and system engineers I don't know a single person in my social circle that own a computer with more than 4GB of memory. And I am not living in a third world country.
As a baseline, Electron performance _should_ be no worse than a regular SPA-style web UI running in the browser. Unless you find _everything_ on the web "irritatingly slow" it's surely _possible_ to create an Electron app with acceptable performance.
From my perspective anyway, I've both used and contributed to multiple Electron-based apps with performance that was not only "adequate" but not noticeably different from a typical native app. Basic Electron apps (done correctly) will look and feel more or less like a web app but perform more or less like a web app too.
FWIW there is a lightly-curated list of electron apps at https://www.electronjs.org/apps
I'm not sure offhand which of those is a good example of UI/UX and performance, but if you poke around with some of the medium-scope stuff (not too basic, not too ambitious) I'll bet you can find some examples.
UPDATE: I spot checked a few of those Electron apps for the fun of it. Here are a few examples you may find compelling:
* Deer - https://github.com/abahmed/Deer/releases/tag/v1.0.0 - A simple styled-text note-taking app that was last updated ~4 years ago. I don't _love_ all the UX choices personally but the performance seemed reasonable in my short test, especially considering the version of Electron they are using is 16 major releases out of date. There are probably more robust note-taking examples in that list (e.g. Inkdrop, Notable, Notion), this just happens to be the one I grabbed.
* Pencil - https://pencil.evolus.vn/ - A much more complex app for drawing fairly sophisticated Visio-like diagrams and UI mock-ups. Performance wise it seems about as responsive as a typical native app on my nearly 3 year old MacBook. But it may have large-ish baseline memory footprint so YMMV.
* I notice that some well known apps (or at least brands) are listed, like Trello, Asana, Notion, GitHub Desktop, Basecamp, WordPress, Twitch, Skype, Signal, Quickbooks, Light Table, Figma, WhatsApp, etc. For several of those I for one was not aware that they were Electron-based, and I'm guessing at least some (but probably not all) of those work pretty well. I think I've used both GitHub Desktop and Notion without anything to complain about but I'm not surprised that they are Electron apps. I've definitely used that Skype client and never noticed that it was an Electron app. I've never used it, but I'd bet Trello works well too.
IMO I think this demonstrates my original point in this thread: When an Electron app is well-engineered you don't even notice that it's Electron. It's survivor bias. People think Electron apps are bad because it's the bad apps that are noticeably Electron-based.
That said, the ratio of fast electron apps over slow electron apps is much worse than the one of fast native apps over slow native apps. If it's not the tech then it's the people around it. Either way, if I hear "hot new program" and it's electron, I don't think I'm in the wrong to assume it will also be rather slow.
At the end of the day, all I really care about is for the programs I use to work well and reliably. I don't really care how you make them, and as I said I don't have anything intrinsic against electron.