Ditch ES5 array methods in favor of simplified fallbacks. #12

Closed
jdalton opened this Issue Mar 2, 2013 · 2 comments

Projects

None yet

2 participants

@jdalton
jdalton commented Mar 2, 2013

Avoiding ES5 array methods gives you better performance, portability, and the ability to add custom features.

Prime's current implementation relies on the presence of a native method first, which means if the method is shimmed incorrectly (which happens all the time) code built on Prime will be affected. Libs like NWMatcher, Dojo, YUI, Ember, and Lo-Dash detect and avoid shims increasing their portability because they can be used in environments which devs may not entirely control.

Because Prime is native first, its fallbacks must also follow spec or introduce cross-browser inconsistencies. Following spec cripples the perf of its fallbacks too because they have to do the (i in this) checks. Even if Prime follows the ES5 spec it still falls to cross-browser inconsistencies of what various engines consider sparse (IE < 9 will consider var a = ['', undefined, null] sparse, and other engines won't).

Because it's not limited to the ES5 specification of Array#map it can customize how callbacks are handled allowing for syntax like _.map(users 'username') to return an array of each user's username property value. Also notice it avoids .call in the loop by only performing the thisArg binding if it's passed. Finally, it fast paths arrays and falls back to the internal each function for objects, strings, and arguments objects. This allows it to fast path the common case while still providing consistent cross-environment support for the other cases.

@kamicane
Owner
kamicane commented Jul 5, 2013

Closing, as the split-generics branch is now on master. Not using es5 natives anymore. Good points.

@kamicane kamicane closed this Jul 5, 2013
@jdalton
jdalton commented Jul 5, 2013

I can dig it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment