Composer.js: a framework for building complex single-page applications

http://lyonbros.github.io/composer.js/

by orthecreedence • 11 years ago

50 28 11 years ago

lyonbros.github.io

Gyonka• 11 years ago

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

But why?

gfosco• 11 years ago

The next sentence has a link explaining the differences: 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.

orthecreedence9• 11 years 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.

krebby3• 11 years 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.

catshirt2• 11 years 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.

allendoerfer2• 11 years ago

Some features seem interesting. Most of it is easy to implement in Backbone, too, but it is a nice benefit to have everything organized together.

The coding style is a bit off putting though. Why did you use underscores and Kernel-style, especially with the backbone-compatible API, where you use CamelCase?

It is irrational, but this lets me hesitate to dig deeper.

jacquesm• 11 years ago

Funny, ICantReadThisCamelCaseStuffNearlyAsEasily as_I_can_read_stuff_with_underscores.

yannis• 11 years ago

icanreadstufflikethis without a problem.

orthecreedence9• 11 years ago

Yeah this is mainly the reason. I have a lot of trouble both reading and typing camel case. I know a lot of the JS world prefers camelCase but_I_really_can't_stand_it!

raziel2p• 11 years ago

I think the point is consistency (not just of your own codebase, but also the APIs you extend) rather than what is easier on the eye or on the fingers.

coldtea• 11 years ago

IOnTheOtherHandCan.

jafaku• 11 years ago

I would pick a different name. The dependency manager everyone in PHP uses has the same name: https://getcomposer.org/

It will be a pain to google anything about your project. Take a look at stackoverflow: https://stackoverflow.com/search?q=composer

orthecreedence9• 11 years ago

You may be right, but the projects both started around the same time (mid-late 2011) and I think two projects in different languages that do separate things sharing the same base name isn't a big deal, at least not as bad as having a language called "go" ...which seems to do just fine anyway =].

MAGZine• 11 years ago

nobody is stopping you from using it, i think the argument being made isn't that "they had it first," but that a lot of materials are going to conflict with the already-established PHP Composer, and that it presents a possible confusion for your (potential) users.

I'd rename it if it were my project. And "go" is pretty bad, but it's clear that if you're looking for specific resources, 'golang' is the appropriate tag/search term.

theOnliest• 11 years ago

At the very least, I'd change the <title> of the home page to remove some ambiguity. Right now it says "Get Composer | Composer.js", and the URL for the PHP composer is getcomposer.org.

orthecreedence9• 11 years ago

Not a bad idea, I'm fine with this change.

lurchpop• 11 years ago

I really don't like the long concatenated HTML strings embedded in the scripting code. Is there a way to do templating here?

rubbingalcohol• 11 years ago

I use composer.js + underscore for templating all the time.

orthecreedence9• 11 years ago

Of course, you can use any templating option you like. Raw HTML was used in the examples because we don't want people getting confused by thinking that Composer makes this choice for you.

You can use Handlebars, Mustache, underscore, etc etc. Just take the output of your templating engine and pass it into `Controller.html()`.

Composer.js: a framework for building complex single-page applications

Related Stories