Even if memory usage is the same, there's a world of a difference when it comes to executable size, and for most Electron apps, I doubt the content will outweigh the runtime.
Ridiculous. I have a 256 GB hard drive, which is pretty common even on new machines. I’m constantly having to delete stuff to make sure I don’t run out of room. It’s absolutely an issue.
Meh, I have an SSD of similar space, and the only stuff I ever have to delete is old Xcode-related data that refuses to go away. Periodically, some Rust build-related stuff I guess.
The litany of Electron apps don't even come close to being an issue (I arguably have more than the average person, too, thanks to every stupid crypto wallet from the past few years).
I'm hoping you have a 256 GB ssd. In any case lots of bad stuff is common and hoping the universe changes seems like a bad strategy seeing as a 500GB ssd is about $85 and a 500GB hd is like $30.
If you want more future proof a 1TB ssd can be found for around $150.
Unless you're on an Apple laptop. There's no upgrading of the components. And before the "you made the choice" guys start chiming in, some people didn't make that choice. If IT says "Dude, you're getting an Apple", then it is what it is. Just because "hard drives are cheap" is not an excuse to ship bloated software. At some point, the app has the features it is meant to have. At that point, it is a good time to refactor bloated code before proceeding to new features. The bloat will just continue, and eventually cause issues that come to a head.
It's opinions like this that cause first day downloads for new games like Red Dead Redemption 2 to be 55GBs.
In the case of an Electron app disk space might not matter as much, but it's absolutely worth optimizing in 2018, at least because not everyone has high speed connections (e.g. in Germany, a lot of infrastructure is built around DSL, which obviously doesn't get great speeds).
You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB. Overall in 2018 that is not a big concern.
In gaming, high definition graphics are going to result in massively larger files. That’s not going to change anytime soon and no gaming company will prioritize a small download over better graphics.
Yes I know, and the size of an Electron app versus a AAA game is sometimes 3 orders of magnitude in difference, which is why I pointed out that even a "small" app that's 100MB is still a lot to download on a limited speed connection.
> Pray-tell, what magic compression technique would you use to do better AND still support 4K textures?
How about downloading textures and movies on demand in the background when you enter new areas? It's not like all that stuff is required for the game to start.
tbh I'd use configurable installer: download only these assets you'll be using
at worst case allow us to set up everything with full version installed and then cleanup
Hey, that's not fair to RDR2! I actually bought it the day it came out because it _didn't_ have a huge day one patch. I think it was only about 4 GB, which is barely a blip on my ISP's arbitrary data cap. Fallout 76, however, had a patch that was larger than the disc itself, so that was an easy "pass" for me.
Edit: I just checked, and even now that they've added multiplayer to the game (which didn't come on the physical disk), the patch for a new installation of RDR2 is 8 GB. Meanwhile, Fallout 76 is 50 GB and COD:BO4 is 65 GB.
Messages uses webviews and manages to do much of what Slack does with a tenth of the memory footprint. I still have not found any evidence for your claim that Electron and WKWebView use the same amount of memory.
You're literally comparing two completely different apps. If you want to compare Apples to Apples, host 5 teams in Slack, in both Chromium and WKWebView
Unfortunately, I’m in a place where I can test your argument, so the best evidence I can give you is the personal anecdote that I run Slack in Safari rather than using the Electron app for performance reasons. It’s not quite WKWebView, but I think it’s a relatively decent approximation. With that said, I still think you’re missing the point: it’s completely possible to make a messaging app that uses significantly less memory than Slack does and does basically the same things, even if you ditch native controls (which is not something I prefer people do, for reasons other than performance, but it’s something I am willing to tolerate). Loading an entire browser with its associated baggage rather than using the platform’s native web view will almost always use more resources, because you will have bloat that is not necessary for what you are doing and some features will end up being reimplemented in Electron. Just because Slack might perform poorly in both a web view and Electron (which I still believe is not equally poorly), does not mean that it could not perform well at all. There are multiple issues here.
There is of course value in comparing Messages-the-HTML-app to Slack-the-HTML-app. If they can do it in a fraction of the memory with comparable functionality, I wonder why Slack can't
For any sites I could think of, the memory usage, thread count, CPU time, and idle wake ups were considerably smaller using WKWebView.
The disk usage was also crazy smaller, as is expected. ~122MB for nativefier vs ~14MB for WKWebView (and a lot of that is due to being written in Swift).