Learn the MVVM pattern and knockout.js quickly with in-browser coding exercises(learn.knockoutjs.com)
learn.knockoutjs.com
Learn the MVVM pattern and knockout.js quickly with in-browser coding exercises
http://learn.knockoutjs.com/
5 comments
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.
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.
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).
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).
Could you explain what you mean in a little more detail? In particular does this problem still persist if you use JQuery templates?
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.
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.
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)
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)
"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.)
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.)
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.
(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.
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.
> 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.
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.
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.
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.
Oh, that kind of databinding. That doesn't really bear any relation to what knockout does :)
I see what you're saying. Yeah, one certainly needs to be careful with those sort of high-level abstractions. I remember when I first started learning WPF, I ran into the exact problem you described. I had a data grid bound to an sqlite database. Without optimization, every row update was making three of four calls to the database. When there were a few thousand records, the UI would screech to a halt.
I like Magic Boxes. They let me get stuff done quickly, and then I can go figure out how they work later.
To be fair, I used to hate them... Back before I started investigating how they worked. Now I'm only slightly uncomfortable with one I don't understand, and love ones that I do.
Bandwidth, and and its brother Responsiveness, are a concern, however. I didn't look into this, but it appeared that the data binding was done in-browser, and only saving the data resulting in bandwidth usage.
To be fair, I used to hate them... Back before I started investigating how they worked. Now I'm only slightly uncomfortable with one I don't understand, and love ones that I do.
Bandwidth, and and its brother Responsiveness, are a concern, however. I didn't look into this, but it appeared that the data binding was done in-browser, and only saving the data resulting in bandwidth usage.
No objection to your general comments, but just to clarify, knockout.js is a regular open source community project, not an MS product. Also, do try it - you might find this approach to binding to be much more compelling in a dynamic world (i.e., JavaScript).
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?
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?
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?
var viewModel = { firstName: ko.observable("Bert"), lastName: ko.observable("Bertington"), fullName: ko.dependentObservable(function() { return this.firstName() + " " + this.lastName(); }, this) };
not work?
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.
In other words, it could work, but would need the correct context instead of 'this'.
<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.