4 ms·

This idea that Electron apps are inherently somehow slow is starting to bug me out. While writing Electron version of our graphics heavy web application, I noti

This idea that Electron apps are inherently somehow slow is starting to bug me out. While writing Electron version of our graphics heavy web application, I noticed that the memory usage or CPU consumption is not a lot higher than some other native applications. We have taken careful care in order to write fast and memory friendly javascript if possible, avoiding using slow features of the language (the list is long, but things like forEach loops, ineffecient data structures etc) and taking care to profile and optimize. Result is an application that feels almost as fast as native and doesn't really consume so much memory even, although we are doing canvas based graphics realtime. My suspection is that many web-developers (and thus, qualified to developer for Electron) just don't have the tenacity or background to write efficient code. You can write slow-ass molasses javascript code very easily. Just take somebody who has done webdev for maybe like 2 - 3 years and doesn't have any other deeper CS background. Watch what kind of memory inefficient and slow code structures, especially with javascript where you don't really understand how heavy an operation like map() can be in worse cases, or where you are creating copies of your data multiple times for example, and voila, you have a slow-ass memory-hogging electron application. Maybe I should do a blog post about how our Electron -application is performing just to show people that you can write fast code using javascript also. But it takes skill and time, and maybe in this current day what matters is just cranking out builds that work somehow.

heipei 5y ago
I'm a self-taught JavaScript developer (front- and back-end) and I would love to read such a blog post. I mostly use language features for their expressiveness (map, filter, forEach) and rarely think about their performance implication unless there is reason to believe some piece of code is in a performance-critical path. However with a guide I might reconsider some scenarios where I'd be willing to give up expressiveness for performance.
- greggman3 5y ago
  A blog post would be nice. You can also test https://jsbenchit.org/?src=708dfb8b9bbfe885f5495f74179fdb72 https://jsbenchit.org/?src=708dfb8b9bbfe885f5495f74179fdb72 https://jsbenchit.org/?src=f0fd4a14ff9a7049d88f57e0fd45b865 https://jsbenchit.org/?src=f0fd4a14ff9a7049d88f57e0fd45b865
- inDigiNeous 5y ago
  Thanks for the encouragement. I will look into this more and write a blog post about, it is actually something I wanted to do for some time now, I'll make sure to post it to HN also and report what we have found .. We have been developing this application since 2011 already, and I also develop in C++ and 3D graphics, so performance has been something I've had to think. But yeah, there are many guides on what to avoid in JS already, how to optimize for speed and memory. But it is not definitely an easy thing to realize, as it's not inherently visible what can be slow and what not. Most blog posts at this time talk about how to optimize for the V8, and I'm not really interested in that so much, as it can be taunting to try to understand how V8 works for example.
N1H1L 5y ago
Please write the blog post and share it to HN. I would really look forward to reading it and learning from it.
- inDigiNeous 5y ago
  Thanks. I will :)
mike_d 5y ago
It isn't just Electron, Node is also plagued by its own low barrier to entry. One of my former employers had the great idea of hiring hundreds of "senior" JS devs and redoing the entire frontend of the website. When it launched to production the whole system scaled at approximately 1 enterprise-grade server to 1 concurrent user. While I applaud your efforts to teach people how to write code faster, the majority of JS devs I have found just want to hit feature-complete and go home.
- kiawe_fire 5y ago
  IMO, it’s not just JS devs. Most of the backend PHP devs I work with are similar. And when nearly every Stack Overflow post asking about performance implications is answered with a litany of “YAGNI” and “premature optimization”, its not hard to see why. The current comp sci culture seems to discourage this in all but the lower level languages like C.
Klonoar 5y ago
You're not wrong, but at the same time, if 99% of Electron applications are slow, then I have no problem calling Electron (as a movement, not a technology) slow. It is also pretty evident that default Chromium itself is a complete battery slog. You can make an Electron app not slow/a battery hog, but it requires working backwards from a state of "what on earth is going on under the hood here". This is the inverse of building a native application, where that complexity is often introduced by you. I personally find this significant - you can teach someone how to avoid the latter, but it can require crazy amounts of insight to learn to debug the former. It is 100% possible to build better Electron apps. I trust almost nobody to actually commit to doing it. Also, particular yet tangential to this thread: apps like Signal or Discord which still make their Electron apps run under Rosetta 2 on an M1 are a nuisance. I just run Discord in a browser tab at this point.
- inDigiNeous 5y ago
  Yeah it's true. Of course native code will perform by default faster and be more battery friendly, but V8 is also very optimized and can perform easily like 80% of native speeds if given some thought. Yeah many people do not just have the time to look into this, and most companies don't really care, as we have so much RAM and CPU power these days, so I can see why for example many messaging apps just choose to write their app in Electron, instead of trying to figure out how to do it natively cross-platform, which can be a more PITA especially when you also have web as a platform.
  - Klonoar 5y ago
    >can perform easily like 80% This feels like... a trap. I think there's a complexity in doing that which could be summarized as follows: it's possible, but the more complex your codebase, the more difficult it is to reason about how to get to or maintain that 80%. Even if we assume that 80% is the maximum, if most products (or the notable ones that we all complain about, I suppose) are hitting 50%, then... well, that's a problem. For full disclosure: I've defended Electron on the merits of "there is sadly no better way to ship cross-platform UI-based software". I criticize it with this in mind.

heipei 5y ago

I'm a self-taught JavaScript developer (front- and back-end) and I would love to read such a blog post. I mostly use language features for their expressiveness (map, filter, forEach) and rarely think about their performance implication unless there is reason to believe some piece of code is in a performance-critical path. However with a guide I might reconsider some scenarios where I'd be willing to give up expressiveness for performance.

greggman3 5y ago
A blog post would be nice. You can also test https://jsbenchit.org/?src=708dfb8b9bbfe885f5495f74179fdb72 https://jsbenchit.org/?src=708dfb8b9bbfe885f5495f74179fdb72 https://jsbenchit.org/?src=f0fd4a14ff9a7049d88f57e0fd45b865 https://jsbenchit.org/?src=f0fd4a14ff9a7049d88f57e0fd45b865
inDigiNeous 5y ago
Thanks for the encouragement. I will look into this more and write a blog post about, it is actually something I wanted to do for some time now, I'll make sure to post it to HN also and report what we have found .. We have been developing this application since 2011 already, and I also develop in C++ and 3D graphics, so performance has been something I've had to think. But yeah, there are many guides on what to avoid in JS already, how to optimize for speed and memory. But it is not definitely an easy thing to realize, as it's not inherently visible what can be slow and what not. Most blog posts at this time talk about how to optimize for the V8, and I'm not really interested in that so much, as it can be taunting to try to understand how V8 works for example.

N1H1L 5y ago

Please write the blog post and share it to HN. I would really look forward to reading it and learning from it.

inDigiNeous 5y ago
Thanks. I will :)

mike_d 5y ago

It isn't just Electron, Node is also plagued by its own low barrier to entry. One of my former employers had the great idea of hiring hundreds of "senior" JS devs and redoing the entire frontend of the website. When it launched to production the whole system scaled at approximately 1 enterprise-grade server to 1 concurrent user. While I applaud your efforts to teach people how to write code faster, the majority of JS devs I have found just want to hit feature-complete and go home.

kiawe_fire 5y ago
IMO, it’s not just JS devs. Most of the backend PHP devs I work with are similar. And when nearly every Stack Overflow post asking about performance implications is answered with a litany of “YAGNI” and “premature optimization”, its not hard to see why. The current comp sci culture seems to discourage this in all but the lower level languages like C.

Klonoar 5y ago

You're not wrong, but at the same time, if 99% of Electron applications are slow, then I have no problem calling Electron (as a movement, not a technology) slow. It is also pretty evident that default Chromium itself is a complete battery slog. You can make an Electron app not slow/a battery hog, but it requires working backwards from a state of "what on earth is going on under the hood here". This is the inverse of building a native application, where that complexity is often introduced by you. I personally find this significant - you can teach someone how to avoid the latter, but it can require crazy amounts of insight to learn to debug the former. It is 100% possible to build better Electron apps. I trust almost nobody to actually commit to doing it. Also, particular yet tangential to this thread: apps like Signal or Discord which still make their Electron apps run under Rosetta 2 on an M1 are a nuisance. I just run Discord in a browser tab at this point.

inDigiNeous 5y ago
Yeah it's true. Of course native code will perform by default faster and be more battery friendly, but V8 is also very optimized and can perform easily like 80% of native speeds if given some thought. Yeah many people do not just have the time to look into this, and most companies don't really care, as we have so much RAM and CPU power these days, so I can see why for example many messaging apps just choose to write their app in Electron, instead of trying to figure out how to do it natively cross-platform, which can be a more PITA especially when you also have web as a platform.
- Klonoar 5y ago
  >can perform easily like 80% This feels like... a trap. I think there's a complexity in doing that which could be summarized as follows: it's possible, but the more complex your codebase, the more difficult it is to reason about how to get to or maintain that 80%. Even if we assume that 80% is the maximum, if most products (or the notable ones that we all complain about, I suppose) are hitting 50%, then... well, that's a problem. For full disclosure: I've defended Electron on the merits of "there is sadly no better way to ship cross-platform UI-based software". I criticize it with this in mind.