
Learn the MVVM pattern and knockout.js quickly with in-browser coding exercises - stevensanderson
http://learn.knockoutjs.com/
======
Pewpewarrows
Props to the developers for making a nice in-browser tutorial. That said,
commenting on knockout.js itself, seeing code like this in HTML makes me want
to throw-up:

<div>You've clicked <span data-bind="text: numberOfClicks">&nbsp;</span>
times</div>

<button data-bind="click: registerClick, enable:
!hasClickedTooManyTimes()">Click me</button>

<div data-bind="visible: hasClickedTooManyTimes"> That's too many clicks!
Please stop before you wear out your fingers. <button data-bind="click:
function() { numberOfClicks(0) }">Reset clicks</button> </div>

I see this as being barely different than inline javascript with a few
abstractions, which we as a community have agreed upon to be an awful
practice.

~~~
sambeau
I don't agree.

The argument that has gone on in the web community over the past 10 years or
more has been about the separation of style and content. Adding inline
javascript was no better than adding inline styles. Thus CSS gave us styling
without changing content; jQuery gave us dynamic content without affecting
content.

However, both require linking a tag property to the CSS or Javascript. Classes
and IDs normally (although thus relationship has become more sophisticated
over the years).

Dynamic data (XMLHttpRequest/Ajax etc) has caused problems with this pattern.
The content and the structure of the data does not now have to live in the
page structure. In fact many people completely dynamically generate the page
structure along with the data.

Adding a data-bind property to tags in some ways repairs this pattern.

I agree that binding events to the tags at the same time is controversial.
However, I am reasonably unfazed by it. It has to go somewhere and I'm not
sure that the class definition is the right place either.

I rationalise this opinion like this:

In a dynamic web page we have: Data, Structure, Style, Behaviour.

We have agreed that data goes into structure if possible (when it is static)
and that style and content need to be kept apart. But dynamic data often
creates or modifies structure through behaviours. Where else should these
behaviours go?

When you have dynamic data you often have holes in your structure that are
filled or modified by behaviour. Showing the binding of the behaviour to the
structure in the HTML, and the binding of the behaviour to the data in the
Javascript seems like the best-worse case to me. The hole in your structure
where your data will go has a clear marker showing you what will go there and
when it will go there. Conversely when you look at the data definitions in the
javascript it is instantly clear which data will be dynamically added to the
structure of the page.

Personally I like it. It seems so much simpler to me than the other systems
that try to solve this.

It also neatly dovetails with jQuery templates & animations.

~~~
Pewpewarrows
The chief problem with this (that Knockout still hasn't solved to this day
that I know of) is progressive enhancement. Time and time again I try Knockout
but I can never get it to progressively enhance based on existing data on the
page, because of how overly declarative it is within the HTML elements
themselves.

I don't want to go so far as to say that it can't be done, but it's certainly
not nearly as easy as my front-end framework of choice right now (Backbone).
That's pretty much a deal-breaker right there, and should be for most people
wanting to design accessible web applications (which should be nearly
everyone).

~~~
sambeau
Could you explain what you mean in a little more detail? In particular does
this problem still persist if you use JQuery templates?

------
headbiznatch
After my experience developing a Silverlight client with Prism over the last
couple of years, I believe the MVVM pattern is a totally valid abstraction for
separating business logic and presentation. Coding against objects that can be
wired up to a view is very TDD friendly and easy to read. But more
interestingly, I think it might end up being an elegant way to be
platform/language future-proof if you decide you need a new version of the
client.

I am going to put that to the test in our company, actually. I want to make a
more ubiquitous version of our app (one that needs no plug-in) and I see a
nice path from our existing MVVM Silverlight to MVVM Javascript and HTML5. I
am really excited to translate our View Models and logic layer, implement the
bindings with something like Knockout and see just how much I can re-use, and
how quickly.

If you or anyone you know loves Silverlight and MVVM and wants to help me move
a Prism app into Javascript/HTML5, we are hiring. We are in the East Bay and
we are cool. IMHO.

------
TomOfTTB
As a Microsoft Developer and someone who has been fairly enamored with
Silverlight I have to say I've always been weary of the MVVM model. It's a
model built to fit a technology rather than the other way around and it shows.

Though I admit my assessment is harsh I've always thought of it as a model
designed to justify sloppy coding tricks (such as Data Binding)

So while I admire the work they put into Knockout.JS it seems like it's
designed to carry a flawed model into the Javascript world (as Microsoft is
seemingly abandoning Silverlight/WPF)

~~~
wccrawford
"Wary", not "weary".

I'm not sure that I agree that data binding is a 'sloppy coding trick'. It's a
time-saver. It enables what you were going to do anyhow, but with a lot less
code. (And hopefully a lot clearer.)

~~~
TomOfTTB
I actually meant weary as in "tired" so there!

(Just kidding, I was totally wrong on that. Thanks for the correction)

As far as data binding there are two reasons I consider it sloppy...

1\. It's magic box coding (as in I put these simple commands in and the
environment just handles it for me and I have little idea how)

2\. It (by Microsoft's admission) hogs bandwidth. In the desktop world that
wasn't a problem but in web applications its a big one.

Which is basically my point. Data binding was a desktop application technique
that Microsoft carried over into Web Forms and which is now trying to make its
way into MVC. But it's not technology built with the web in mind and designing
a new model around it doesn't change that.

I will take Mr. Sanderson's advice in the other reply here and try the thing
out but for the reasons above I don't see myself adopting it.

~~~
ncarlson
I can't endorse KnockoutJS because I've never used it. However, I'd like to
address the two points you made.

> 1\. It's magic box coding (as in I put these simple commands in and the
> environment just handles it for me and I have little idea how)

Is this not abstraction? I'm not familiar with the internals of the Python
interpreter, but I'm able to be productive and creative with it.

> 2\. It (by Microsoft's admission) hogs bandwidth. In the desktop world that
> wasn't a problem but in web applications its a big one.

I'm not convinced that this is a problem outside of edge-case scenarios.
However, from my understanding, this limitation is overcome in two ways: 1\.
Large application are broken up into small modules which can be loaded lazily.
2\. Time. The average bandwidth of an internet user increases exponentially
over time.

~~~
TomOfTTB
I'm not sure I know what you're talking about. I was talking about Data
Binding in the context of Microsoft technology. So, for example, when you want
a grid to reflect an entire database table you can define the table and this
with two lines of code (grid.datasource = table and then grid.databind()) the
grid will reflect the table. It takes care of all the hard stuff as far as
pagination, sorting columns, and even updating and deleting are taken care of
automatically.

It is a really quick and easy way to do things (and I don't question how
amazing it is in its depth of ability). But it creates almost constant chatter
as the grid is reflecting all changes off the database.

~~~
kenjackson
I'm sure there must be a template for this where you can see pretty intimately
how it works and completely change it. In WPF land they're lookless controls.
The databinding gives you a local copy of an object that is updated (via
things like INotifyPropertyChanged) and then templates render it. There's no
magic. Just a lot less code to write.

------
bialecki
Web based tutorials for learning programming languages and frameworks seems
like the future. As much as I love O'Reilly books, you can't beat having the
material/instructions and IDE in the same place.

Works really well for browser technologies (JS/HTML/CSS), quess the question
is how do you do this for non browser technologies? Are there are web based
interpreters for Python/Ruby/etc?

------
pmr_
I'm a JS noob. Can someone explain to me why I have to add the fullName
(ko.dependentObservable) after the declaration of the viewModel object? So,
why does this:

var viewModel = { firstName: ko.observable("Bert"), lastName:
ko.observable("Bertington"), fullName: ko.dependentObservable(function() {
return this.firstName() + " " + this.lastName(); }, this) };

not work?

~~~
bialecki
Because "this" as the second argument to the ko.dependentObservable doesn't
refer to the viewModel object (it's still being declared), it refers to
whatever the current context is. To check it, console.log or alert "this"
inside the function and see what it's value is.

~~~
wccrawford
In other words, it could work, but would need the correct context instead of
'this'.

