71–80 of 162 posts
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.
Instead 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.
Only if each site is using the exact same version of Lodash which is unlikely. Lodash is tiny anyways.
For the sake of 25KB for the full Lodash library, is it really going to make much difference? That size will be eclipsed by just a single small image on your website. Development is all about tradeoffs. Liberal use of Lodash can make for clean code that abstracts away subtle browser differences. For a small download size it sounds like a great tradeoff to me.
Yes, you could implement every feature of just about any library yourself. Why, though?
I think the point of the page is to demonstrate that for many, many lodash functions, there are direct equivalents in native JS - not rewritten features.
Earlier quoted context omitted.
And it will also lead to the site not working out-of-the-box for privacy-conscious people like me who block third-party JS by default.
Well you can avoid that with an inline script that checks for it and includes it from a local path if it fails. But that's just more waiting, and you still end up downloading the ENTIRE script (unless you get REALLY fancy with webpack in a way I don't even want to think about...)
I have a friend who has done, in production, exactly what your subconscious is afraid of. I should get him to do a write up sometime: it's both amazing and horrifying at the same time...
All kidding aside, a lot of our lodash code ends up looking something like this:
function (xs) {
return _(xs).pluck('foo').filter().value();
}
Most of the time, we want our function to just swallow those errors and return an empty array in such cases. This is exactly what lodash does, but if we tried to call xs.map(...) in that case we'd get an error. Similar caveats apply for grabbing the foo attribute if one of the array elements ends up being null or something.
For this reason, I recommend continuing to use lodash almost all of the time, even when there's a native Javascript method available.
https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_...
Getting rid of unnecessary dependencies can have a huge impact on site download performance, especially on mobile. Even in the case of having the site cached, every resource you link will have to perform an HTTP request to at least receive NOT-MODIFIED. It can add up, especially if you're on a semi-spotty connection and trigger TCP congestion avoidance.
Alternate title for the article: "Lists of lodash features replaced by ES6 if you don't mind throwing an exception when given invalid input such as null or undefined". All kidding aside, a lot of our lodash code ends up looking something like this: function (xs) { return _(xs).pluck('foo').filter().value(); } That code clearly expects that xs is an array of objects. However, we might occasionally end up with xs being…
No no no no. That's a silent failure and a bug. That means our code is doing something we don't intend or understand.
Earlier quoted context omitted.
Don't miss the forest for the trees. Re-implementing _.forEach, _.map, and _.reduce to do something like loop over objects yourself is going to most likely end up taking more code than just using those functions from lodash. Not to mention that you most likely won't have the same amount of testing, speed/optimization, or "familiarity" across devs with a home-grown solution. Yeah, don't pull in lodash if you are makin…
I do not agree at all. What is so hard about for loops? I do not agree that using the native-to-the-platform looping constructs will create as much code as half a megabyte. I'm looking at it right now: the full build of Lodash is 503KB. That's also half-a-meg of code that needs to be parsed by the JS engine. And nothing else you said has anything to do with site performance. Do users care if it took you 10 seconds ve…
If you are only using _.forEach, then you should only include _.forEach, which comes out to about 10kb before gzip compression, 5kb after (i just built it myself to test). And all but about 1.2kb of that is "core" code, so if you add additional lodash functions, most of them will increase the code size by about 2kb at the most.
That means that for an overhead of about 8kb, you can start adding extremely useful functions all throughout your codebase with very little overhead. 1.2kb to easily and quickly iterate over an object using the key and the value in each block;
_.forEach(obj, function(value, key) { // do stuff })
Object.keys(obj).forEach(function(key) { var value = obj[key] // do stuff })
Now let's look at _.find in an object...
_.find(obj, { 'age': 1}) // returns the first object (in the object) that has a property 'age' that equals 1.
var objKeys = Object.keys(obj)
var retval
for(var i; i You could use the native .find() function, but that won't work on chrome for android, android browser, IE (any version), safari 7 and older, and opera. Plus you'd still need something like Object.values() in order to convert the "parent" object into an array to search through.
Plus what if i want to find an object in an array and in another object? (which I actually just had to do, which is why i thought of this use case) Well now you've just doubled your code, doubled the amount of tests you need to write, doubled the chance for random bugs to crop up (what happens if one of the object values is undefined? What happens if obj is null?).
With stuff like the lodash cli where you can make builds that literally only contain what you need, the lodash babel plugin that will allow you to require lodash functions and it will build only what you need, or webpack which will tree-shake away everything you don't need (and actually does a better job than the lodash-cli does!), there's no need to avoid lodash like the plague.
I'm not saying include all of it, i'm not saying use it in everything, i'm saying that you should use your brain and include it if it's going to increase the speed that you can develop, reduce the number of bugs you will face, simplify your codebase, and won't negatively impact your users. (after all, a single image will blow the 5kb of js you'll be saving out of the water)