I assume you mean when nothing is loaded in it, or it's showing a plain HTML page. 1GB+ is completely common for a lot of Electron apps in real use. If you run a dev environment and are using 2-3 Electron apps, 16GB will be a struggle.
Currently sitting at 29GB (on M1 Pro), just for regular web dev environment on MacOS.
Having a system with lots of RAM, the OS does it's best to use it. Just because you see 29GB used doesn't mean you'd see a noticeable performance dip on a 16GB machine. You might, but it really depends what that RAM is being used for.
Yes, but that's normally what people mean when they talk in broad strokes about "electron apps". Anything beyond that is application data, which is going to be roughly the same regardless of stack, and in nontrivial apps quickly comes to dominate.
> Currently sitting at 29GB (on M1 Pro), just for regular web dev environment on MacOS
I mean, I assume you're using more than just some regular electron apps. macOS itself is currently using 8GB of RAM on my machine, my docker VM is using 4GB (down from a default of 8GB), etc. And that doesn't include my IDE and its code-scanning and type-checking background processes.
It's technically Chromium Embedded Framework instead of Electron, but last time I used the Spotify desktop client it was possible to push its RAM usage past 512MB up to the 1GB mark just by clicking through albums and artists.
For something extremely functional like a VS Code, which is a mini-IDE of sorts, that might be excusable but it's beyond silly for a streaming music player.
But it has nothing whatsoever to do with it being a web-based app. It pretty clearly has to be the result of caching lots of album art and/or metadata and/or audio data, which is just as likely to happen on a native app.
Web technologies in and of themselves aren't bad, but their usage is strongly correlated with cost-saving measures and the questionable technical decisions that result since choosing a web app itself is often a cost-saving measure.
VS Code is an example of things gone right, where Microsoft has clearly hired an AAA-class team and funded them well. Within the same company, Teams is an example of the exact opposite and much more representative of the typical web app.
In Spotify's case, if they're aggressively caching album art, metadata, and/or audio I would say that's of questionable value to the user. Art and information on songs/albums/artists/etc are in nearly all cases only going to be seen once or twice by the user per session, and so keeping them sitting in memory doesn't make a whole lot of sense. Caching audio that's not been played is very questionable (to the point that I don't think they're doing this) because many, many people are still on metered connections and Spotify would quickly be blowing past bandwidth limits if it were pre-caching albums left and right.
Disk caching makes a ton of sense for Spotify, given that it's being done in a standarized directory that the OS can clear to free up space when necessary, but on machines with 8GB or especially 4GB of RAM there's a very good chance that by aggressively caching to memory they're evacuating other things that would better serve the user to be sitting in memory.
Using a lot of memory is fine when there's clear user benefit but it should still be done intelligently.
> their usage is strongly correlated with cost-saving measures and the questionable technical decisions that result since choosing a web app itself is often a cost-saving measure
Correlation is not causation
We can debate the specific design choices that Spotify or any other company has made, but my original point was to push back against the tired trope that using web technologies for an app automatically means runaway resource consumption and (apparently) the downfall of civilization
Except in this case, correlation is so strongly correlated with causation that it becomes causation.
Look, the plural of anecdotes is not data, but you can't argue against the general trend of "applications using web frameworks like Electron tend to consume more RAM" by saying "well in this specific case they made poor design decisions that would bite anyone in the ass"; while that may be true it misses the point, which is the much larger (and well-correlated) & overarching tendency of such apps to absolutely chew RAM.
That it's a "tired trope" doesn't make it untrue; it just means that enough people have accepted what is functionally the new state of the software application world that it's considered passé to call such things out.
Ahaha, this is a tangent, but this stupid situation is why I'm doing my current web project as God intended: in a single .html file, shared with collaborators on Dropbox, editing in any dumb text editor.
