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)
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.)
(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.
<div>You've clicked <span data-bind="text: numberOfClicks"> </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.
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.
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).
var viewModel = { firstName: ko.observable("Bert"), lastName: ko.observable("Bertington"), fullName: ko.dependentObservable(function() { return this.firstName() + " " + this.lastName(); }, this) };
not work?
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.
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?
