Both Knockout.js and Backbone.js have their strengths and weaknesses, but together they are amazing! With Knockback.js, you can use the strong ORM provided by Backbone and create dynamic views using Knockout bindings.
- Knockout.js' bindings and automagical update
- Backbone's sleek Model definition
- Dynamic collection sorting
- Two-way string formatting
Knockback requires Knockout.js and Backbone.js (and therefore Underscore.js) to be already loaded on the page:
Download Latest 0.19.4
|Bullet-proof ORM||☚||Weak ORM|
|Built-in Serialization / Deserialization||☚||Manual serialization||1|
|Low level DOM maninulation||☛||Reduced jQuery effort|
|Manual view updating||☛||
|Routing and history support||☚||No routing||2|
|Blurred separation between:
Views | Controllers
|Proper separation between:
Models | Views | Controllers (ViewModels)
|Blurred separation between:
Models | Controllers (ViewModels)
|Cross-view Model state synchronization|
|Messy collection/view updating||Fully sorted and updated collection views|
|View settings and control properties||4|
As you probably know, Backbone is known to have a fantastic syncing system built
as close as possible to the RESTful pattern. And if this is not good for your
application you can always opt to build a custom
Backbone.sync or, if further
granularity is required, you can customize a Model/Collection's own
Knockout.js instead does not provide such a feature, and what it offers is a simple plugin to map into/from any JSON source.
Knockback uses Backbone's models and collections, and this means that all the serialization features we all love are still there!
In Knockback, while using Knockout.js ViewModel pattern, we developed a full pattern that supports Backbone's routing solution.
(Im)proper use of tools
Too often, in a large Backbone application you find yourself building up views with too much logic in them, almost always requiring sub-state management. This is actually an improper use of views, which should be as logic-less as possible.
But you have to do things like that, and Backbone doesn't help the developer solving this (ethical?) issue.
In Knockout.js, this is not a problem, because ViewModels differ from Views exactly in this: they own states, methods and properties allowing the views to be logic-less.
So Knockout solves the blurry View/Controller issue you'll find building large applications with Backbone. But because Knockout simply provides ViewModels and no Models, how can you build a proper MVC/MVVM? Backbone to the rescue!
And the circle is complete: Models from Backbone, and Views/ViewModels from Knockout.js.
Following MVVM principles where a ViewModel is the "View's Model", and therefore owns its own properties and methods which are then reflected in the View itself, Knockback ViewModels can add View setting and control properties, which are not (and should not be!) owned by the model.
What does this allow? Actual settings (eg colors for different priorities in a task list) to be applied on all the associated ViewModels, or...something more interesting, like an design pattern for localization.
If you consider localized labels as observed properties, then you can understand how Knockback provides internationalization to your applications.