7 ms·

Learn Knockout.js in 30 minutes

95 points by aymeric 15y ago

Codayus 15y ago
It's an incredible sales tool for the framework, I'll say that. I'm in the process of selecting a Javascript framework for a new project, and this makes selecting Knockout very compelling. It's hard to convince yourself you need to evaluate some other competing and (almost invariably) poorly documented framework when you've got this tutorial sitting there, just asking to be used...
bcjordan 15y ago
Loving the lot of javascript-backed in-browser programming tutorials launching lately. This one in particular has a nice UI and help overlay.
- instakill 15y ago
  Have you seen any for Backbone?
- seminal 15y ago
  My favorite is still Cows and Closures. http://nathansjslessons.appspot.com/lesson?id=1000 http://nathansjslessons.appspot.com/lesson?id=1000
  - andrewl-hn 15y ago
    Oh, thanks for sharing! It's brilliant! I'll definitely give it to developers new to JavaScript.
thedevelopment 15y ago
This is a top notch effort. As someone who has recently started looking at JS MVC frameworks, I've found there are a lot of options and not a huge amount of documentation or tutorials. When it comes to differentiating between frameworks, tutorials like this go a long way, and help the entire JS community. I look forward to other JS frameworks coming out with similar, and getting more opinionated about conventions.
- nchuhoai 15y ago
  i have to agree with that. It's really hard to keep up with all the JS frameworks and having tutorials like these definitely helps with the anxiety to delve into it. I wish there would be one for backbone, as it seems more popular
- gldalmaso 15y ago
  This is certainly true, specially when you work at a company that really doesn't invest enough research time in the choosing of a new framework as they should. You need to see the key features and a bit of hands-on trial fast to be able to showcase them even faster. Of course it's not an ideal method of picking new technology, but sometimes you can't really argue about it and have to go along.
dpres 15y ago
Been there done the Knockout.js thing... try Backbone.js instead: http://documentcloud.github.com/backbone/ http://documentcloud.github.com/backbone/ Not knocking Knockout.js ;) it's great for really small apps.
- apsurd 15y ago
  Have to agree here. backbone.js has a learning curve but imo backbone is based on more ideal design principles. For example the first lesson in this tutorial is telling you to bind data to the view _by manually editing a DOM node_. Whereas in backbone all your data exists in model objects as it should. Views get initialized/created by view objects, and the bindings are through events. So for the first example, in backbone, I'd use a mustache template to build my view, toss in the model object (obj.attributes) and bind the view rendering to the objects change event. Much more clear lines of responsibility imo. Thus Backbone.js is definitely advocating much better design principles.
  - vailripper 15y ago
    As an addition to this, the backbone model binding plugin is great for binding models to views. https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding
  - andrewl-hn 15y ago
    I wouldn't dismiss Knockout right away. 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-beta-available/ 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
jph 15y ago
Be sure to look at Knockout Model too - it provides similar capabilities to Backbone e.g. for things like REST/JSON APIs.
neebz 15y ago
My experience with Knockout has been great. I have used it on two major products. People are not really happy with the data binding stuff put directly into the markup but I always liked it because even in the big apps, I hardly had any binding which has been ugly. It's been pretty straightforward. There have been some edge cases but Steve has dealt with them in 1.3 version.
ez77 15y ago
Off-topic legalese: Does the "(c) knockoutjs.com" at the bottom have any legal value whatsoever? Generally one would expect a person or a company after the "(c)".
- freehunter 15y ago
  IANAL but from my understanding, copyright is implied by default. You don't have to apply for a copyright, you get it automatically when you create something. knockoutjs.com would be considered a group, and a representative from the group could be appointed for legal purposes.
bbrizzi 15y ago
The demo is pretty cool but I have a few questions: - Since all the templating is done on the client-side, isn't it bad for referencing? Note that this isn't specific to Knockout but to all javascript templating libraries in general. - data-bind seems to be an HTML5-only attribute. I guess this means Knockout documents require an HTML5 doctype. Can't this cause problems with older browsers, at least for validation? (The knockout website mentions compatibility with IE6+). Otherwise, it seems really fun and easy to use and feels pretty snappy. It probably won't replace server-side templating for me yet though.

95 points by aymeric 15y ago

It's an incredible sales tool for the framework, I'll say that. I'm in the process of selecting a Javascript framework for a new project, and this makes selecting Knockout very compelling. It's hard to convince yourself you need to evaluate some other competing and (almost invariably) poorly documented framework when you've got this tutorial sitting there, just asking to be used...

bcjordan 15y ago

Loving the lot of javascript-backed in-browser programming tutorials launching lately. This one in particular has a nice UI and help overlay.

instakill 15y ago
Have you seen any for Backbone?
seminal 15y ago
My favorite is still Cows and Closures. http://nathansjslessons.appspot.com/lesson?id=1000 http://nathansjslessons.appspot.com/lesson?id=1000
- andrewl-hn 15y ago
  Oh, thanks for sharing! It's brilliant! I'll definitely give it to developers new to JavaScript.

thedevelopment 15y ago

This is a top notch effort. As someone who has recently started looking at JS MVC frameworks, I've found there are a lot of options and not a huge amount of documentation or tutorials. When it comes to differentiating between frameworks, tutorials like this go a long way, and help the entire JS community. I look forward to other JS frameworks coming out with similar, and getting more opinionated about conventions.

nchuhoai 15y ago
i have to agree with that. It's really hard to keep up with all the JS frameworks and having tutorials like these definitely helps with the anxiety to delve into it. I wish there would be one for backbone, as it seems more popular
gldalmaso 15y ago
This is certainly true, specially when you work at a company that really doesn't invest enough research time in the choosing of a new framework as they should. You need to see the key features and a bit of hands-on trial fast to be able to showcase them even faster. Of course it's not an ideal method of picking new technology, but sometimes you can't really argue about it and have to go along.

dpres 15y ago

Been there done the Knockout.js thing... try Backbone.js instead: http://documentcloud.github.com/backbone/ http://documentcloud.github.com/backbone/ Not knocking Knockout.js ;) it's great for really small apps.

apsurd 15y ago
Have to agree here. backbone.js has a learning curve but imo backbone is based on more ideal design principles. For example the first lesson in this tutorial is telling you to bind data to the view _by manually editing a DOM node_. Whereas in backbone all your data exists in model objects as it should. Views get initialized/created by view objects, and the bindings are through events. So for the first example, in backbone, I'd use a mustache template to build my view, toss in the model object (obj.attributes) and bind the view rendering to the objects change event. Much more clear lines of responsibility imo. Thus Backbone.js is definitely advocating much better design principles.
- vailripper 15y ago
  As an addition to this, the backbone model binding plugin is great for binding models to views. https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding
- andrewl-hn 15y ago
  I wouldn't dismiss Knockout right away. 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-beta-available/ 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

jph 15y ago

Be sure to look at Knockout Model too - it provides similar capabilities to Backbone e.g. for things like REST/JSON APIs.

neebz 15y ago

My experience with Knockout has been great. I have used it on two major products. People are not really happy with the data binding stuff put directly into the markup but I always liked it because even in the big apps, I hardly had any binding which has been ugly. It's been pretty straightforward. There have been some edge cases but Steve has dealt with them in 1.3 version.

ez77 15y ago

Off-topic legalese: Does the "(c) knockoutjs.com" at the bottom have any legal value whatsoever? Generally one would expect a person or a company after the "(c)".

freehunter 15y ago
IANAL but from my understanding, copyright is implied by default. You don't have to apply for a copyright, you get it automatically when you create something. knockoutjs.com would be considered a group, and a representative from the group could be appointed for legal purposes.

bbrizzi 15y ago

The demo is pretty cool but I have a few questions: - Since all the templating is done on the client-side, isn't it bad for referencing? Note that this isn't specific to Knockout but to all javascript templating libraries in general. - data-bind seems to be an HTML5-only attribute. I guess this means Knockout documents require an HTML5 doctype. Can't this cause problems with older browsers, at least for validation? (The knockout website mentions compatibility with IE6+). Otherwise, it seems really fun and easy to use and feels pretty snappy. It probably won't replace server-side templating for me yet though.