JoeBot3000

The majority of packages in JS land change quickly and are poorly documented, unfortunately :(

There certainly are stable packages, but sometimes to do what you need to do there is no other option.

> I regularly see websites that have noticeably slow javascript "startup" times.

True, same as any language or applications fast CPUs shouldn't be a free chance to completely ignore writing efficient code. Although I bet those websites are slow because they are doing silly things like adding 1000 items to the DOM one by one rather than being slow because someone didn't optimize their use of .forEach()

> You can make either function take arbitrarily long by increasing the size of the input. The second one scales worse.

I think this is the point, the second one scales worse - absolutely (ignoring the bug you mentioned) however it really is more readable, and because V8 is so fast, why not use the second version?

Block comments and function names are important, but if someone needs to modify the code to add or change functionality nothing beats simple & readable code.

For lower numbers this completely optimizes away for me too, but after a certain point the loops stays in place (with no flags)

I don't know that I agree with this article, while there is absolutely a problem with package/framework/build tools churn that makes development super painful, I don't feel that developing with JavaScript has been any more painful than developing with VB, C#, PHP etc was in the past.

All languages have their pain points, and modern JS/TS, while undisputably having their quirks, aren't particularly more quirky than JS (IMHO)

Super true, and JS frameworks haven't always been kind on their CPU usage (cough AngularJS).

I think desktop GUI apps also have browser rendering engines chewing resources.