5 ms·

Composer was built specifically as a Backbone.js replacement to support Mootools But why?

by Gyonka 12y ago

gfosco 12y ago
The next sentence has a link explaining the differences: http://lyonbros.github.io/composer.js/pages/comparison http://lyonbros.github.io/composer.js/pages/comparison Things Composer.js provides that are not in Backbone: Generic class system, filtered collections, controller-collection tracking, granular silencing of events, router-provided auto link binding, controller event inheritance.
orthecreedence 12y ago
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.
- krebby 12y ago
  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 12y ago
    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 12y ago
      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.
- catshirt 12y ago
  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 12y ago
    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."
    - catshirt 12y ago
      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 12y ago
        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 12y ago

Composer was built specifically as a Backbone.js replacement to support Mootools But why?

by Gyonka 12y ago

Composer was built specifically as a Backbone.js replacement to support Mootools But why?

The next sentence has a link explaining the differences: http://lyonbros.github.io/composer.js/pages/comparison http://lyonbros.github.io/composer.js/pages/comparison Things Composer.js provides that are not in Backbone: Generic class system, filtered collections, controller-collection tracking, granular silencing of events, router-provided auto link binding, controller event inheritance.

orthecreedence 12y ago

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.

krebby 12y ago
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 12y ago
  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 12y ago
    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.
catshirt 12y ago
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 12y ago
  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."
  - catshirt 12y ago
    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 12y ago
      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 12y ago