I'm not an electron hater, but when only using 300mb of memory while idle is something to boast about, they may have a point.
Granted, that's reserved memory, but that's the only memory you really need to worry about anyway.
Of course, native doesn't make a program automatically use less RAM. It does start with a lower footprint through, meaning that you can keep an eye on memory usage without relying on ugly hacks in your code.
$ ps -eo rss,cmd |grep claws-mail|grep -v grep
36016 claws-mail
Developers shouldn't be assuming that their users will have machines even close to theirs spec-wise.
Chrome is awful with resource usage to begin with, which is why Electron is, it bundles and runs a headless Chrome for each Electron app.
It goes on to say that there's a memory-intensive piece that I haven't even optimized yet and will rewrite into Rust which should bring the memory down a lot more.
Slack does not use the OS webview, it is Electron. I don't think it's a 3MB download - if it is it must just be an installer that installs the real thing? I haven't looked recently.
I do prefer the webview approach because I don’t need/want my chat app to bundle a browser :-/ Ive been a web and native app dev for a decade and do not agree that developer convenience could ever justify these sorts of choices. My webview backed native apps are all sub 1mb and I have no trouble developing them. I guess I just dont get it.
It also provides some Chrome specific functionality (loading Chrome extensions) that wouldn't work in an engine-agnostic system, though I don't imagine this is a commonly used mechanism. Extensions are more useful for shoving your own functionality into someone else's webpage, if you control the whole codebase surely it's not the best way to do anything.
https://electronjs.org/docs/api/browser-window#browserwindow...
Which means they choose the wrong way to go about creating an app. If you have to bundle a huge secondary app just to run your main application, you've done something wrong.
Electron doesn't help, of course.
But Slack seems to either cache a lot of stuff, or have memory leaks, or something. It's weird, because Slack seems to re-fetch data whenever I switch rooms, so I'm not sure what all that RAM is being used for.
It's the same thing with any app, as you go further along development you will want to optimize in more advanced ways.
I'm not arguing that Electron doesn't have bloat though: https://news.ycombinator.com/item?id=20274725
I mean, how much data can a user for a personal finance app store in a year?
(to be clear I consider this a very generous estimate of how big this could possibly get)
A background worker in an Electron process, however, can be thought of (depending on what it’s used for) as more of a “local ambassador of the server”, and thus isn’t really “frontend” at all. It lands on the client, sure, but it’s no more frontend than the client-side half of the Firebase library is frontend. It’s plumbing, and so it’d be the responsibility of a backend or infrastructure engineer to write and maintain.
If you take this perspective, you still receive the main practical advantage that the system’s product manager was probably seeking by choosing Electron in the first place: the ability to hire inexperienced engineers to do UX tweaks, freeing up the senior engineers’ time to handle the hard stuff.
UX tweaks won’t generally bubble down to the level of needing to modify the background worker (again, depending on how you’ve written the thing), so your [junior] frontend engineers won’t need to touch the background worker, so it can be written in a language more on the “good engineering” side of the spectrum than the “low barrier to entry” side—like Rust—without that causing you any headaches of the “everybody who knows how to fix it is busy” variety.
Do you mean that the front end developers are cheaper or you mean even the less experienced can code in Electron? I have issue with both but I need to understand what you mean first.
You can then have someone with more experience "box up" that web SPA frontend in an Electron wrapper, in a way that will generally last a good while.
(This is, AFAIK, precisely the approach taken by teams like Spotify, where the Electron app has no extra functionality beyond what you'd get from the web app.)
Of course, developers generally age out of only having one skill, so this is sort of the programming equivalent of an "intern job": not something anyone would stay in for more than the length of an internship, and something that you just constantly pump new people through.
You're not making it any better...