7 ms·

The tweet mentioned in the article, saying: Electron app memory usage: 150MB Native app memory usage: 0 MB (because you never ship it) really hit home for me

The tweet mentioned in the article, saying: Electron app memory usage: 150MB Native app memory usage: 0 MB (because you never ship it) really hit home for me.

sdwolfz 6y ago
I used to disagree with this view, since I was "raised" in school to think that raw performance is the only worthy attribute of a computer program, regardless of purpose. Then, when I started working on real products instead of homework I learned how wrong that way of thinking was. Of course it does not apply to everything, some apps do need every last clock cycle of speed, but so far none of mine had.
- MaxBarraclough 6y ago
  How about Electron-based chat apps like Slack and Teams? We know it's possible to implement this kind of functionality in <40MB of RAM, rather than the 300MB used by Slack and Teams. [0] If these apps are going to be running constantly, it essentially means you've paid for 260MB of RAM more than you're able to use, on account of Slack putting their developer convenience before your computational resources. This seems especially silly to me as many companies pay good money for the privilege. For comparison, the Playstation 3 has 256MB of system RAM, and manages to run GTA V. [0] See the Ripcord application, discussed https://news.ycombinator.com/item?id=23163960 https://news.ycombinator.com/item?id=23163960
  - jakelazaroff 6y ago
    I think we can hold multi-billion dollar venture-backed companies to a different standard than we do indie developers working on side projects.
    - MaxBarraclough 6y ago
      Not sure if you meant that as a nod to Ripcord. Slack has, to put it mildly, plenty of money, and gave us a 300MB bloated client. Ripcord is a payware alternative client made by a single developer. Things seem to be precisely backward.
      - jakelazaroff 6y ago
        I meant that as a nod to the person to whom you're replying, as well as the author of the article. Of course it's possible for indie developers to build native apps — but I don't begrudge them for avoiding that route, especially if their day job doesn't involve it. I am perfectly fine with criticizing giant companies for building chat apps atop Electron.
  - coding123 6y ago
    The PS5 has 16GB of RAM. So does the Mac I'm using. Slack is taking less than 1% of my Ram. PS3 was released 13 YEARS ago. At the time AIM was the dominant chat client, and it probably took more like 5% of RAM available.
    - MaxBarraclough 6y ago
      > PS3 was released 13 YEARS ago. That's why I used it for my example. Past systems are a useful benchmark for what it's practical to do with a certain level of computational horsepower. > Slack is taking less than 1% of my Ram. My system has 8GB, so 3.7%. I'd rather have 3.4% of my memory back. More broadly, we should consider that we may run many bloated apps. Even if Slack doesn't do too much harm on its own, if all your desktop apps are using 10x the resources they could be using, it adds up to you spending more on hardware than you should have to. You paid for that 16GB of RAM. That should let you do a lot more than old computers can, rather than doing the same things we did 15 years ago with bloated software. > At the time AIM was the dominant chat client, and it probably took more like 5% of RAM available. Right, like Ripcord, it did roughly the same thing Slack/Teams do, using far fewer resources.
      - horsawlarway 6y ago
        Honestly though, why would you rather have that 3.4% of ram back? Is the bottleneck in your system actually ram usage? Because I think implicit in your view is that you have a better usage for that ram. If so, what? Because I really struggle coming up with more than about 5 electron apps I might ever run at any given time (Slack, VSCode, Discord, maaaybe Etcher..., and I'm basically out of ideas). Even then, two of those apps are both chat apps and I probably shouldn't have Discord open for work, and I don't use slack for any personal reason. Basically - Electron apps are all applications that are UI heavy. I don't have the mental power to manage more than about 5 open and active UI apps before I'm the bottleneck, not the computer. So at 5, you're spending 15-18% of your RAM on 5, 5! apps that you want to be interacting with rich GUIs at any given time. I just don't see it. At least for my use cases, electron apps almost always make up a trivial amount of my total ram usage. Docker/Development Env/Vms DOMINATE in comparison. So while I get that it could be faster, the reality of the situation is that without electron, none of the apps I listed would work on Linux at all. Instead they all do by default. So right now on amazon, 16gb of ram is 53 bucks for a decent module. 150/16000 = .009. So basically - I paid 49 cents, and got apps that work by default on my platform of choice. That's pretty fucking amazing compared to old platform specific apps.
  - Falling3 6y ago
    Yea, completely agree. I think context is very important here. We should not be making the same arguments for a one-person side business and a company with 400MM in revenue. Slack really can't stand on the arguments presented in the article.
    - dangus 6y ago
      Slack didn't exactly start with 400MM of revenue.
      - Falling3 6y ago
        Of course not. But do we expect companies to stick to the decisions they made as startups forever?
        deleted 6y ago
        [deleted]
  - sdwolfz 6y ago
    I don't use the Slack app, there is no need to do that when I can have it running in a browser tab instead. Not sure what Teams is either...
    - MaxBarraclough 6y ago
      The Slack app is essentially a Chromium browser running the usual web-based Slack. It uses the same amount of resources running in a tab in your browser. I think there are some UI niceties to the 'app' version but it's essentially the same. Teams refers to Microsoft's competing product. Like Slack, its desktop app is really just the web version.
      - piaste 6y ago
        > The Slack app is essentially a Chromium browser running the usual web-based Slack. It uses the same amount of resources running in a tab in your browser. I would expect that a pinned Slack tab in Chrome/Edge would be able to share some resources with the browser that a separate Slack app can't. Has anybody tested the performance difference between running 100 browser tabs vs. running the same webapps as 100 electron processes?
  - dangus 6y ago
    Ripcord itself demonstrates why Slack is written in Electron. Is there a mobile app? Nope! Dead on arrival. In 2020, Slack or Teams or anything similar is literally useless without a mobile app. Feature matrix says animated emojis will arrive "never." lol! I remember the days of native chat clients like Skype and AIM. I remember how Linux and Mac platforms were basically half-clients compared to Windows. It sucked. Electron applications like Slack and Spotify work everywhere, exactly the same. And if you think about it, that's why something like chat and music apps would prioritize ease of cross-platform deployment over perfect efficiency. They're not particularly demanding, and they are most valuable to people when they're ubiquitous. If Spotify isn't in every device I own it loses a great amount of value. Nobody's sitting at their Activity Monitor staring at the RAM usage of Slack or Teams. In reality, performance is fine. It's just chat. (Interestingly enough, I've never found a music application that skips tracks more quickly than Spotify, even for locally-stored music. It's just instant with no gaps.)
    - xg15 6y ago
      > Electron applications like Slack and Spotify work everywhere, exactly the same. Yes, because they're just web pages. Then why not just use the browser to display them?
      - dangus 6y ago
        Nobody’s stopping you from using the web version of Slack or Spotify. That said I can think of some pretty good reasons. - Users don’t understand it as well or are less comfortable with it. - Users’ general preference for logical separation - Mobile safari doesn’t support browser notifications. - You won’t get browser notifications if you close the tab by accident - You lose OS integration, like replying via OS notifications in Slack or using OS Music controls with Spotify On top of all that a browser tab uses plenty of RAM as well so I don’t really see the upside of using the browser for these apps, either.
  - kyriakos 6y ago
    You'll be lucky if you get Teams to work in a 300mb. I regularly see it hitting 1GB. The fact is though that even if it was implemented as a native up it relies so much on web views for its addons which would probably not give much benefit cause it would need to run tens of webviews as a native up to have the same functionality.
- xg15 6y ago
  In general, I think you're right - but that mindset can quickly become one of shifting costs to others: E.g., $framework-of-your-choice may increase your velocity and allow you to ship faster. However, it might also make it harder to find bugs and it will produce bloat with real, noticeable consequences - e.g. increased RAM, CPU and disk usage, more sluggish UI behavior, etc - except, those effects will happen on the user's machine, not the developer's, so a developer might be tempted to ignore them.
GirkovArpa 6y ago
Sciter.JS is going to change that: https://github.com/c-smile/sciter-js-sdk https://github.com/c-smile/sciter-js-sdk I cloned a 165mb Electron app in Sciter, and it was only 6mb: https://github.com/GirkovArpa/clipper-sciter https://github.com/GirkovArpa/clipper-sciter

The tweet mentioned in the article, saying: Electron app memory usage: 150MB Native app memory usage: 0 MB (because you never ship it) really hit home for me.

sdwolfz 6y ago

I used to disagree with this view, since I was "raised" in school to think that raw performance is the only worthy attribute of a computer program, regardless of purpose. Then, when I started working on real products instead of homework I learned how wrong that way of thinking was. Of course it does not apply to everything, some apps do need every last clock cycle of speed, but so far none of mine had.

MaxBarraclough 6y ago
How about Electron-based chat apps like Slack and Teams? We know it's possible to implement this kind of functionality in <40MB of RAM, rather than the 300MB used by Slack and Teams. [0] If these apps are going to be running constantly, it essentially means you've paid for 260MB of RAM more than you're able to use, on account of Slack putting their developer convenience before your computational resources. This seems especially silly to me as many companies pay good money for the privilege. For comparison, the Playstation 3 has 256MB of system RAM, and manages to run GTA V. [0] See the Ripcord application, discussed https://news.ycombinator.com/item?id=23163960 https://news.ycombinator.com/item?id=23163960
- jakelazaroff 6y ago
  I think we can hold multi-billion dollar venture-backed companies to a different standard than we do indie developers working on side projects.
  - MaxBarraclough 6y ago
    Not sure if you meant that as a nod to Ripcord. Slack has, to put it mildly, plenty of money, and gave us a 300MB bloated client. Ripcord is a payware alternative client made by a single developer. Things seem to be precisely backward.
    - jakelazaroff 6y ago
      I meant that as a nod to the person to whom you're replying, as well as the author of the article. Of course it's possible for indie developers to build native apps — but I don't begrudge them for avoiding that route, especially if their day job doesn't involve it. I am perfectly fine with criticizing giant companies for building chat apps atop Electron.
- coding123 6y ago
  The PS5 has 16GB of RAM. So does the Mac I'm using. Slack is taking less than 1% of my Ram. PS3 was released 13 YEARS ago. At the time AIM was the dominant chat client, and it probably took more like 5% of RAM available.
  - MaxBarraclough 6y ago
    > PS3 was released 13 YEARS ago. That's why I used it for my example. Past systems are a useful benchmark for what it's practical to do with a certain level of computational horsepower. > Slack is taking less than 1% of my Ram. My system has 8GB, so 3.7%. I'd rather have 3.4% of my memory back. More broadly, we should consider that we may run many bloated apps. Even if Slack doesn't do too much harm on its own, if all your desktop apps are using 10x the resources they could be using, it adds up to you spending more on hardware than you should have to. You paid for that 16GB of RAM. That should let you do a lot more than old computers can, rather than doing the same things we did 15 years ago with bloated software. > At the time AIM was the dominant chat client, and it probably took more like 5% of RAM available. Right, like Ripcord, it did roughly the same thing Slack/Teams do, using far fewer resources.
    - horsawlarway 6y ago
      Honestly though, why would you rather have that 3.4% of ram back? Is the bottleneck in your system actually ram usage? Because I think implicit in your view is that you have a better usage for that ram. If so, what? Because I really struggle coming up with more than about 5 electron apps I might ever run at any given time (Slack, VSCode, Discord, maaaybe Etcher..., and I'm basically out of ideas). Even then, two of those apps are both chat apps and I probably shouldn't have Discord open for work, and I don't use slack for any personal reason. Basically - Electron apps are all applications that are UI heavy. I don't have the mental power to manage more than about 5 open and active UI apps before I'm the bottleneck, not the computer. So at 5, you're spending 15-18% of your RAM on 5, 5! apps that you want to be interacting with rich GUIs at any given time. I just don't see it. At least for my use cases, electron apps almost always make up a trivial amount of my total ram usage. Docker/Development Env/Vms DOMINATE in comparison. So while I get that it could be faster, the reality of the situation is that without electron, none of the apps I listed would work on Linux at all. Instead they all do by default. So right now on amazon, 16gb of ram is 53 bucks for a decent module. 150/16000 = .009. So basically - I paid 49 cents, and got apps that work by default on my platform of choice. That's pretty fucking amazing compared to old platform specific apps.
- Falling3 6y ago
  Yea, completely agree. I think context is very important here. We should not be making the same arguments for a one-person side business and a company with 400MM in revenue. Slack really can't stand on the arguments presented in the article.
  - dangus 6y ago
    Slack didn't exactly start with 400MM of revenue.
    - Falling3 6y ago
      Of course not. But do we expect companies to stick to the decisions they made as startups forever?
      - deleted 6y ago
        [deleted]
- sdwolfz 6y ago
  I don't use the Slack app, there is no need to do that when I can have it running in a browser tab instead. Not sure what Teams is either...
  - MaxBarraclough 6y ago
    The Slack app is essentially a Chromium browser running the usual web-based Slack. It uses the same amount of resources running in a tab in your browser. I think there are some UI niceties to the 'app' version but it's essentially the same. Teams refers to Microsoft's competing product. Like Slack, its desktop app is really just the web version.
    - piaste 6y ago
      > The Slack app is essentially a Chromium browser running the usual web-based Slack. It uses the same amount of resources running in a tab in your browser. I would expect that a pinned Slack tab in Chrome/Edge would be able to share some resources with the browser that a separate Slack app can't. Has anybody tested the performance difference between running 100 browser tabs vs. running the same webapps as 100 electron processes?
- dangus 6y ago
  Ripcord itself demonstrates why Slack is written in Electron. Is there a mobile app? Nope! Dead on arrival. In 2020, Slack or Teams or anything similar is literally useless without a mobile app. Feature matrix says animated emojis will arrive "never." lol! I remember the days of native chat clients like Skype and AIM. I remember how Linux and Mac platforms were basically half-clients compared to Windows. It sucked. Electron applications like Slack and Spotify work everywhere, exactly the same. And if you think about it, that's why something like chat and music apps would prioritize ease of cross-platform deployment over perfect efficiency. They're not particularly demanding, and they are most valuable to people when they're ubiquitous. If Spotify isn't in every device I own it loses a great amount of value. Nobody's sitting at their Activity Monitor staring at the RAM usage of Slack or Teams. In reality, performance is fine. It's just chat. (Interestingly enough, I've never found a music application that skips tracks more quickly than Spotify, even for locally-stored music. It's just instant with no gaps.)
  - xg15 6y ago
    > Electron applications like Slack and Spotify work everywhere, exactly the same. Yes, because they're just web pages. Then why not just use the browser to display them?
    - dangus 6y ago
      Nobody’s stopping you from using the web version of Slack or Spotify. That said I can think of some pretty good reasons. - Users don’t understand it as well or are less comfortable with it. - Users’ general preference for logical separation - Mobile safari doesn’t support browser notifications. - You won’t get browser notifications if you close the tab by accident - You lose OS integration, like replying via OS notifications in Slack or using OS Music controls with Spotify On top of all that a browser tab uses plenty of RAM as well so I don’t really see the upside of using the browser for these apps, either.
- kyriakos 6y ago
  You'll be lucky if you get Teams to work in a 300mb. I regularly see it hitting 1GB. The fact is though that even if it was implemented as a native up it relies so much on web views for its addons which would probably not give much benefit cause it would need to run tens of webviews as a native up to have the same functionality.
xg15 6y ago
In general, I think you're right - but that mindset can quickly become one of shifting costs to others: E.g., $framework-of-your-choice may increase your velocity and allow you to ship faster. However, it might also make it harder to find bugs and it will produce bloat with real, noticeable consequences - e.g. increased RAM, CPU and disk usage, more sluggish UI behavior, etc - except, those effects will happen on the user's machine, not the developer's, so a developer might be tempted to ignore them.

GirkovArpa 6y ago

Sciter.JS is going to change that: https://github.com/c-smile/sciter-js-sdk https://github.com/c-smile/sciter-js-sdk I cloned a 165mb Electron app in Sciter, and it was only 6mb: https://github.com/GirkovArpa/clipper-sciter https://github.com/GirkovArpa/clipper-sciter