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
Contributors: Underscore + Lodash #2184
Comments
He sure is. |
Well, to get the ball rolling:
I think this is entirely solved by modularizing functions. We can still offer the current underscore functions as just a different build of the modules, while also adopting anything we like. If there's anything we reject, it'd be extremely easy to offer those as "contrib" modules, akin to underscore-contrib
I wouldn't be opposed. But, I think offering ample code samples in the source would be a huge plus.
👍 💯
👍
I agree. That should help immensely in deciding how we go about merging the codebases. |
This becomes a pain to manage. Do I have to require in What about other utility libraries duplicating such simple functions? One of the goals of Underscore is that it's all the base functions you may need on any given project (or library) that are at least somewhat de facto standardized between projects. If there are 5 different
A few, maybe. And more than we have now. But it's a tricky balance. Maybe we should create an examples page, or inline some extra ones into the docs hidden behind some JS? Tests also exist as examples, though I wouldn't recommend learning how to use Underscore from them.
Eh. This is always the first thing the corporate robots always want to see. What would this say, anyway? Keep JS weird!! |
Agreed about the project priorities. We need to define those first. One major difference is underscore likes to define functions in terms of other underscore functions (for readability of the source code), while lodash prefers to define functions' behaviour directly or using internal helpers (for performance). Underscore has been borrowing that style for some functions with particularly large performance gains, but has mostly avoided it. When it comes to modularisation, I think this is a no-brainer. We should follow lodash's lead here and split each function out into its own file, which can be included individually. For releases, we can have a module that pulls in and exposes each of the individual functions, then bundle it and distribute that as another module. For documentation, I'd really like to see each function listed with type signatures (I don't care whose type system we use), and remove the fairly unhelpful hierarchy. |
No way. Empirical evidence is hard to come by or inconclusive, but I'd bet my bottom dollar that the majority of lodash users are using a complete version, not individually picking methods here and there. In terms of mental simplicity, it's way nicer just to include a no-fat library and forget about it. That said, offering modularized methods as an option is fine. Ideally they wouldn't all live in separate files, but would be built/split out into separate files as a part of the build/publish process. Then you can have your readable nice source code, and get your mini-libs too. |
Undoubtably. But, we can offer the best of both worlds (as lodash already does) even when you only install the // Slow, since it loads up **everything**
var _ = require('underscore');
// Faster, smaller footprint, bundled inside `underscore` package
var reduce = require('underscore/reduce');
That is acceptable, but I'd argue the other way. Including them all in the same file then publishing them as separate modules requires cumbersome maintenance (just look at lodash's build to map functions to dependencies). If we separate functions into files, the |
What do you mean by this? If everything is in one file it really isn't especially expensive to parse everything. If they're split into 150 modules it has to do a synchronous require (with disk i/o) for each, which is slow.
That looks like a nightmare to maintain. Awesome that JDD is willing to devote his time to keep so many moving parts of lodash working, but I sure ain't. |
By the way — I know that it's a lot of work, and a daunting thing to contemplate ... but if anyone is real jazzed up and wants to start a new branch to explore a possible view of what a merge might look like code-wise — go for it. |
Sorry, that was meant to come after I argued for multiple files. |
One of the big wins of Lodash/Underscore merge of some kind is avoiding the duplication of effort and fragmentation. Lodash is already modular, has a build system in place, robust testing, and great code coverage. I think Lodash and Underscore have pretty established names and no shortage of strong opinions so a full merge may not be immediately feasible. However, there are lots of ways to start moving things in that direction. One such way is Underscore could punt on the methods it doesn't take issue with, like several of the isXyz methods, object iteration helpers, etc., and strip those out, opting to pull those methods in from lodash modules, e.g. |
Sure. Why bother building and publishing an interim FrankenScore that increases complexity in the short term? I don't see the point. I think it's more worth trying to imagine a unified "Underscore 2.0" that everyone can agree on, and working towards that goal... |
Because it plays to the key wins of merging; reducing fragmentation and duplication of effort.
It's relatively straightforward to spin up and would reduce the testing and support burden of Underscore. |
I'm with @jashkenas on this. I don't see consuming lodash as a win, since it'll impair search-ability. I now have to understand two separate codebases, figure out which one actually defines the method, etc. One of the original points:
I think this is a very important goal. And while lodash is well annotated, splitting code between two codebases defeats it.
Absolutely. |
The distributed source would have the sources combined so search-ability would still be doable. If code/doc style is an issue I'm flexible and willing to adjust to make the boundaries more blurred. |
All aboard 🚋! Moving to underdash. |
A purposefully locked thread to discuss merging Underscore and Lodash. Public discussion is still open in #2182.
@jashkenas, @braddunbar, @megawac, @akre54, and @michaelficarra, mind cross posting your comments so far?
Also, is @jdalton able to comment on this?
The text was updated successfully, but these errors were encountered: