I defend decisions made by IDE developers because those are niche markets, but slack is not a niche market. They're "IRC for normies" (yes, yes, they fix a lot of cruft too but, it's effectively the same system).
We're not talking about hand optimised assembly, but maybe assuming that I'm going to throw 1/8th-1/3rd of my system resources into your IRC clone is not healthy.
the highest tier macbook pro can only handle 16G of memory. I had to get a special laptop (precision 5520) in order to get 32G of ram, which I feel is the only option that is future-proof for the next 3 years, and if everyone follows the slack model then it will be the minimum in less than that.
But that would encourage competition and open up the market, something that web 4.0 companies never want.
Most users think their computer is broken, or they have a virus, or something along those lines because the perceive how slow their computer is but they don't have the knowledge to place the blame where it belongs.
Some posters seem to think that, because you CAN build a chat app consuming a few megabytes of RAM, it means you should and it's practical. It's like pointing to 64KB demoscene games and saying "see, you can write a game in 64KB, why does this one take multiple gigabytes".
Well, by all means, create a Slack competitor in hand-optimized assembly if you wish. Or whatever else you prefer (Rust?). If it's a better product, it may take over market share. Assuming your users even care about that. Hint: most are not obsessing over TOP, Activity Monitor, or whatever your OS uses.
Otherwise, don't whine. Electron makes it possible to create and ship apps very very quickly. Apps which would not exist otherwise. Every time you remove a barrier, you open up doors for more people.
While spinning up an entire browser for a single app has memory usage implications – namely, the baseline consumption is high, as is download size – the biggest issue is that it is easy to be wasteful when using web technologies. Look at Visual Studio Code, for instance. It's light and nimble compared to alternatives. It's true that a single one of its workers consume as much memory as a whole Emacs instance, but the development pace is staggering. And it still uses less memory than Slack...