Well, what browsers you support is obviously going to depend strongly on your particular site and use case. I work on a consumer-facing site for a national broadcaster which sets very aggressive browser support (oldest IE we support is IE11) which works fine for us.
Regardless, any sort of environment where you can do `import extend from 'just-extend';` is going to (have a way) support map and filter.
>> 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).
Because then you can curry/partially apply functions independent of your data.
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)
That aside, to me, putting the data argument first would seem to make the code more readable.