I can't get past this (let alone the why of another MV*) - Why sugar.js? 6731 lines of bloat. This is going to turn off a great number of developers out the gates.
Take Ember for example. Joosy is only 2-3kb more including Sugar. Compare the profit. One framework can not (and should never try to) address everything. Sugar beats Underscore without a hope (http://borisstaal.com/post/24270017179/please-use-sugar-js). And you just can't live without both, raw JS is too poor.
I'm obviously opinionated on this point (backbone/underscore user), it just seems like it comes with so much i wont ever user - and could easily add via a mixin on a per project basis (in a nice functional manor). I also can't get over extending the native prototypes. Dealing with too many moving parts in modern web apps to go and start extending things that weren't built that way - maybe in the ruby world it just feels better to have it on the prototype directly. I suppose im getting off topic tho.
This lib (joosy) was built to satisfy your particular set of needs, and it seems that it does so well. Cheers to that.
" it just seems like it comes with so much i wont ever user - and could easily add via a mixin on a per project basis"
You could easily add the simple helpers in underscore too, they're not complex, but the idea is you use a library so you can work at a higher level of abstraction. Why write your own array intersection method? Why write your own camelcase function? Sugar opens a lot of doors that are just a little much effort to normally be bothered with (and underscore does too, but to a lesser degree).
"…start extending things that weren't built that way?"
It's ok to extend the prototypes, so long as a) you own the objects and b) you only extend the prototypes from a single module (e.g. sugar). c) Don't extend Object.prototype (unless you're really brave). http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is...
The major risk is in collisions, and if you follow those rules you reduce the chance of this occurring to a minimum. If you're worried about for-loops, the way sugar handles extending the object prototype makes this a non-issue. http://sugarjs.com/native
