Learn Knockout.js in 30 minutes

Under the hood those data-bind attributes use the same event model as Backbone views. However unlike Backbone KO doesn't force you to write this event propagation code manually. In KO all I have to do is to declare what property of viewModel I'd like to show up without actually telling about the machinery. This helps quite a bit to reduce code bloat while still giving you all the possibilities of event model. For example one can attach more event listeners to any observable value.

In that 1st example tutorial the author shows bindings directly in HTML because that helps him keep sample code small and demonstrate bindings. Bindings are NOT the major feature of the framework - observables and dependency detection are. However bindings are perfect for demo as they tend to impress the newcomers quickly. They are visually appealing, too. A newcomer sees how little does it take to convert a static markup into a complete dynamic example and is more likely to continue with the tutorial and later try the framework out.

Also note that KO has build-in templates so no one actually forces you to put bindings inside your static (or server-side generated) html. But in general if you don't like having your markup annotated you can get away with pure-js bindings. No one actually stops you from that! The code is a bit more verbose in that case but still comparable to other frameworks.

However I would personally ague in favor if bind declarations inside your markup. Especially in templates that are usually belong to separated visual components or blocks. In practice even though you can put arbitrary JavaScript code inside data-bind values you always gonna have the simplest binding declarations possible: anything bigger than `visible: showItem` would seem unnatural and ugly. So you would define a `dependentObservable` for any computable values or complex conditionals instead. And that's a good thing: code should belong to JS, not HTML. But I would ague that binding declarations are about the same thing as DOM ids and classes: just a list of parameters that help rendering the DOM node correctly. It's not the code.

One thing that Knockout doesn't currently do that Backbone does is helping you structure your application. There are no `Models` in the framework by default although there's a plugin which does fine job. But KO doesn't make structuring you app harder either.

I particularly want to emphasize is that your `ViewModel` is NOT a model and it's not a kitchen sink. I see quite a lot of people who start working with Knockout put all the bindings, all the data, and all the methods into one single gargantuan object. That's not the way things should be organized! It's pretty easy to keep all your entities decoupled and separated. Knockout even has a mechanism to narrow binding context from the parent model to submodels (and access parent model if needed). So, for example, inside your user profile page one can have separate `ViewModel` objects for personal info, contact info, friends list and so on. So, modularity is not forbidden. It's still doable and Knockout doesn't make it hard.

I would ague that writing large structured modular applications is easier with an MVP framework. And it matters very little which framework one has chosen as long as there's one.

One last note: this learning tutorial is focused on current release (1.2.1). The upcoming 1.3 release is very stable and brings some nice little features that make most stuff that I talked about more prominently represented in the framework, more concise and prettier http://blog.stevensanderson.com/2011/08/31/knockout-1-3-0-be...

I'd particularly like to point you to:

- control-flow bindings (that let you keep most templates inlined)

- 'with' binding and bind context switching (helps with sub-viewmodels that I talked about)

- binding providers (helps you keep your HTML data-bind-free)

[EDIT]: formatting