New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Just vs lodash #4
Comments
Lodash (even lodash-modularized) has dependencies. |
@aristidesfl @angus-c In addition, there are babel and webpack plugins to make cherry-picking and bundle size optimizations a breeze. The individual modularized method packages, e.g. lodash.chunk, may or may not have dependencies. However, their dependencies are shallow and many have been inlined to keep dep counts low. |
Lodash is well used and well liked, and I have no problem with people using it. The question was about the differences. Just had a philosophy of importing just one small function with zero dependencies. Closing as this is straying off topic. |
@angus-c after looking at this lib's README, first thing I thought is "How does this compare to lodash?" (this is how I stumbled upon this issue). I'd suggest you address this directly in the README, as people picking a dependency for their project are likely to compare this to other libs. |
@ThibWeb I'm planning a blog post on the rationale for Just, which I'll link to here. |
That would be amazing On Thu, Jul 21, 2016, 3:46 PM angus croll notifications@github.com wrote:
|
Would be nice to have some concrete numbers in the blog post / comparison , like module size (including dependencies), and performance. |
@aristidesfl It kind of feels like retrofitting an argument, or picking a fight, since Angus wasn't aware that Lodash was modular or had individual method packages. There wasn't a particular failing or slight of Lodash that sparked the creation of Just. Since Angus isn't super familiar with Lodash it'd be harder to represent Lodash fairly in comparisons. You don't know what you don't know, you know? |
Preface: Lodash user here, and I thought it strange for this lib to exist at first glance. Lodash is modular, duh. Then I realized it was published by Angus Croll (Hemingway, anybody?), and had to figure out why he'd do this. Here's what I found:
There are other points of general difference, but let's go with these. Here's a great way to sum up the comparison: lodash.union - 318 LOC: https://github.com/lodash/lodash/blob/4.1.1-npm-packages/lodash.union/index.js Yes, the LOC count includes empty lines and source docs for both, which may not be fair since Lodash is such a mature, longstanding lib. This bears consideration. That said, the just-union source is so succinct that I'm going to paste it right here: module.exports = union;
/*
union([1, 2, 5, 6], [2, 3, 4, 6]); // [1, 2, 3, 4, 5, 6]
*/
function union(arr1, arr2) {
var result = arr1;
var len = arr2.length;
for (var i = 0; i < len; i++) {
var elem = arr2[i];
if (arr1.indexOf(elem) == -1) {
result.push(elem);
}
}
return result;
} I love the idea of using small chunks of code for this utility stuff, chunks that are probably similar to what I'd write myself if we didn't have these libs. For debugging alone, there is a clear advantage to this approach. Parting note: much love for Lodash, I just felt an uninvolved third party actually digging into the case for this lib could be helpful for others. There's plenty of room in the industry for both. |
Lodash's Lodash is in the local npm cache of most users so it's not downloaded from the npm registry. |
@jdalton yep - not pointing out weaknesses, just points of difference. That said, if Lodash's union is 840x faster than the just-union package, that'd be very compelling information for folks to be aware of. Might be worth posting a jsperf whenever they're back online. |
Dependency count (esp. low to no) isn't a thing devs should get super hung up on. There's plenty of other compelling info like Lodash has ~100% code coverage, environment testing, and is completely customizable. If there's gaps, bugs, or failings they're usually addressed pretty quickly too. |
I'm not very interested in a lodash versus just comparison. As I keep saying, I like lodash, the two libraries can and should coexist. But if the question is why did I build a 10 line utility instead of a 1000 line utility, it's because I can.
Also what does 840x faster mean? For arrays with Number.MAX_SAFE_INTEGER elements? For all practical purposes I'm more than happy with the results
Now can we just co-exist? Please? |
I would say the comparison is both necessary and unavoidable, not to determine superiority, but to determine which is the right tool for my project. There's no reason for such comparison to be anything other than amicable. @jdalton there's no argument, lodash is an excellent lib. You should be proud. |
@jdalton how did you measure that 840x? I'm pretty sure that you are using O(N ^ 2) worst case time complexity in your Test Lodash's unique against:
With the following input data:
|
Me neither. See above.
The number of files or lines in the That said, I prefer the primary
var union = require('just-union');
var _ = require('lodash'); Naw. You can see similar with a smaller amount. var a1 = _.shuffle(_.range(5000));
var a2 = _.shuffle(_.range(3500, 8500));
console.time('a');
union(a1, a2);
console.timeEnd('a');
// ~6266.933ms (6 seconds) var a1 = _.shuffle(_.range(5000));
var a2 = _.shuffle(_.range(3500, 8500));
console.time('b');
_.union(a1, a2);
console.timeEnd('b');
// ~4.234ms Careful though, Making packages with naive implementations is nothing new. There's plenty of them out there. The devil is in the details though. Even something as simple as array-last or lodash/last can have surprises (see #9). UpdateI've revved up inlining, so
|
This is not fair! You are testing best case of Lodash against worst case of @angus-c implementation.
|
Linear search bogs down the longer the array is. That's just how it is. |
@jdalton good call with the mutation, I missed that |
That's naive vs. a bit more robust for ya. I get it. I do. You'll likely not hit new territory in this thread though. |
@jdalton should I? What I'm saying is: "In non ES6 environment |
In older environments I use a |
It does not prove anything. If I pass two arrays of objects, the time complexity will be O(N ^ 2). |
Sure, but that's not the primary use case and not something Node folks have to worry about in 0.12 and beyond or browser folks with IE11 and beyond. So Lodash get's great perf most of the time vs. other packages. Seems like a win to me. I'll put it another way. I pay special attention to methods like Check out my ThunderPlains talk over performance. Optimizing for the common case is a theme. FWIW, though I don't dig the technique, the core-js |
Don't get me wrong. I've never said that Lodash is bad library. My initial comment was about worst case performance time. JS is shitty in set theory API. We had to wait several years before native |
You derailed the thread pretty good there. |
Next time would better if you take algorithm course, since you don't know what time complexity means! I'm tired from all those javascripters with lack of computer science degree. Anyway, write what you want but don't tell me how your |
Is this O(N) solution? What will be happen with frozen objects? Or again this is an edge case? Your algorithm can be described with O(N) best case and O(N ^ 2) worst case. Nothing more, nothing less. If you can't get over it, this is not my problem. |
Yep. If it's a frozen object (so an edge of an edge case) core-js falls back to linear search. Relying on |
the differences to lodash should be listed in the readme.md, because that will be the first question that a typical js developer come up with |
Lodash doesn't have dependencies and its methods can be imported individually, e.g.
How do just modules compare to equivalent lodash methods?
The text was updated successfully, but these errors were encountered: