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 NoThis 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4