Lodash is what finally made me get functional programming, because I was able to start using it in small places where it made sense as opposed to diving into it all at once. At first it started out with just map and filter for some basic cases. Then I would peruse the Lodash docs now and then and discover functions that could replace a lot of my iterative, often messy code with something that felt much more elegant, especially with chaining.

With that new-found knowledge, I decided to make my 4th or 5th attempt at trying to grasp clojure and ran through some 4clojure problems. This time I breezed through the problems, and in many cases enjoyed writing it more than I would have in a typical iterative style. I made sure to follow some recommended users to see their solutions as well, which helped reduce much of my parentheses bloat.

My favorite thing about using high order functions has been that provided your underlying functions are tested/correct, you can more easily reason about and test your new functions, particularly when you keep things immutable/side-effect free.

I'm sure I would have gotten to this point eventually without Lodash, but being able to make use of bits and pieces at a time was a major catalyst for me.

Also this ? http://ramdajs.com/

Also this: http://facebook.github.io/immutable-js/docs/#/ and this: http://swannodette.github.io/mori/

Wow, this is wonderful input. I always love finding an overlap in terminology. If you find the same description of something in more than two places, I think it's safe to say that it's some kind of standard definition.

But for a functional library it has strange argument ordering.

There's a variant of lodash with auto-currying and better argument ordering: https://github.com/lodash/lodash-fp

I haven't tried it, but it looks like it could basically replace Ramda (although I feel that Ramda might contain even more FP oriented functions).

After a little bit of use, I feel like lodash-fp is limited by being a simple adaptation of lodash. Lodash's API is designed around variadic functions, which doesn't really work with autocurrying, so a bunch of important options and functionality is lost. On the other hand, working with Ramda makes me miss some of the flexibility of lodash - e.g., not having to use a different map() for arrays and objects.

The optimal functional utility library would be designed with autocurrying in mind from the start, but not shy away from flexibility where it makes sense.

Open an issue (https://github.com/lodash/lodash-fp/issues) for the options you'd like and we'll add alternative API to cover the arguments required.

lodash-fp does this for max, min, & uniq by offering maxBy, minBy, & uniqBy.

I see. Nice :)

My library of choice is http://www.preludels.com

prelude-ls really shines when combined with LiveScript - syntactic support for partial application, currying, function composition, "pipelining" (|>), implicit arguments and so much more really make a difference.

I started writing a comparison between un-sugared JS and LS use for functional programming patterns, here: https://klibert.pl/warsawjs-talk/code.html (for the talk I gave: https://klibert.pl/warsawjs-talk/).

That being said, I'm very interested in mori, immutable-js or lz.js. prelude-ls is nice, but is designed to work with native JS types and provides no extended semantics that I'd find useful. It's still my go-to library when working on the frontend and it probably will remain one, but I'm thinking about contributing some support for other advanced collection types to it.

Here's a good video showing the difference between underscore and lodash: https://www.youtube.com/watch?v=m3svKOdZijA