4 ms·

Here's what's been bugging me lately about electron apps. They often take disproportional amounts of ram compared to what they do/have to offer. Common response

by dkns 9y ago

Here's what's been bugging me lately about electron apps. They often take disproportional amounts of ram compared to what they do/have to offer. Common response is that it's not an issue because ram is plentiful and even if my terminal takes 500 mb of ram that's not an issue because I have 8 gb or 16 or whatever. Yes, but if this trend continues soon we'll end up with electron based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc. etc. That starts to quickly add up and I don't feel like buying more ram just because it's cheap. RAM is cheap but so is a trip to the zoo and given the choice I'd rather go to zoo than buy more ram.

BugsJustFindMe 9y ago
I'm 100% with you on this, but the real problem is that, while maybe RAM is relatively cheap, the most common computers today, laptops, cannot be arbitrarily upgraded!, and any developer who ignores that is just not doing you a favor.
- golergka 9y ago
  They cannot be upgraded because ordinary users didn't actually ever upgrade them when it was even possible.
  - BugsJustFindMe 9y ago
    Why do you think the reason matters? It doesn't change anything.
egeozcan 9y ago
> if this trend continues soon we'll end up with electron based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc. etc. I can imagine at some point the runtime, being so popular, getting heavily optimized by some stakeholder. I already heard that there are some significant contributions from Microsoft. They had also did the same for node.js. > and given the choice I'd rather go to zoo than buy more ram While I generally agree with your comment, I personally like shopping for hardware much more than pitying caged animals.
- geodel 9y ago
  That 500-700MB for an ordinary single application is already using heavily optimized electron. I do not think electron is some sloppily written piece of software. That monstrous ram consumption is just the effect of using browser framework for non-browser application. Nothing will change until people simply stop using electron.
  - egeozcan 9y ago
    You may be right, I don't know the internals of the Webkit. Then I suppose an alternative with an easy migration path would pop-up... or the supply of developers with good native experience would need to magically increase, which is very less likely to happen.
    - geodel 9y ago
      > or the supply of developers with good native experience would need to magically increase Well one of the thing I notice despite all the new apps made with electron, none of them opened a category of new type of software which wasn't there before. It is just quickly made chat app, notes app, text editor and so on. So it is not that we need dramatically more native developers but to ask do we need 100 more apps of same type.
      - eridius 9y ago
        The only real benefit I see to Electron is it's finally delivering what Java promised, which is apps that run on all platforms from a single code base. Although, just like Java, they end up having non-platform-native UIs, and I imagine there's still some amount of platform-specific work you need to do (e.g. providing appropriate keyboard shortcuts on each platform).
        umanwizard 9y ago
        > finally delivering what Java promised Isn't this mostly true for Java already? I certainly recall downloading various applications bundled in .jar's and having them work fine on whatever platform I happened to be using. I think people moved away from writing end-user apps in Java because they were bloated and slow and had ugly UIs, not because cross-platform development was super hard.
vetrom 9y ago
It's definitely a band-aid, but has anyone tried ksm on linux with a web/electron-heavy desktop to see how much ram is duplicated across multiple instances?
golergka 9y ago
As far as I understand, there's nothing impossible in optimizing the internals of Electron while keeping more or less the same application-facing API. And if it's possible, it will get done, sooner or later - after all, Java had a reputation for being slow too.
realharo 9y ago
Eventually we may end up with shared system-wide electron instances, that are shared between all applications that claim they're compatible with said version. Kind of like Chrome tabs all share the same Chrome browser. Then someone will come up with ElectronOS.
- Grangar 9y ago
  And then someone will write a web browser for Electron, and then someone will make that browser headless. Electrons all the way down!
  - cdevs 9y ago
    It's going to start with a browser based desktop ('not OS') and trickle down from there inception style. That way when we build a mirror out of raspberry pi we can CSS/js the calendar into the desktop background.
- pdkl95 9y ago
  https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Unfortunately some people seem to have missed that this talk was labeled "comedy" and "absurdist", are actually trying to implement a JavaScript kernel. The talk just got the name wrong - it was "Electron", not "Metal". I know it's an experimental project, but that's exactly the time to learn Ruby+Tk, or {anything}+Qt, or any of the other cross-platform toolkits. If you have to bundle an entire GUI server ("the browser") with your app to shoehorn HTML into use cases it wasn't designed for, you're doing it wrong.
  - roryisok 9y ago
    > you're doing it wrong "wrong" is subjective here. You could also argue that Ruby+Tk is "wrong" because Ruby is not as efficient as coding in C++, or C, or Assembly. What we're talking about here, (and every time this comes up, again, and again, and again, over and over) is what shortcuts you're willing to take to get to MVP. There are a lot of Electron success stories out there, and when you're a solo dev starting out, and want to make a cross platform app, Electron is approachable and proven.
HighlandSpring 9y ago
Can anyone comment on the relationship between memory usage and the number of windowed instances of Black Screen? Right now I have 8 terminals open, some tabbed, some not, Sometimes I can have over twice as many. Many of them sit untouched on an Awesome workspace for days ready for me to come back to whenever I need them. This isn't a issue since their memory footprint is almost non-existent on pretty much any machine. Could I get away with this if I had to run an instance of Node + Chromium per terminal window? Is Black Screen one step ahead of me and it'll reuse an already running instance and open up another window? Do I want all my terminal instances to be managed by a single node process? Despite my reservations, still going to give this a go. On a side note, anyone looking for a slightly more useful shell that is still very lightweight: check out fish: https://github.com/fish-shell/fish-shell https://github.com/fish-shell/fish-shell
Nyubis 9y ago
>electron based text editor, music player, terminal, 2 - 3 chat apps, git browser So... Atom, Spotify, Black Screen, Slack & Discord, GitKraken. "Soon" is now.
- kevlar1818 9y ago
  +1 You beat me to it.
- 0x6c6f6c 9y ago
  Spotify is close but not actually an Electron app, although it does use the Chromium Embedded Framework on-top of a C++ core and modules. Basically, only the view is web-based.
  - tjoff 9y ago
    Well, a chain is only as strong as its weakest link. And Spotify is a bloated monster and a disgrace just because of "only the view".
nmca 9y ago
I also like the zoo.
tjoff 9y ago
You can't buy more RAM in most small laptops anyway, and even big ones have limits.

by dkns 9y ago

BugsJustFindMe 9y ago

I'm 100% with you on this, but the real problem is that, while maybe RAM is relatively cheap, the most common computers today, laptops, cannot be arbitrarily upgraded!, and any developer who ignores that is just not doing you a favor.

golergka 9y ago
They cannot be upgraded because ordinary users didn't actually ever upgrade them when it was even possible.
- BugsJustFindMe 9y ago
  Why do you think the reason matters? It doesn't change anything.

egeozcan 9y ago

> if this trend continues soon we'll end up with electron based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc. etc. I can imagine at some point the runtime, being so popular, getting heavily optimized by some stakeholder. I already heard that there are some significant contributions from Microsoft. They had also did the same for node.js. > and given the choice I'd rather go to zoo than buy more ram While I generally agree with your comment, I personally like shopping for hardware much more than pitying caged animals.

geodel 9y ago
That 500-700MB for an ordinary single application is already using heavily optimized electron. I do not think electron is some sloppily written piece of software. That monstrous ram consumption is just the effect of using browser framework for non-browser application. Nothing will change until people simply stop using electron.
- egeozcan 9y ago
  You may be right, I don't know the internals of the Webkit. Then I suppose an alternative with an easy migration path would pop-up... or the supply of developers with good native experience would need to magically increase, which is very less likely to happen.
  - geodel 9y ago
    > or the supply of developers with good native experience would need to magically increase Well one of the thing I notice despite all the new apps made with electron, none of them opened a category of new type of software which wasn't there before. It is just quickly made chat app, notes app, text editor and so on. So it is not that we need dramatically more native developers but to ask do we need 100 more apps of same type.
    - eridius 9y ago
      The only real benefit I see to Electron is it's finally delivering what Java promised, which is apps that run on all platforms from a single code base. Although, just like Java, they end up having non-platform-native UIs, and I imagine there's still some amount of platform-specific work you need to do (e.g. providing appropriate keyboard shortcuts on each platform).
      - umanwizard 9y ago
        > finally delivering what Java promised Isn't this mostly true for Java already? I certainly recall downloading various applications bundled in .jar's and having them work fine on whatever platform I happened to be using. I think people moved away from writing end-user apps in Java because they were bloated and slow and had ugly UIs, not because cross-platform development was super hard.

vetrom 9y ago

It's definitely a band-aid, but has anyone tried ksm on linux with a web/electron-heavy desktop to see how much ram is duplicated across multiple instances?

golergka 9y ago

As far as I understand, there's nothing impossible in optimizing the internals of Electron while keeping more or less the same application-facing API. And if it's possible, it will get done, sooner or later - after all, Java had a reputation for being slow too.

realharo 9y ago

Eventually we may end up with shared system-wide electron instances, that are shared between all applications that claim they're compatible with said version. Kind of like Chrome tabs all share the same Chrome browser. Then someone will come up with ElectronOS.

Grangar 9y ago
And then someone will write a web browser for Electron, and then someone will make that browser headless. Electrons all the way down!
- cdevs 9y ago
  It's going to start with a browser based desktop ('not OS') and trickle down from there inception style. That way when we build a mirror out of raspberry pi we can CSS/js the calendar into the desktop background.
pdkl95 9y ago
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Unfortunately some people seem to have missed that this talk was labeled "comedy" and "absurdist", are actually trying to implement a JavaScript kernel. The talk just got the name wrong - it was "Electron", not "Metal". I know it's an experimental project, but that's exactly the time to learn Ruby+Tk, or {anything}+Qt, or any of the other cross-platform toolkits. If you have to bundle an entire GUI server ("the browser") with your app to shoehorn HTML into use cases it wasn't designed for, you're doing it wrong.
- roryisok 9y ago
  > you're doing it wrong "wrong" is subjective here. You could also argue that Ruby+Tk is "wrong" because Ruby is not as efficient as coding in C++, or C, or Assembly. What we're talking about here, (and every time this comes up, again, and again, and again, over and over) is what shortcuts you're willing to take to get to MVP. There are a lot of Electron success stories out there, and when you're a solo dev starting out, and want to make a cross platform app, Electron is approachable and proven.

HighlandSpring 9y ago

Can anyone comment on the relationship between memory usage and the number of windowed instances of Black Screen? Right now I have 8 terminals open, some tabbed, some not, Sometimes I can have over twice as many. Many of them sit untouched on an Awesome workspace for days ready for me to come back to whenever I need them. This isn't a issue since their memory footprint is almost non-existent on pretty much any machine. Could I get away with this if I had to run an instance of Node + Chromium per terminal window? Is Black Screen one step ahead of me and it'll reuse an already running instance and open up another window? Do I want all my terminal instances to be managed by a single node process? Despite my reservations, still going to give this a go. On a side note, anyone looking for a slightly more useful shell that is still very lightweight: check out fish: https://github.com/fish-shell/fish-shell https://github.com/fish-shell/fish-shell

Nyubis 9y ago

>electron based text editor, music player, terminal, 2 - 3 chat apps, git browser So... Atom, Spotify, Black Screen, Slack & Discord, GitKraken. "Soon" is now.

kevlar1818 9y ago
+1 You beat me to it.
0x6c6f6c 9y ago
Spotify is close but not actually an Electron app, although it does use the Chromium Embedded Framework on-top of a C++ core and modules. Basically, only the view is web-based.
- tjoff 9y ago
  Well, a chain is only as strong as its weakest link. And Spotify is a bloated monster and a disgrace just because of "only the view".

nmca 9y ago

I also like the zoo.

tjoff 9y ago

You can't buy more RAM in most small laptops anyway, and even big ones have limits.