

Composer.js: a framework for building complex single-page applications - orthecreedence
http://lyonbros.github.io/composer.js/

======
jafaku
I would pick a different name. The dependency manager everyone in PHP uses has
the same name: [https://getcomposer.org/](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](https://stackoverflow.com/search?q=composer)

~~~
theOnliest
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.

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

------
Gyonka
_Composer was built specifically as a Backbone.js replacement to support
Mootools_

But why?

~~~
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."

~~~
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!

------
allendoerfer
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
Funny, ICantReadThisCamelCaseStuffNearlyAsEasily
as_I_can_read_stuff_with_underscores.

~~~
raziel2p
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.

~~~
allendoerfer
Exactly. It drives me nuts, when I see CamelCase in Python (except in
classnames) or underscores in JavaScript. Designing JSON data for REST APIs is
stressful for me every time ;-).

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

~~~
orthecreedence
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()`.

