Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

End Goal #6

Closed
jridgewell opened this issue Jun 5, 2015 · 4 comments
Closed

End Goal #6

jridgewell opened this issue Jun 5, 2015 · 4 comments
Labels

Comments

@jridgewell
Copy link
Contributor

Just an issue to discuss the end goal of underdash. I'm trying to compile the discussions we've had.

@megawac: I would love to see a base platform which both underscore and lodash use.

@jashkenas: To be clear, I'm hoping that instead of fragmentation, "Underdash 1.0" would be both "Lodash 4.0" and "Underscore 2.0". Otherwise, there's much less of a point.

@megawac: I think this is a good long term goal, but I expect for the merge to succeed we should start smaller. Both underscore and lodash have prominent identities in the JS community and currently have some ideological differences.
I see the starting point for this as making underdash the place to implement a core API for both libraries to share, and then have both libraries import (whether CJS/compilation/etc) the implementation herein this repo. Anyway, this conversation should probably moved to another thread


@paulfalgout: It looks as if the first pre-draft-way-too-early-to-comment of the core underscore won’t be enough to support backbone. not sure if that’s a valid concern, but I’ve always considered the underscore-compat build of lodash to be “the one I need for Bb” Hopefully there will still be some sort of easy out of the box build for that..

@megawac: based on my understanding not supposed to encompass both libraries but a common dependency for strictly core functionality


@jridgewell (hey, that's me!):

To be clear, I'm hoping that instead of fragmentation, "Underdash 1.0" would be both "Lodash 4.0" and "Underscore 2.0”.

@jridgewell: I’m not sure Jeremy is aiming for that.

Heck ya! I think we can work together on a common core. My angle has always been about reducing fragmentation, testing cost, and maintenance overhead.

@jridgewell: Seems JDD is ok with that goal too.
@jridgewell: Being, the non “core” methods would still be in Underdash, but they wouldn’t be part of the normal build.

@megawac: Yeah, I agree more with JDDs goal here

@jridgewell:

As an exercise to the repo collaborators, let's see what it would look like to pull in all of the good stuff from underscore-contrib as well — the more useful of them going in "More" and the more esoteric going in a new third-level "Contrib" section.

@jridgewell: I actually like Jeremey’s idea here. If we can unite all of this under one roof, with the “core” being the normal build. Then “monolithic” being the kitchen sink. Or, just install @underdash/each if you only need each.

@jdalton: I think Jeremy's goal is great as a long term goal, but I think focusing on the small core that each can consume is a bigger win. Smaller core, less to agree on, and we can begin sharing the code base.

@megawac
Copy link
Contributor

megawac commented Jun 5, 2015

An extension of this thread is road mapping how we will get to the end goal.

Just to be clear, I think merging the projects would be an ideal end goal but not attainable right away.

I think it'd be best to identify core functionality, as we've been doing; then to start with underscore@2 and lodash@4 depending on underdash@1. We can then continue the transition by discussing and merging shared functionality through this repository.

@jashkenas
Copy link
Contributor

Just to be clear, I think merging the projects would be an ideal end goal but not attainable right away.

If it's an attainable, ideal end goal ... then why not do it?

Older versions of Underscore and Lodash continue to exist — they don't go anywhere. And more backwards compatible Underscore-old-API and Lodash-old-API implemented with Underdash can be provided as well.

But it seems very silly to promote and publish "halfway" versions of a merge. That just gives you five options: Underscore, Lodash, Underscore-flavored-Underdash, Lodash-flavored-Underdash, and proper Underdash.

Yes, it might take a little bit of time to get this sorted out — but if it's worth doing, it's worth doing right.

@jdalton
Copy link
Contributor

jdalton commented Jun 5, 2015

Yes, it might take a little bit of time to get this sorted out — but if it's worth doing, it's worth doing right.

From the Lodash side of things the Underdash goal (small core + more + modules) is doable in very little time since Lodash is already modularized and has build automation in place. We basically just need the list of methods to include as "core" and can wip out a 4.0 release in a weekend. With it being so easy to do for Lodash and an almost overwhelming amount of work for Underscore I'm not sure if it meshes for Underscore to go down that route. Underscore still has a very hand crafted feel, e.g. hand maintained docs, which is suitable for small projects but doesn't scale well. Adding modules to the mix, and various builds, is yet another thing to manage and would require more automation and a more active role/participation in the project than the current Underscore maintainer level. This is why a small core may be something more suited to the Underscore-way and something everyone can get behind.

@megawac megawac mentioned this issue Jun 5, 2015
@jdalton
Copy link
Contributor

jdalton commented Feb 13, 2016

Closed by #14.

@jdalton jdalton closed this as completed Feb 13, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

4 participants