Let this be a lesson that JavaScript is not slow. The DOM can be slow, and downloading large bundles can be slow, and any code can be made slow if you try hard enough to write it poorly. But JavaScript the language is not slow in 2020.
When we talk (or rant) about the performance of JS-based apps - running on the web or in Electron or otherwise - it's really important that the conversation focus on the factors that actually matter.
No, JS is slow(ish). The GC pressure alone will kill you. This is fast despite being in JS by simply doing as little as possible (while still meeting the requirements on the end result, which is where the genius lies).
The fastest code is no code. No code is fast even with pathologically slow languages/runtimes.
It's no slower than Python. Probably faster unless you're staying within a native library like NumPy.
But that wasn't my main point: my main point is that people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Sometimes it's poor usage of the DOM. Usually it's ads. It's almost never the unavoidable overhead of JS cycles.
> people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience.
Are you sure you got this right?
Just because JS is fast[0] doesn't mean we cannot complain about Javascript apps that should have been plain web pages?
It is clearly possible to create advanced Javascript apps that are enjoyable even to people like me.
For most pages I use as a consumer I don't see much value add because of frontend code: I see the value of autocomplete, drag-and-drop etc but I would much prefer if my CPU stopped chewing after web pages were loaded and rendered.
[0]: yes, I agree - in most cases the Javascript language or engine is not the cause of the performance problems on the web
Whether or not a given site should be client-side rendered is a valid discussion
Ad bloat is a valid discussion
Lazy development practices in modern sites/apps are a valid discussion
But in my experience, these as well as other less-legitimate issues all tend to get lumped under the banner of "JavaScript stuff == slow", without any nuance.
Can't say for sure but the way I read them most complaints about Javascript performance are about the results of the abuse of Javascript applications everywhere.
I guess Javascript just happens to be the common thing between a number of them, and people would be just as annoyed if the multi-megabyte, cpu-hogging, data-stealing monstrosities where hand-crafted in assembly ;-)
And: If someone complained about Javascript being slow for scientific calculations I'd probably call them out on it ;-)
> but I would much prefer if my CPU stopped chewing after web pages were loaded and rendered.
this happens when it's programmed with performance as an afterthought, which is sadly how things work when the prerogative is to just ship more features and continually ingest dependencies with the most features, with little vetting.
For me as a user it seems to be: loading google analytics, loading fonts that seem to be improperly cached, loading chat windows, assistance widgets and spies, and dynamically adding things after page load that cause reflows.
It's among the fastest scripting languages. Only LuaJIT turned out to be faster (than Node.js) in my benchmarks. Node is on par with Dart most of the time and the latter is statically typed.
When we talk (or rant) about the performance of JS-based apps - running on the web or in Electron or otherwise - it's really important that the conversation focus on the factors that actually matter.