The November 2020 M1 machines are nearly getting to daily usability in Linux. Support for screen brightness adjustment, the webcam, speakers and mic are the remaining things for day to day use for me. All look like they should be working in 6 months-1 year.
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.
Are you all using some rare electron apps that are unknown to me because I keep hearing this meme repeated but when I look at my RAM usage[0], it never corroborates this.
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.
Signal is using 335MB for me right now, which feels ridiculous for a messaging app. I have Firefox running with over a thousand tabs (hard to tell how much RAM it's using with all the processes, many of which share memory, but my total system usage is around 8GB right now, so it's at least less than that), so I guess it's not scaling linearly from 8 tabs = 1.2GB. At any rate, Firefox does at least a couple orders of magnitude more things than Signal does; I think it's reasonable for it to use more RAM.
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.
Does weechat support rich embedded media like images and videos, can you live stream games to your friends on it, talk with people, have profile avatars, use emotes, build bots that stream music to you?
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.
How much of that needs to relate to the memory usage though? Embedded media doesn't need to be loaded besides what's visible in the current channel and perhaps a bit of scrollback, perhaps some text and scrollback for other frequently viewed channels. Livestreams also shouldn't be taking memory unless you're watching, same with voice. Avatars and emotes would certainly take memory, but certainly not hundreds of megabytes of it.
EDIT: ignore me, I thought this was about WeChat, the Chinese messaging app, not weechat, the IRC client :(
> 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.
Part of the issue is that 64-bit programs end up taking close to twice as much memory, because pointers are twice as big, instructions are longer, etc.
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.
I don't want to run a web browser to run a desktop app. I don't care how useful it is to run JS and HTML from a dev standpoint it's an absolutely absurdity that my desktop app has a CORS vulnerability.
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.
Honestly, if the other OSes had decent native apps for some of these things I would probably switch. There is just something wrong with Spotify using 1gb when it was just opened and never used.
Somehow a security feature in browsers called CORS, that isn't present at all in native apps, is both a vulnerability and a downside? I don't understand this line of thinking.
I could be wrong but I feel like literally running some kind of little mini virtualized instance and just running a desktop app meant for OSX or Windows could end up being more efficient than running a whole browser.....
Not necessarily. If you're running the browser anyway, and the app is a PWA and can share that same instance. The "browser" overhead is not really there.
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.
> It's a bit of a shame that the RAM is so limited on all those platforms
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).
MacOS creates swapfiles automatically as needed (in /var/vm). It will allocate a lot more space to swap than the size of RAM, if it determines that's useful.
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.
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.
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.