Dependencies

Knockback requires Knockout.js and Backbone.js (and therefore Underscore.js) to be already loaded on the page:

Optional dependencies:

Features

  • Localization
  • Knockout.js' bindings and automagical update
  • Backbone's sleek Model definition
  • Dynamic collection sorting
  • Two-way string formatting

Latest 0.15.3

Please look at the release and upgrade notes if you are migrating from an earlier version.

Source

You can find the source on Github. To provide feedback leave a message or create an issue.

Backbone.jsKnockback.jsKnockout.js!
Bullet-proof ORMWeak ORM
Built-in Serialization / DeserializationManual serialization1
MVCMVVM
Low level DOM maninulationReduced jQuery effort
Manual view updatingdata-bind based sorcery
Routing and history supportNo routing2
Blurred separation between:
Views | Controllers
Proper separation between:
Models | Views | Controllers (ViewModels)
Blurred separation between:
Models | Controllers (ViewModels)
3
Cross-view Model state synchronization
Messy collection/view updatingFully sorted and updated collection views
View settings and control properties4
Localization

Notes

Serialization

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 sync function.

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!

Routing

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.

Views' settings

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.