Composer.js: a framework for building complex single-page applications | Hacker News Reader

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

lyonbros.github.io

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

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 =].

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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.

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!

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

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.

Funny, ICantReadThisCamelCaseStuffNearlyAsEasily as_I_can_read_stuff_with_underscores.

icanreadstufflikethis without a problem.

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!

M-x glasses-mode

:bufdo :GoodOne!!!111

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.

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 ;-).

IOnTheOtherHandCan.

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

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

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

Reply on news.ycombinator.com