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.

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.

The editor that became known for consuming nontrivial amounts of CPU for blinking the cursor, something computers could do since they replaced paper tapes with screens.

*became known to you for a big that consumed nontrivial amounts of CPU

- Many people know VS Code before that

- It was a bug, not something inherent to Electron

That issue was limited to mac, as far as I know

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.

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.

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.

I see it in text files and Rust code, which are the only ones I've edited so far in VSC.

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)

>My gut wants to agree but then I see things like VSCode that shows it can be done with discipline and proper engineering.

VSCode just makes an tolerably-fast Electron app. Still doesn't solve the CPU usage, battery hungrinees, and memory hoginess of the platform.

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.

I created an issue reporting the main problem caused by Electron for them: https://github.com/desktop/desktop/issues/1641

Maybe they'll figure something out.

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.

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.

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).

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.

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

No. JS is not statically typed and that prevents the vast majority of optimizations and better memory efficiency(native types underneath).

Not to mention the levels of indirection that also impact java and c# performance, despite 20 years of people saying "compilers will improve".

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

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.

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.

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.

This just isn't true. There's many Java ports of C/C++ applications and benchmarks are usually within 30%.

For the easy tasks. Try a CPU heavy C/C++ app -- like an audio/video editor, number crunching of any kind, etc.

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

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

He was probably talking about runtime optimizations done by CLR and JVM; this kind of optimizations is impossible even when you use TypeScript.

I see somebody has never heard of JIT compilers.