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.
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.
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.
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.
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.
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.
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.
I use mainly VSCode these days though and Firefox, but even Unity game engine works just fine on this machine.
Any IDE I also throw at this machine works just fine. Only things that feel slow, are things that need a beefy GPU.
Probably depends on the IDE and the language. My impression is that newer computers (especially in the "consumer" / "general public" market) have especially improved efficiency. They're not much faster, but they last longer on smaller batteries.
My late 2013 15" (2.3 GHz / 16 GB RAM) works great with Pycharm for moderately sized projects. It's even usable for personal Rust projects (with the intellij-rust plugin).
For Rust it's somewhat slower than my i5-8500 desktop but not by much. For incremental compiles, I don't feel like I'm waiting around more. The i5 mainly wins when it can use all six cores.
It's however quite a bit faster than my work HP ProBook with an i5-8250U which is a much newer machine (2018 I'd say).
Aside from battery life, which is somewhat lesser, all in all the mac is a much, much better machine than the HP, especially for "creature comforts": gorgeous screen, no misaligned panels rubbing against my wrists, great trackpad, no random coil whine, inaudible fans unless it starts compiling for a while, no background noise on the headphone out, integrated optical output when I want to use my home stereo.
My work 2019 16-inch MacBook Pro actually doesn't feel that fast considering how fucking expensive it is.
Quiet and cool with about 11 hours of battery life when writing, reading or some simple productivity stuff.
Fast but loud and hot when doing anything else with about 3 hours of battery life. Even the Touch Bar (which I don’t hate, but I also don’t love) is uncomfortable to the touch.
It seems there is no in between. I’m generally happy with the machine, but I’m very interested in what’s next for the big MBP.
I've also had issues with the laptop waking from sleep, where it'd either hang for up to minutes, or just outright kernel panic. Big Sur seems to have fixed the kernel panics but waking from sleep still feels really slow.
I think from 2016-2019 was a rough era for the MacBook Pro when you factor in price for performance; still great machines, but they didn't feel as polished as the 2015 MBP or the 2020 M1's.
Edit: year banding.
Except for the keyboard. Been replaced three times. It's defective by design. Such a letdown.
We’re in a golden age of cpu improvements. A dual core 2016 mbp isn’t good enough for me any more.
Just wondering, don't those cores still have HyperThreading or such, resulting in actually more cores than just 2 physical ones ?
Finally sold the 2011 MacBook Air a few months ago for $300. I got so much value out of that laptop.