> The alternative given for a jQuery.each statement is the IE9+ supported Array.prototype.forEach — now you'd think this would be faster right? It's actually still not as performant as it could be. As this jsPerf set of benchmarks shows is that a for loop is the most performant option: http://jsperf.com/foreach-vs-jquery-each/38 — it might not be as pretty as jQuery.each or Array.prototype.forEach, but heck, it's a whole lot faster than the alternatives.
So I'm by no means a compilers or js engine expert, and this really is an honest to god question and not an attempt at sideways criticism.
When I use each, forEach, map, or something like that, I'm usually optimizing for my own readability and to try to create more concise and understandable code (admittedly only for folks comfortable with those paradigms) and not actual raw performance.
Is it the case that Array.prototype.forEach is faster than a for loop for all modern browsers, and could that change with engine optimizations? My wonder there is that it smells like premature optimization while sacrificing readability (again, assuming you think map/forEach/etc is more readable, which might be a huge assumption).
I think you make a very valid point. One poorly optimised loop using jQuery.each or Array.prototype.forEach unless you're writing a heavily JS intensive application isn't really going to make a noticable difference to performance. The average Joe developing a Wordpress theme with a slideshow and a few other little pieces of JS probably won't see any lag nor benchmark said theme. However, it does all add up the more you use Javascript for, you eventually get to a point where the milliseconds of delays and spikes in RAM usage add up and cause delays/lag.
I think it's just important to be aware of the alternatives and trade-offs using certain methods and knowing when to a 3 line method in place of a one-liner piece of jQuery. On a site I am currently working on I am using jQuery.each, I am modifying elements in the page using jQuery.width and all kinds of other things I normally would advise against in a large application. But the site I am building which is a Wordpress theme uses such little amounts of Javascript that using a more optimal method wouldn't really make much of a different interaction and latency wise.
My point was more-so that there are developers out there using poorer methods even in large-scale applications because that's the only way they know how to do it. Just being aware of what you can do in Javascript can be a beautiful thing and even save your hide in a situation where the page is freezing up when you scroll (an event I recently witnessed occur and had to fix).
In time I do believe native methods and certain implementations will get better. Javascript has evolved quite a lot in the last few years and shows no signs of slowing down.
Got it. That makes sense, and I definitely agree with the point of knowing the language features and being aware of the trade offs you're making by choosing one technique over the other.
So I'm by no means a compilers or js engine expert, and this really is an honest to god question and not an attempt at sideways criticism.
When I use each, forEach, map, or something like that, I'm usually optimizing for my own readability and to try to create more concise and understandable code (admittedly only for folks comfortable with those paradigms) and not actual raw performance.
Is it the case that Array.prototype.forEach is faster than a for loop for all modern browsers, and could that change with engine optimizations? My wonder there is that it smells like premature optimization while sacrificing readability (again, assuming you think map/forEach/etc is more readable, which might be a huge assumption).
Thoughts?