[orthecreedence]

The reasoning was that at the time of building, Backbone was tied to jQuery, and I really don't like jQuery. So Composer was built on top of Moo (and used a lot of the built-ins, such as the class system) but the API stayed very close to Backbone.

As of v1.0, everything Moo-specific was ripped out, the class system was redone from scratch, and everything was modularized so different pieces of Composer could be used in different places, independent from each other.

For instance it's common practice for me to take just the class system or eventing objects from Composer into projects without importing all the other stuff.

[catshirt]

i'm confused by this. the reason for creating an entire framework is you didn't like the jQuery dependency?

replacing jQuery with MooTools in Backbone seems trivial, especially with respect to creating a whole new framework. you'd just need to override a small handful of methods.

all the other problems Composer solves that Backbone excludes (like filtered collections) are supplemented by other third party libraries. i'm not one of those "another framework?" guys- but it seems like you had a great opportunity to make the landscape more robust, instead of further segregating it.

[orthecreedence]

From what I remember at the time (keep in mind, this is ~3.5 years ago), backbone had a few issues (and bugs) that were making it difficult for us to use on an app we were building.

We could have spent a good amount of time forking, fixing them, hopefully getting a PR merged (if the changes were even in-line with the project), and on top of that creating an adapter to replace any sort of DOM manipulation with Moo, which I think back then was more then just overriding a handful of methods.

So, composer was born not just out of "jquery sucks, we're redoing this" but more "well, we could fix all the stuff that we don't like in backbone, or build something that suits our needs directly."

[krebby]

I admittedly haven't taken an in-depth look over the framework, but what specifically did you feel was missing from Backbone? Anything we can improve?

I don't find this list [0] to be particularly helpful. It looks like the main addition is filtered collections and relations, which there are many ways of doing [1] or pretty easily added via a plugin.

(And as an aside, Backbone absolutely does support IE6, and goes out of its way to maintain bc, particularly in History).

[0] http://lyonbros.github.io/composer.js/pages/comparison [1] http://backbonejs.org/#FAQ-nested

[catshirt]

gotchya. i don't mean to sound accusatory- i am just being selfish. there are bits and pieces of Composer that i'd like to see in Backbone proper. but, the thought of leaving Backbone for something a lot like Backbone is scary.

[orthecreedence]

You did not come off as accusatory, and these are good questions to ask. I also understand the hesitation in trying it out. Do keep it in mind though if you ever have a toy project and a few hours...you might like it!

[krebby]

Disclosure: I work on Backbone from time to time. In the next version of Backbone we're removing the jQuery dependency from Backbone.History and making it easier to separate out from Backbone.View.

Adding support for MooTools should be as simple as overriding Backbone.ajax and a few methods from Backbone.View. There exist at least one or two projects that do this already that I know of, though I've never had a use for them myself.

[orthecreedence]

Thanks for the update! The things that Composer needs jquery/moo for are all compartmentalized into one place (called the adapter)...sounds like you guys are moving in the same direction.

I wish backbone hadn't tied itself so closely to jquery early on because I really like the project and could have seen myself building a lot on top of it (like composer's filtercollections or listcontroller), and now it seems both projects are occupying closer and closer to the same space. Who knows, this may be good though.

[krebby]

To be sure, Backbone has had "adapters" for a pretty long time. You just replace Backbone.$ and be on your way (there's a few for mootools, etc if you look hard enough). The latest changes just make this a bit easier so you can use native DOM / xhr methods if that's your particular bag of awesome.