I just wanted to say that the behaviour of this 'nicer' idiom may not be what's expected - it stops iterating once it hits the first falsy value. I was quite excited actually when I first saw them idiom, until I quickly realized its limitations
Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I've personally never seen it in the wild.
In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).
Caching the array length still gives you a small speed boost in most browsers, but it's probably an over optimisation unless you're doing something really intensive.
If you're just writing ordinary business code (i.e. in 80% of all code out there), by all means, please use forEach and friends.
Besides, if you're doing number crunching in JS, you probably want to stick to ASM.js anyway.
Can't wait for ES6 to no longer be 'experimental', as I'd much prefer to use 'for..of' loops
On the server-side async/await are worth their weight in gold... and using lambdas is very nice. I still don't like the ES6 module syntax over node/commonjs require statements though.
The only thing to be really mindful of is when you browserify for the client that you don't accidentally include, for example the entire crypto library, buffer or similar shims because they can get very big, very quickly.
I think there are still places where you need to do this (please correct me if wrong, or mention some other cases):
- when iterating over DOM nodelists in JS (why doesn't the browser cache this as well?)
- if using strlen in C/C++ (for the latter, you should use string.length() instead).
(Sure, IE<9 is a caveat, but all the Array iteration methods are the easiest things to shim and if you're targeting below IE9 chances are pretty good it's not the first shim you'd be using.)
“A nicer-looking but limited idiom is:”
MDN documentation is on a wiki. You can just edit the page.