As someone who works on Backbone.js, the level of conversation in the blog post and this thread is a bit disheartening. Client-side libraries aren't just matrices of features to be checked off ... we're talking about the style in which you think about and work with the concepts that construct your user interface.

I'd tend to think that attempts to glom together Backbone.js and Knockout.js will produce something less than the sum of their parts.

Here's Knockout's documentation: http://knockoutjs.com/documentation/introduction.html

Most of Knockout's API deals with binding JavaScript objects to web forms. If all of your web app's UI is essentially a series of web forms, then great! You're all set. The Knockout examples demonstrate this ability: http://knockoutjs.com/examples/

However, if your UI starts to move in interesting directions beyond filling out a series of forms, then Knockout doesn't have much to offer you (see LargeWu's comments on this page).

On the other hand, Backbone's philosophy is that your UI is your business -- jQuery is already great at extracting data from forms and other elements in the DOM, and there are already a large number of wonderful templating libraries for rendering HTML from JS objects. Instead, it focuses on helping you model your data in the browser: providing events you can observe whenever a model changes state, adding essential functions like "map", "filter", "find", "groupBy" and "any" to collections of models, giving you simpler declarative bindings for DOM events in your views, so that you don't have to worry about whether a particular piece of HTML is visible on screen or not, and so on...

But really, the best proof of "UI wizardry" is in the pudding. If you haven't scrolled through it recently, I encourage you to check out some of the amazing apps built with Backbone over the past year: http://backbonejs.org/#examples

(with all due apologies for boosterism)