Atom has actually gotten significantly faster recently. It seems they've started to rewrite some core components of it in C++ for performance reasons. I've also used some Electron apps that are very lean. I think it's more of an implementation issue. Slack is pretty terrible at resource usage, for example, but Zeit's Hyper is very efficient & it's resource usage is comparable to iTerm in my experience.
Slack's issues with their electron app shouldn't be particularly surprising, either, considering it was their head architect that published an article on Medium advocating for PHP on the basis of it's concurrency model...
On a serious note, I think the insanity will stop when the operating systems will start shaming badly written applications and nudge users to get rid of them. It is in Apple/Microsoft interest, because users will blame their computers ("My Windows is getting slow...").
The phones already show the list of power hungry apps responsible for your battery life reduction, having this on a desktop would be nice too. If even a terminal needs 64 threads and 126MB of RAM now... looks like some wrist-slapping is in order...
That's a lot more threads than iTerm uses for me, but it's less memory. Typically my work computer (a 2015 15" MBP) tends to be bottlenecked on RAM, too. 16GB sadly is pretty much the minimum viable amount of RAM for me to do full stack development these days.
I've maxed out my 64GB a few times and have seriously weighed upgrading to 128GB. Running all the development environment on my localhost (where I'm the actual sysadmin) is really handy if your sysadmins are too busy to help you with their business side of things.
macOS already does present a list of apps that are using a lot of energy if you click on the battery indicator. I thought that Windows had a similar feature, but I'm not sure.
Well, seeing as so many applications remain single-threaded despite years of mainstream multi-core CPUs, that shouldn't be too hard. Especially with many mentors in our industry cautioning new programmers that "concurrency is hard" so often that—at least within my small social network—new developers have been conditioned to avoid subjects like threading.
Yes, concurrency is a challenge, but it's tremendously rewarding. Plus modern languages make it much easier than it was in the past.
microsoft put in a lot of work into how vscode buffers the html its displaying for the file, and it runs very well because of it. It is actually a very cool setup; if you get a chance do an element inspection of the monaco in-browser editor, as it uses the same method.
the same can not be said for atom, however.
I will say that, despite its many shortcomings and after I was able to overcome the netbook-induced Atom stigmas, I really do like the Atom for small-business NAS applications.
