Did you read the article? It says 230MB for starters, you're clearly trying to paint it negatively. And the first thing it says after that is "still not ideal". Looking around at other native apps and at rest they are consuming between 150-200MB.
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.
"Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.""
>Did you read the article? It says 230MB for starters, you're clearly trying to paint it negatively. And the first thing it says after that is "still not ideal". Looking around at other native apps and at rest they are consuming between 150-200MB.
Making electron, the entire point of which was to lower the barrier to entry to app development, even vaguely reasonable in terms of memory use by having to code in Rust which is very much not low barrier to entry is an irony that strikes exactly to the heart of the point the person was making.
I don't get what you are saying. Using 230MB of memory for a very data-heavy app is already somewhat reasonable, and more advanced optimizations are going to require more advanced engineering.
It's the same thing with any app, as you go further along development you will want to optimize in more advanced ways.
Every single transaction on every account they have for starters, plus a data point for the total in the account at the end of each day I would imagine, plus all metadata you could ever want to associated with a transaction
Electron lowers the barrier-to-entry for frontend app development. Or, more cynically: Electron allows you to hire cheaper, less-experienced frontend engineers.
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.
> Electron allows you to hire cheaper, less-experienced frontend engineers.
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.
I mean that you can hire developers who, due to their inexperience, know just enough to make one very specific kind of thing, and that thing is a certain type of SPA frontend (e.g. "React developers", sort of like "Java developers"). Because they only have this one skill, and because "web SPA frontend developer" is in-demand enough for a decent supply pipeline of them to have formed (of "code bootcamps" et al), the junior ones are relatively cheap to hire.
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.
Aha, sorry I have totally misinterpreted that then, here's an up-vote :) I sort of got super sensitive when it comes to people underrating the huge amount of skills that are required to be a front-end developer.
Its interesting that slack takes 1gb+ memory. Slack still uses the OS provided webview, right? That seems like the right way to do it (last time I used Slack, it was a 3mb download - glorious), but how is it using so much RAM? maybe its leaky?
As someone who uses Slack only in the browser and not as a native app, Electron is not the reason Slack is slow.
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.
Electron ships its own Chromium-based browser view. Using the OS provided one does sound like an efficient option, but then you have to deal with all the same compatibility testing (different browsers, different releases, running under different OSes and OS releases) that makes web development suck. It's trying to provide a web-based stack while abstracting away most of those headaches.
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.
> but then you have to deal with all the same compatibility testing
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.
My guess is Slack likes to keep pages around, and each workspace is a separate page that are individually pretty heavy. So if I'm logged into 4-5 workspaces that adds up quick.
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.
It has been years so youre probably right. Bummer. That explains the ram usage.
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 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.