`map` and `filter` should take their functional argument first, then data second.
That aside, to me, putting the data argument first would seem to make the code more readable.
It sure is confusing why the author implemented these functions...
Regardless, any sort of environment where you can do `import extend from 'just-extend';` is going to (have a way) support map and filter.
That is not true for the now-fairly-common use case that browserify/webpack satisfy. I write code with ES6 module syntax and build with browserify (& babelify) to target the browser. But I still need to pull in modules like lodash.map/lodash.filter if I want to target IE8.
(I could use es5-shim but that makes for less portable code).
It's _not_ because it's convention everywhere else.
(I realize that only really makes sense if you know why it makes sense, so this video gives a pretty good explanation in ~30 minutes - https://www.youtube.com/watch?v=m3svKOdZijA)