There's a huge gotcha:
_.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't.
At some point you'll need lodash and co again - at least for convinience.
Lists of JavaScript methods which you can use natively
11–20 of 162 posts
Re: Lists of JavaScript methods which you can use natively
#12Instead of searching for the compatibility of each individual function I would much rather just use a custom build of Lodash with the collection of functions I need (which can even be handled by your build process now and some tree shaking). And I get a lot of utility functions with it too that I use a lot like Throttle and Debounce.
Might be a good idea to use a polyfill (like core-js) to ensure the api exists. On modern browsers it would just use the native impl.
Not much to gain though. Just importing lodash works fine.
Re: Lists of JavaScript methods which you can use natively
#13"However, when you are targeting modern browsers" - possibly one of the worst mistakes companies do. Then they decide to support older browsers after customers complaints. Then shit goes down!
Re: Lists of JavaScript methods which you can use natively
#14_.filter is NOT equivalent to Array.prototype.filter. The array could be null/undefined, in which case the _.filter just works fine, but Array.protoype.filter does not. I hate to riddle my code with null checks I actually do not care about.
(arr || []).filter... Is something I do when I'm not sure if the array is null or not. Looks shitty but works fine. (Now if arr is not falsy and not an array either, this blows up. But I don't know what lodash does then too)
To be honest, I'd rather check / handle nulls rather than to rely on an external library semantics. They might also change it tomorrow and upgrading would be a pain.
Re: Lists of JavaScript methods which you can use natively
#15There's a huge gotcha: _.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't. At some point you'll need lodash and co again - at least for convinience.
Object.keys() is rather well supported these days though.
Re: Lists of JavaScript methods which you can use natively
#16"However, when you are targeting modern browsers" - possibly one of the worst mistakes companies do. Then they decide to support older browsers after customers complaints. Then shit goes down!
It depends. Most of the really bad internet explorers are officially deprecated by now, so unless your customers are big enterprises with badly managed IT, it's completely fine to scrap support.
Re: Lists of JavaScript methods which you can use natively
#17It took me a moment to figure out what this was for:
https://github.com/cht8687/You-Dont-Need-Lodash-Underscore/b...
Cripes!
Re: Lists of JavaScript methods which you can use natively
#18Instead of searching for the compatibility of each individual function I would much rather just use a custom build of Lodash with the collection of functions I need (which can even be handled by your build process now and some tree shaking). And I get a lot of utility functions with it too that I use a lot like Throttle and Debounce.
If you just use lodash from a CDN, many, many users will already have it. If you make a custom build, then everyone has to download.
Re: Lists of JavaScript methods which you can use natively
#19The native version of find is still using _.find.
What?
Re: Lists of JavaScript methods which you can use natively
#20I understand why, and once upon a time I was the guy who would commit code where I replaced jQuery and underscore (at the time) calls with native calls. It works, and is totally fine. But what was the point? Some kind of optimization? It was pretty pointless in hindsight and just made my coworkers trouble. Now all my JS code is Ramda/lodash all the way, and it's great (although I opt for Clojure/script when possible)
These emperor has no clothes posts are very popular, and some may ask what's the point. It's a question worth considering. I think by instinct people especially programmer/engineer types like the idea of purity.
But if you consider that every decision must be put through a cost/benefit analysis, I think the appeal is that - I (or anyone in the future that will ever touch the code) must learn JS. OK. Now they must also learn framework X. That's the added cost.
Our memory is limited too, like a computer chip. When I know JS I can instantly access what I need. If you think of a Google or cheat sheet lookup like a disk access, well memory is faster than disk.