The point of this test is to show that by creating your own custom forEach-lite or other native-lite implementations you can get better performance over native.

Many times you don't need to support all of the functionality/edge cases of the native method and that allows you to gain performance/custom-functionality and save code because you no longer need to have an ES5 compliant fallback.

Many libs, like Underscore.js, fork for native methods but could reduce code/gain speed if they settled for simpler methods.

Most devs don't care about supporting sparse arrays or ToUint32'ing a `length` value and this allows us to optimize for the common case.

Also, by implementing a custom method you can gain functionality like exiting early by explicitly returning `false` or method chaining.

http://jsperf.com/for-vs-array-foreach/4

Well, `forEach` being faster than a for loop is more of a newbie misconception I think. It's not an unreasonable assumption, after all. In fact, looking at the `forEach` algorithm[1], it is not even immediately obvious why it would be so much slower than a for loop.

It seems that the killer is the membership test[2] at line 44. What I don't really understand is why `i in O`, when O is an array, would be so slow, and furthermore, given that it is that slow, why `forEach` uses it instead of a simple bounds check.

[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global...

[2]: http://jsperf.com/for-vs-foreach/17

Strongly agree. To me the majority of slides read like one big strawman, I didn't realise the myths were even myths. Or, in a couple of cases, what they attribute to performance concerns are things I'd attribute to good programming style for other reasons.