[serve_yay]

Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away.

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.

[pluma]

I think nearly every JS engine now optimizes `for (...;i < arr.length;...)` -- I'm nearly 100% sure V8 does and fairly certain Firefox's and ModernIE's do as well.

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).

[thomasfoster96]

forEach is awfully slow compared to a for statement if you're dealing with numbers - less so with strings/objects, but it's still noticeable (like 10x whenever I've tested it at best).

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.

[pluma]

If you're doing number crunching, yes, don't use forEach.

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.

[jaredsohn]

I think a big reason to cache the array length within interviews (for cases when it isn't already cached) is that to not do so can often increase the complexity of a solution by a factor of O(n).

[kremlin]

the problem with using it even when you don't have falsy values is that, eventually, you're going to forget that you can't use it when you do have falsy values. You're going to get too comfortable with it, and it's not general-purpose enough.

Can't wait for ES6 to no longer be 'experimental', as I'd much prefer to use 'for..of' loops

[tracker1]

Honestly, I'm more excited about some of the ES7 features at this point... I've given in, as much as I dislike transpiling, and using BabelJS for most of my new development, server and client-side.

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.

[jaredsohn]

>old canard about caching the length of an array when iterating over it

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).