End Goal #6
Comments
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 |
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. |
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. |
Closed by #14. |
Just an issue to discuss the end goal of underdash. I'm trying to compile the discussions we've had.
The text was updated successfully, but these errors were encountered: