Electron & NodeJS Performance Problems
Back when I wrote the article below, I was having some serious problems with my home PC. The problems might get covered up if you have a high performance SSD, but you’ll certainly notice them if you’re using a standard HD.
Adobe Cloud (Desktop) Killing Performance
What I didn’t talk about in my previous article was the performance hit I was getting from Adobe Creative Services/Cloud Desktop. While I was trying to spot and silence high disk reads, I came across a series of NodeJS processes… this concerned me because I wasn’t intentionally running Node…
Looking deeper into the process I discovered it was Adobe’s Desktop app. The app is probably written in Electron and using Node’s server to support it. The processes were extreme and combined with other issues I had to fix, it was bringing my PC to its knees.
I mentioned this to a co-worker and he told me that Adobe’s Desktop app on his Mac is also a performance killer as well (and he has an SSD.) Both he and I have been killing our Adobe Cloud app due to resource hogging.
Initially I was impressed with how quickly I could create a Desktop application using Electron. However, the performance hit I get with most Electron apps is significant.
Look at Skype’s new Electron app… it has been a real crap show for sure.
While there’s ease to prototyping and getting an application quickly to market, Electron and Node just simply suck the resources out of the system.
Discord is another Electron app that really sucks out performance. Although it’s built for gamers, I honestly hate using it. It’s fine on mobile, but on a desktop PC or Mac powerbook (SSD or not) it just doesn’t perform well.
Discord is the only app on my Mac Powerbook that pulls so much resources that I can hear it humming from over-worked CPUs.
On my home Windows PC, I get the same performance problem. This is why I uninstalled Discord from all my PCs/Mac’s.
This may controversial, especially in the age of quick development in one JS language/framework, but we really should start evaluating performance.
Perhaps the promise of “one language to rule them all,” made business entities think it was more cost effective… higher one team of developers, for less money (as JS developer roles often earn less than C++/Java developers) and the work can be exported out everywhere (Mobile, Desktop, etc.)
Yes, it’s great to write in one language and port it everywhere… But this can also be done with alternatives.
Qt does have mobile deployment schemes as well, although I haven’t attempted them. As time progresses I am finding (and probably many others) that the ease of JS to deploy anywhere (mobile, serverside, clientside, desktop) is becoming a true issue of performance.
We may just return back to the days of having a team for mobile, using a native language/framework and teams for desktop development and teams for web development.
I’m Not Alone
While my words might strike some controversy, I’ll leave the talk with this Adobe support ticket… it’s not mine, but someone experiencing the same problems I was: