6 ms·

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.

jlongster 7y ago
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.
- loljabab 7y ago
  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?
  - jlongster 7y ago
    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.
    - loljabab 7y ago
      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.
  - butteroverflow 7y ago
    Are you sure those 3 MB were not just a web installer?
  - wlesieutre 7y ago
    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. https://electronjs.org/docs/api/browser-window#browserwindowaddextensionpath https://electronjs.org/docs/api/browser-window#browserwindow...
    - monksy 7y ago
      > 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.
      - coldtea 7y ago
        If you have a multi-billion valuation while doing it, and millions of users, you could not care less...
  - danShumway 7y ago
    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.
  - krzyk 7y ago
    Not every OS has a "provided webview", Linux doesn't, not sure if MacOS does.
    - mthoms 7y ago
      MacOS does (WKWebView)
    - yjftsjthsd-h 7y ago
      Doesn't it? I would say that WebKitGTK counts.
      - krzyk 7y ago
        You need to install it first, there are multiple Linux distributions
- weego 7y ago
  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.
  - jlongster 7y ago
    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. I'm not arguing that Electron doesn't have bloat though: https://news.ycombinator.com/item?id=20274725 https://news.ycombinator.com/item?id=20274725
    - Scarbutt 7y ago
      I don't understand how is this a "data-heavy" app? You are implying that most of those 230MB is data? I mean, how much data can a user for a personal finance app store in a year?
      - fjp 7y ago
        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
        _dps 7y ago
        Ballpark: say 16 8-byte fields for each transaction and 128 transactions per day, 30 years of transactions is ~180MB. (to be clear I consider this a very generous estimate of how big this could possibly get)
  - derefr 7y ago
    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.
- coldtea 7y ago
  >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. You're not making it any better...
- dang 7y ago
  "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."" https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
CharlesW 7y ago
It's relative. Outlook is using 2.37 GB of RAM as I type this.
- Sahhaese 7y ago
  That's odd, OUTLOOK.EXE is using 44MB of ram as I type this and has been open for 7 hours.
  - LandR 7y ago
    Same here, Outlook has been open from 9am > 4pm and it's using 64MB.
  - toyg 7y ago
    Maybe a Mac. My Outlook on mac is idling at 150MB.
    - CharlesW 7y ago
      Yes, this is Office 365 on macOS. Neither the computer nor Outlook have been restarted in weeks, which is surely contributing to its current RAM footprint.
  - GrinningFool 7y ago
    Is it minimized? IIRC on Windows, when an application is minimized the working set is trimmed which can result in a significant reduction - but it jumps back up when you start using the application again.
- jeroenhd 7y ago
  That too is relative. My copy of Thunderbird with 6 open emails from six open mailboxes is consuming about 170MB of memory right now, and that's hosting a fully-featured browser to view emails. 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.

jlongster 7y ago

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.

loljabab 7y ago
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?
- jlongster 7y ago
  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.
  - loljabab 7y ago
    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.
- butteroverflow 7y ago
  Are you sure those 3 MB were not just a web installer?
- wlesieutre 7y ago
  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. https://electronjs.org/docs/api/browser-window#browserwindowaddextensionpath https://electronjs.org/docs/api/browser-window#browserwindow...
  - monksy 7y ago
    > 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.
    - coldtea 7y ago
      If you have a multi-billion valuation while doing it, and millions of users, you could not care less...
- danShumway 7y ago
  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.
- krzyk 7y ago
  Not every OS has a "provided webview", Linux doesn't, not sure if MacOS does.
  - mthoms 7y ago
    MacOS does (WKWebView)
  - yjftsjthsd-h 7y ago
    Doesn't it? I would say that WebKitGTK counts.
    - krzyk 7y ago
      You need to install it first, there are multiple Linux distributions
weego 7y ago
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.
- jlongster 7y ago
  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. I'm not arguing that Electron doesn't have bloat though: https://news.ycombinator.com/item?id=20274725 https://news.ycombinator.com/item?id=20274725
  - Scarbutt 7y ago
    I don't understand how is this a "data-heavy" app? You are implying that most of those 230MB is data? I mean, how much data can a user for a personal finance app store in a year?
    - fjp 7y ago
      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
      - _dps 7y ago
        Ballpark: say 16 8-byte fields for each transaction and 128 transactions per day, 30 years of transactions is ~180MB. (to be clear I consider this a very generous estimate of how big this could possibly get)
- derefr 7y ago
  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.
coldtea 7y ago
>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. You're not making it any better...
dang 7y ago
"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."" https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

CharlesW 7y ago

It's relative. Outlook is using 2.37 GB of RAM as I type this.

Sahhaese 7y ago
That's odd, OUTLOOK.EXE is using 44MB of ram as I type this and has been open for 7 hours.
- LandR 7y ago
  Same here, Outlook has been open from 9am > 4pm and it's using 64MB.
- toyg 7y ago
  Maybe a Mac. My Outlook on mac is idling at 150MB.
  - CharlesW 7y ago
    Yes, this is Office 365 on macOS. Neither the computer nor Outlook have been restarted in weeks, which is surely contributing to its current RAM footprint.
- GrinningFool 7y ago
  Is it minimized? IIRC on Windows, when an application is minimized the working set is trimmed which can result in a significant reduction - but it jumps back up when you start using the application again.
jeroenhd 7y ago
That too is relative. My copy of Thunderbird with 6 open emails from six open mailboxes is consuming about 170MB of memory right now, and that's hosting a fully-featured browser to view emails. 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.