Composer.js

Framework comparison

Obviously, we’re going to be biased, but here’s a quick comparison between Composer and a few other projects.

Feature	Composer.js	Backbone.js
Supports modules	Yes	Yes
Dependencies	History.js	jQuery or Zepto, underscore.js
Ships with a generic class system	Yes	No
Provides hierarchical data relationships	Yes	As a module
Provides filtered collections	Yes	No
Provides controller <-> collection tracking	Yes	No
Provides AJAX API syncing out of the box	DIY	Yes
Allows granular silencing of specific events	Yes	No
Supports using promises for async operations	Yes, via ES6 (or compatible, like Bluebird)	Yes (via jQuery promises)
"View" or "Controller"?	Controller	View
Router supports named parameters	No (regex only)	Yes
Router provides automatic link binding	Yes	No
Comes with history management	Requires History.js	Requires jQuery
Supports event binding contexts	Yes, string-based	Yes, object-based
Provides Controller event inheritance	Yes	No
Controller DOM diffing/patching/batching	Yes with morphdom	As a module w/ Marionette/VDOM
Supports IE 6+	When using Mootools	No

This list is not exhaustive. For instance, the relational models that Composer and Backbone use are fairly different in the way they handle data (Backbone forces one-instance-many-locations, Composer favors many-instances). There are also utility functions in models/collections that one framework provides that the other doesn’t and vice versa.

The best way to get a good feeling for Composer’s abilities is to read the docs.