> start a project or feature with the coding standard of, "use the fast ones"
Ironically, that involves certain habit changes that completely obviate the library:
1) avoid map. Just create an array and write a for loop directly at the callsite, putting the code in a block rather than as a separate function
2) avoid indexOf. For single-character indexOf, it's much faster and much more efficient to match the character code (loop and check charCodeAt) than to use the function form
3) avoid lastIndexOf. Same as indexOf, except you loop in the opposite direction.
4) avoid forEach. Learn to love the for loop.
5) avoid reduce. See forEach
Anyone embracing fast.js is sacrificing some performance to begin with.
The point of this library is that it provides the same behavior (for 99.99% of cases) and the same abstraction (so same readability / maintainability) as the functions it replaces, but with significantly better performance (for wildly varying degrees of "significantly" depending on usage).
I don't think the idea is that you profile your code and then micro-optimize it using this library. If you're doing that (which you should, for varying definition of "should"), then yes you will want to consider sacrificing the abstraction / brevity for performance.
However, this library seems like a handy way to maintain the abstraction, while gaining performance essentially for free without sacrificing anything worth mentioning. Then you profile (if you were going to / had time to / cared enough to) and optimize from a better starting point. Don't see anything wrong with that.
My opinion is that JavaScript applications aren't losing that much performance by the use of lodash or fast.js but the gain in code brevity and readability more than makes up for any slight performance reduction. (Especially in a large web app where the tiny lodash library can save you many KB of boilerplate).
And with regard to performance, for most Node.js code / webapps if you have a loop with so many iterations that _.map is significantly slower than a for loop then you might be doing something wrong.
Ironically, that involves certain habit changes that completely obviate the library:
1) avoid map. Just create an array and write a for loop directly at the callsite, putting the code in a block rather than as a separate function
2) avoid indexOf. For single-character indexOf, it's much faster and much more efficient to match the character code (loop and check charCodeAt) than to use the function form
3) avoid lastIndexOf. Same as indexOf, except you loop in the opposite direction.
4) avoid forEach. Learn to love the for loop.
5) avoid reduce. See forEach
Anyone embracing fast.js is sacrificing some performance to begin with.