It's a bit of a shame that the RAM is so limited on all those platforms - I can't imagine it being enough to load many electron apps in a few years time.
It's a bit of a shame that the RAM is so limited on all those platforms - I can't imagine it being enough to load many electron apps in a few years time.
I honestly hopoe Electron has to improve it's performance or companies start moving off of it. It's honestly a bit of a joke at this point.
A native app, lets say that wants to play video and is using a cross platform GUI. You've got to load and run that code, and have all the relevant code in the native app's address space. That would be a bunch of code that needs to load over the PWA which is leveraging something you have loaded in RAM anyway. In this case the native is actually worse than the PWA for resource utilization.
Launch CPU cycles can be similar, running a huge swath of GUI code for the native app vs a pre-loaded browser which only needs to run the JS and render the page.
Having your app's runtime already loaded on the system is a huge advantage.
Electron does not benefit from these advantages though. These are PWA exclusive advantages.
Yes, because CORS, a way that HTTP requests are restricted, doesn’t even exist in native. Of course a native app can reach out to any URL it wants. That is the default, and also how CORS functions when disabled or bypassed.
I just don't see how 220MB for Discord is unreasonable in any way, when Firefox with 8 tabs takes 1.2GB. Telegram written in Qt meanwhile takes 200MB, literally no difference to Discord, an electron app.
Even something completely simple such as snip a portion of your screen and paste it in the chatbox so others can see it immediately, without having to mess around with dodgy image upload sites. This is basic functionality for 2022.
It's like comparing notepad.exe to Microsoft Word
The point is most of what Discord provides is low value for the resources it demands.
> rich embedded media like images and videos
Yes
> live stream games to your friends on it
no (there's WeChat livestream (idk what it's called in English), but it's not discord style stream-your-desktop)
> talk with people
yes
> have profile avatars
yes
> use emotes
yes
> build bots that stream music to you
yes
> Even something completely simple such as snip a portion of your screen and paste it in the chatbox so others can see it immediately, without having to mess around with dodgy image upload sites
yes? you can paste stuff into wechat just fine. Think WhatsApp, not IRC
Idk where GP came up with 18MB tho, it's eating up 100 on my laptop right now.
Higher screen resolution uses more memory too.
I'm sure dependencies / libraries have grown in size too, and yeah, using web for UI takes memory.
Slack was using 1.2 GB. It is in a workspaces but that seems a lot for an app that does nothing.
Postman I think is also Electron often uses 1-2GB for sending API requests.
Atom though was only using 200MB which is fair.
I think it's a bit weird to compare a chat app with a web browser, though, when it comes to memory usage. Maybe a better example: hexchat, a native GTK IRC client, is currently using 60MB of RAM. Telegram's native app using over 200MB is also ridiculous.
Not to say that it should not have more, far from it. But the Electron framework is so wasteful, compared with basically all the alternatives.
I wish the framework developed for Sublime Text were not secret.
Que pedo, wey.
As long as you didn't get one of the single-channel SSD models, it would make plenty of sense to give yourself a 16 gig swapfile (or something of the sort).
It's actually a problem, if you're low on SSD space the filesystem can fill up with swapfiles while the system is still reasonably functional because the SSDs are fast enough. Then because of an APFS design fault, sometimes it isn't possible to delete any files to free up space. It says "out of disk space" when you try to delete a file.
Currently sitting at 29GB (on M1 Pro), just for regular web dev environment on MacOS.
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.
Does that include file system cache?
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.
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.
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.
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
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.
There are no dependencies.