5 ms·

The problem with Electron apps is that they're all running their own little Chromium-like instance, hogging up hundreds of MB of RAM, clogging up the process ta

The problem with Electron apps is that they're all running their own little Chromium-like instance, hogging up hundreds of MB of RAM, clogging up the process table with all its helper processes, using up CPU when idling. I get the easy cross-platform solution part, but this is just horrible UX. I'm reminded of this article [0], about just how bad Electron is compared to native apps. [0]: https://josephg.com/blog/electron-is-flash-for-the-desktop/ https://josephg.com/blog/electron-is-flash-for-the-desktop/

LeoPanthera 9y ago
I avoid Electron apps for the above reasons. On a laptop they will eat your battery dry. It reminds me of "Adobe Air", all over again.
rpwverheij 9y ago
is anything being done to improve this? would it be reasonable to expect this to change in the future?
- forgotpw1123 9y ago
  No. JS is not statically typed and that prevents the vast majority of optimizations and better memory efficiency(native types underneath).
  - flukus 9y ago
    Not to mention the levels of indirection that also impact java and c# performance, despite 20 years of people saying "compilers will improve".
    - forgotpw1123 9y ago
      The level of indirection is minimal, basically c++ with garbage collection. That's why they're statically typed. Both perform within a small margin of native code, with the major exceptions of vector instructions that aren't supported by all CPU's
      - flukus 9y ago
        In an artificial benchmark they are pretty similar, but in real world idiomatic code they are very different to c++. Nearly everything is on the heap so you've got pointers everywhere, dynamic data structures are used everywhere, virtual functions (particularly with java) and interfaces. There's is a reason java was so much slower than native code 20 years ago and that gap has been bridged by CPU progress more then compiler progress.
        pjmlp 9y ago
        You are forgetting the crappy programmers as well. I lost count how many times I have reviewed code where a for loop is used instead of System.arrayCopy(). Or the times I have seen code that my CS data structures teacher would probably give a plain 0, even if done in C.
        flukus 9y ago
        It's probably for the best those people aren't writing c/c++ ;) I'd love to make them code in rust, their inability to write code, to even copy/paste it will save so many maintenance problems.
        forgotpw1123 9y ago
        This just isn't true. There's many Java ports of C/C++ applications and benchmarks are usually within 30%.
        coldtea 9y ago
        For the easy tasks. Try a CPU heavy C/C++ app -- like an audio/video editor, number crunching of any kind, etc.
        forgotpw1123 9y ago
        Like I said, the major exception is SIMD instructions. AV and heavy math are a tiny fraction of applications. For these you can use JNI. There is precedent for this in Netty where they use a native poll mode driver and everything else Java, and it performs about as fast as pure C code on Techempower benchmarks
  - dmsnell 9y ago
    note: the article mentions that the app is written in TypeScript which _is_ statically typed and therefore many of these optimizations are at least possible if not in place
    - TomMarius 9y ago
      He was probably talking about runtime optimizations done by CLR and JVM; this kind of optimizations is impossible even when you use TypeScript.
  - yogthos 9y ago
    I see somebody has never heard of JIT compilers.
bakchodlonda 9y ago
Natives apps are native for a reason, right? If there one extra layer of abstraction to run your code, there is going to be a performance hit.
- riffraff 9y ago
  The complaint is that the layer of abstraction is too thick. Other cross platform solutions are not nearly as heavy (though they might have other issues).
vvanders 9y ago
My gut wants to agree but then I see things like VSCode that shows it can be done with discipline and proper engineering. I also don't think you'd see nearly the level of extensions and language support if they didn't go with an electron based solution.
- Amezarak 9y ago
  I like VS Code and I don't want to crap on it, but I frequently experience massive UI lag on Windows - i.e., I start typing and the letters show up five seconds later. I think maybe it's related to source control? The same laptop runs Visual Studio fine.
  - cwbrandsma 9y ago
    oh heck, I get that in Visual Studio, IntelliJ, and XCode. Not saying I'm in love with electron apps, but they have their place. (I once wrote a trivial app using Adobe Air, also consumed hundreds of megs of ran, all the same issues as Electron...it just seems like the nature of the beast)
  - kej 9y ago
    Out of curiosity, do you get this regardless of file type? I've noticed something similar but only in Python files, and I had assumed I had misconfigured my setup somehow. Just curious if your experience was similar.
    - Amezarak 9y ago
      I see it in text files and Rust code, which are the only ones I've edited so far in VSC.
  - Matthias247 9y ago
    Do you have any kind of anti-virus tool running? I experienced several slowdowns for autocompletion in VSCode, which turned away once Avira was deactivated. I think VsCode (and especially some plugins like the language services) are working with lots of files in the background, which got slowed down due to the filtering of these tools.
Mithaldu 9y ago
I created an issue reporting the main problem caused by Electron for them: https://github.com/desktop/desktop/issues/1641 https://github.com/desktop/desktop/issues/1641 Maybe they'll figure something out.
- shoover 9y ago
  Nice. I came here to ask, "What exactly is Chrome doing while using CPU when the app is idle?" Answering this would leave the memory usage and installer size issues but make the architecture tenable for more applications.
tonyedgecombe 9y ago
This would be fine for an app you ran occasionally but for something that's likely to be running all day it isn't good.
sfifs 9y ago
Usefulness amd usability trumps efficiency every time in any user facing application. Electron enables a very large population of programmers and designers to produce useful applications using very evolved UI tech which can be multiplatform with nothing more than zipping with the right runtime - much easier than "native" or arcane cross platform UI libraries. So of course people will develop useful stuff on it amd people will use it.

LeoPanthera 9y ago

I avoid Electron apps for the above reasons. On a laptop they will eat your battery dry. It reminds me of "Adobe Air", all over again.

rpwverheij 9y ago

is anything being done to improve this? would it be reasonable to expect this to change in the future?

forgotpw1123 9y ago
No. JS is not statically typed and that prevents the vast majority of optimizations and better memory efficiency(native types underneath).
- flukus 9y ago
  Not to mention the levels of indirection that also impact java and c# performance, despite 20 years of people saying "compilers will improve".
  - forgotpw1123 9y ago
    The level of indirection is minimal, basically c++ with garbage collection. That's why they're statically typed. Both perform within a small margin of native code, with the major exceptions of vector instructions that aren't supported by all CPU's
    - flukus 9y ago
      In an artificial benchmark they are pretty similar, but in real world idiomatic code they are very different to c++. Nearly everything is on the heap so you've got pointers everywhere, dynamic data structures are used everywhere, virtual functions (particularly with java) and interfaces. There's is a reason java was so much slower than native code 20 years ago and that gap has been bridged by CPU progress more then compiler progress.
      - pjmlp 9y ago
        You are forgetting the crappy programmers as well. I lost count how many times I have reviewed code where a for loop is used instead of System.arrayCopy(). Or the times I have seen code that my CS data structures teacher would probably give a plain 0, even if done in C.
        flukus 9y ago
        It's probably for the best those people aren't writing c/c++ ;) I'd love to make them code in rust, their inability to write code, to even copy/paste it will save so many maintenance problems.
      - forgotpw1123 9y ago
        This just isn't true. There's many Java ports of C/C++ applications and benchmarks are usually within 30%.
        coldtea 9y ago
        For the easy tasks. Try a CPU heavy C/C++ app -- like an audio/video editor, number crunching of any kind, etc.
        forgotpw1123 9y ago
        Like I said, the major exception is SIMD instructions. AV and heavy math are a tiny fraction of applications. For these you can use JNI. There is precedent for this in Netty where they use a native poll mode driver and everything else Java, and it performs about as fast as pure C code on Techempower benchmarks
- dmsnell 9y ago
  note: the article mentions that the app is written in TypeScript which _is_ statically typed and therefore many of these optimizations are at least possible if not in place
  - TomMarius 9y ago
    He was probably talking about runtime optimizations done by CLR and JVM; this kind of optimizations is impossible even when you use TypeScript.
- yogthos 9y ago
  I see somebody has never heard of JIT compilers.

bakchodlonda 9y ago

Natives apps are native for a reason, right? If there one extra layer of abstraction to run your code, there is going to be a performance hit.

riffraff 9y ago
The complaint is that the layer of abstraction is too thick. Other cross platform solutions are not nearly as heavy (though they might have other issues).

vvanders 9y ago

My gut wants to agree but then I see things like VSCode that shows it can be done with discipline and proper engineering. I also don't think you'd see nearly the level of extensions and language support if they didn't go with an electron based solution.

Amezarak 9y ago
I like VS Code and I don't want to crap on it, but I frequently experience massive UI lag on Windows - i.e., I start typing and the letters show up five seconds later. I think maybe it's related to source control? The same laptop runs Visual Studio fine.
- cwbrandsma 9y ago
  oh heck, I get that in Visual Studio, IntelliJ, and XCode. Not saying I'm in love with electron apps, but they have their place. (I once wrote a trivial app using Adobe Air, also consumed hundreds of megs of ran, all the same issues as Electron...it just seems like the nature of the beast)
- kej 9y ago
  Out of curiosity, do you get this regardless of file type? I've noticed something similar but only in Python files, and I had assumed I had misconfigured my setup somehow. Just curious if your experience was similar.
  - Amezarak 9y ago
    I see it in text files and Rust code, which are the only ones I've edited so far in VSC.
- Matthias247 9y ago
  Do you have any kind of anti-virus tool running? I experienced several slowdowns for autocompletion in VSCode, which turned away once Avira was deactivated. I think VsCode (and especially some plugins like the language services) are working with lots of files in the background, which got slowed down due to the filtering of these tools.

Mithaldu 9y ago

I created an issue reporting the main problem caused by Electron for them: https://github.com/desktop/desktop/issues/1641 https://github.com/desktop/desktop/issues/1641 Maybe they'll figure something out.

shoover 9y ago
Nice. I came here to ask, "What exactly is Chrome doing while using CPU when the app is idle?" Answering this would leave the memory usage and installer size issues but make the architecture tenable for more applications.

tonyedgecombe 9y ago

This would be fine for an app you ran occasionally but for something that's likely to be running all day it isn't good.

sfifs 9y ago

Usefulness amd usability trumps efficiency every time in any user facing application. Electron enables a very large population of programmers and designers to produce useful applications using very evolved UI tech which can be multiplatform with nothing more than zipping with the right runtime - much easier than "native" or arcane cross platform UI libraries. So of course people will develop useful stuff on it amd people will use it.