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.