I think it's a bit unfair to label using a known fast library over a known slow library as "premature optimization". I would much rather start a project or feature with the coding standard of, "use the fast ones", rather than have to go back through all the code, profile it, and replace only the ones hurting performance.
> 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.
No, but using a non-spec compliant implementation across the board because "it's faster" is definitely premature optimisation. This is the sort of stuff that should be kept for performance critical bits, not used application wide.
Yeah but it could be a premature optimization if you blindly decided to use a library because the cost of having to download it (in the case of browser JS) and/or parse (in the case of server JS) an extra script file may outweigh its performance benefits.
It may be premature optimization to use a faster library when the faster library has known places where it differs from standard behaviour, and almost certainly lots of bugs.
I don't know much about fast.js in particular but in this case there might be an advantage of using the fast functions simply because they have simpler semantics. There are many bugs and inconsistencies that come up from people expecting that native methods behave the same as simple for-loops when they actually don't.
I'd agree with you if we were comparing apples to apples.
This is not the case with Fast.js as it breaks away from the language specifications. I'd much rather build, profile, and then optimize the few areas that actually require better performance than potentially introduce bugs by replacing the built-in methods.
