Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I’d rather have heavy software than no software.
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...
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.
RAM is pretty cheap, I'd rather put money towards a better Linux machine than give that money to Microsoft for the OS.
Eventually, when every single desktop app is like this, and we can no longer keep shoving more RAM into computers, we'll realise that the only way to manage such hogs is to pickle background apps to disk Android-style and to just have one foreground app in memory. And that's when we'll all realise we might as well switch to Chrome OS. Well played, web devs, Google says thanks.
Or maybe Electron is a conspiracy by someone heavily invested in RAM production?
No, the real casualty in this cycle have been spinning rust, good old hard disks. Their performance was never great but a sure fire way to kill it and make sure it never recovers is to trigger a full fucking unthrottled index scan at every boot that inevitably finds nothing changed. Looking at you Dropbox.
Everything is cheap when you have a high salary even by your rich country's standards. There are other users outside of SV.
I rather put money towards responsible developers than contributing to the waste of more computing power and more electricity than Bitcoin wastes, while doing basically nothing over what Sublime Text can do.
I mean, if there were no other way to code a text editor I could accept the idea of Atom. But with faster alternatives, it is just an exercise in consumerism. Wasting computing power for the sake of wasting computing power.
It's the rolling coal of computers.
There are many laptops which have fairly low total system RAM limits. Those in our workplace are 4GB and 8GB for example. Once you hit that limit the cheapness of RAM is irrelevant.
It was quite productive and straightforward. That said, Java likes to use as much RAM as it can get even if it could release a lot back to the OS. It looks at it, sees it's free and thinks "I might as well take that".
That shouldn't be the goal. Linux and Windows have different norms when it comes to UI design, and (usually) have completely different widget appearances. You can save yourself a lot of headaches by just specifying the bare minimum (i.e. the widgets themselves) and letting the user/system remain in control of exactly how they appear.
In other words, if you're treating desktop GUI design as equivalent to web GUI design and expecting your app to look the same across all platforms, you're going to have a bad time.
https://github.com/yuya373/emacs-slack works on Linux, and doesn't chew up CPU, RAM & disk to do it.