Hacker News new | ask | show | jobs
by krapp 3628 days ago
In a perfect world, map and filter would extend the Array prototype, which is how the language was designed to be extended.

That aside, to me, putting the data argument first would seem to make the code more readable.

1 comments

map and filter are already builtins anyway, so it's kind of a moot point.

It sure is confusing why the author implemented these functions...

Cross-browser usage? Map and filter aren't in IE8, which is still in wider use than a lot of people would like to pretend.
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).