Following Comparison from Steven Sanderson.
Disagreement: What’s flexible, what’s integrated.
Each technology has different levels of prescriptiveness:
|
Views
|
URL routing
|
Data storage
|
AngularJS
|
Built-in DOM-based templates (mandatory)
|
Built-in (optional)
|
Built-in system (optional)
|
Backbone
|
Choose your own (most used handlebars.js, a string-based template library)
|
Built-in (optional)
|
Built-in (overridable)
|
Batman
|
Built-in DOM-based templates (mandatory)
|
Built-in (mandatory)
|
Built-in system (mandatory)
|
CanJS
|
Built-in string-based templates (mandatory)
|
Built in (optional)
|
Built in (optional)
|
Ember
|
Built-in string-based templates (mandatory)
|
Built-in (mandatory)
|
Built-in (overridable)
|
Knockout
|
Built-in DOM-based templates (optional, can do string-based too)
|
Choose your own (most use sammy.js or history.js)
|
Choose your own (e.g., knockout.mapping or just $.ajax)
|
Meteor
|
Built-in string-based templates (mandatory)
|
Built-in (mandatory?)
|
Built-in (Mongo, mandatory)
|
Spine
|
Choose your own string-based templates
|
Built-in (optional)
|
Built-in (optional?)
|
As expected, whenever a library leaves a decision open, they argue it is better overall to guarantee composablity with arbitrary 3rd-party libraries. And the obvious counter-argument is that integration can be more seamless if built-in. Again, based on my conversations, the audience was split and opinions went in all directions — usually based on how much other technology stack an individual was wedded to.
Quote from Tom Dale of Ember: “We do a lot of magic, but it’s good magic, which means it decomposes into sane primitives.“
Another Comparison
The Contenders
Here is a table showing all of the frameworks support for the above features. Click through the title for more detail.
I am still not in a position of choosing any of them for my single page architecture applications whereas my sense with Angular.js.
will see.
cheers !!!
