Skip to content
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

Closed
jridgewell opened this issue May 21, 2015 · 15 comments
Closed

Contributors: Underscore + Lodash #2184

jridgewell opened this issue May 21, 2015 · 15 comments

Comments

@jridgewell
Copy link
Collaborator

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?

Repository owner locked and limited conversation to collaborators May 21, 2015
@jashkenas
Copy link
Owner

Also, is @jdalton able to comment on this?

He sure is.

@jridgewell
Copy link
Collaborator Author

Well, to get the ball rolling:

Lodash is currently > 12k lines of code, and Underscore is 1.5k. I understand that part of that is JSDoc noise, but it still seems potentially problematic and worth talking about.

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

Documentation style. Ideally I'd like the Underscore docs to be written even more conversationally than they are at the moment.

I wouldn't be opposed. But, I think offering ample code samples in the source would be a huge plus.

Strict(er) SemVer. Totally fine with me. I'm still of the opinion that true believer SemVer isn't something that actually exists in the real world (most changes are subtly backwards-incompatible in minor ways), but I have no problem praying to this golden cow to keep the philistines happy ;)

👍 💯

"Governance Model": I don't think we need anything fancy here.

👍

I do think we'd need a clear mission statement about the spirit of what the library should be.

I agree. That should help immensely in deciding how we go about merging the codebases.

@akre54
Copy link
Collaborator

akre54 commented May 21, 2015

I think this is entirely solved by modularizing functions

This becomes a pain to manage. Do I have to require in each, map, pluck, every time I need it? How long does my package file's dependencies list become? What about the libraries I pull into my code? What if they use an incompatible version of each?

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 each packages out in the wild, all doing similar things under different packages, we've now got fragmentation and code duplication.

I think offering ample code samples in the source would be a huge plus

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.

Clear mission statement

Eh. This is always the first thing the corporate robots always want to see. What would this say, anyway?

Keep JS weird!!

@michaelficarra
Copy link
Collaborator

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.

@jashkenas
Copy link
Owner

I think this is entirely solved my modularizing methods.

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.

@jridgewell
Copy link
Collaborator Author

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.

Undoubtably. But, we can offer the best of both worlds (as lodash already does) even when you only install the underscore package.

// Slow, since it loads up **everything**
var _ = require('underscore');

// Faster, smaller footprint, bundled inside `underscore` package
var reduce = require('underscore/reduce');

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.

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 required dependencies are easily parseable.

@akre54
Copy link
Collaborator

akre54 commented May 21, 2015

Slow, since it loads up everything

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.

just look at lodash's build to map functions to dependencies

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.

@jashkenas
Copy link
Owner

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.

@jridgewell
Copy link
Collaborator Author

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 for each, which is slow.

Sorry, that was meant to come after I argued for multiple files.

@jdalton
Copy link
Contributor

jdalton commented May 22, 2015

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. _.isArray = require('lodash/lang/isArray'), instead and build them in on publish/dist. This would allow Underscore to offload methods, keep its source simple, and share implementation and testing with Lodash. It also gives Underscore the freedom to adopt as little or as much as wanted, easing into merging without being locked-in. Thoughts?

@jashkenas
Copy link
Owner

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. _.isArray = require('lodash/lang/isArray'), instead and build them in on publish/dist. This would allow Underscore to offload methods, keep its source simple, and share implementation and testing with Lodash. It also gives Underscore the freedom to adopt as little or as much as wanted, easing into merging without being locked-in. Thoughts?

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...

@jdalton
Copy link
Contributor

jdalton commented May 22, 2015

Why bother building and publishing an interim FrankenScore

Because it plays to the key wins of merging; reducing fragmentation and duplication of effort.

that increases complexity in the short term?

It's relatively straightforward to spin up and would reduce the testing and support burden of Underscore.

@jridgewell
Copy link
Collaborator Author

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 instead and build them in on publish/dist.

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:

@jashkenas: We should keep nicely annotated source code as a priority.

I think this is a very important goal. And while lodash is well annotated, splitting code between two codebases defeats it.

I think it's more worth trying to imagine a unified "Underscore 2.0" that everyone can agree on, and working towards that goal...

Absolutely.

@jdalton
Copy link
Contributor

jdalton commented May 22, 2015

@jridgewell

I'm with @jashkenas on this. I don't see consuming lodash as a win, since it'll impair search-ability.

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.

@jdalton
Copy link
Contributor

jdalton commented Jun 4, 2015

All aboard 🚋! Moving to underdash.

@jdalton jdalton closed this as completed Jun 4, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants