Martin Fowler, for example, has some articles on it.
But i don't really understand the difference. I have, in my applications a basic view that declares all GUI-elements, and special aspects of the GUI, like columns resizable or not in a table. Thats mostly for the designer to build everything out.
Now i write my domain models.
Then i go on and have a concrete view that inherits the formerly created view and sets up databinding, validation, actions etc. handled by the presentation model.
The presentation model is always connected to one specific domain model.
So now i have:
Abstract view (mostly for the designer)
^
|
View -> Presentation model -> Domain Model
Besides the presentation, there are validators etc. but all incorporated with the presentation.
Now i can test against the presentation, the domain or the concrete views.
Also, i can bind multiple presentation models against one view, or one presentation model against multiple views.
But i don't call that MV(VM) but MVP.
The levels of granularity are also different. With Knockout, any change to the data will update that atomic portion of the view. With Backbone, the default is to be much more coarsely grained. The good baseline approach for getting started is to simply re-render the view when the model changes:
model.bind("change", this.render);
And now, whenever any attribute in the model is updated, the view is redrawn. In most cases, that's all you ever need, but in performance critical cases, you can optimize by listening for changes to specific values, and updating just those portions of the view. model.bind("change:title", function(model, newTitle) {
titleEl.text(newTitle);
});
It's great to see different approaches to JS Apps start to surface. I wonder how much cross-pollination there's going to be... <span data-bind:"text: title"></span>
And Knockout allows you to put bindings in code too, where that makes sense. I also like the way Knockout keeps everything in the view model, rather than passing in the observable attributes when constructing an instance. For instance: var Sidebar = Backbone.Model.extend({
promptColor: function() {
var cssColor = prompt("Please enter a CSS color:");
this.set({color: cssColor});
}
});
Here color doesn't exist yet. I guess this is just standard javascript style? In Knockout (+coffeescript), I'd write: class SideBar
color: ko.observable('white')
promptColor: ->
@color(prompt('Please enter CSS color:'))
My model is self-contained. This example also shows the syntax for updating and getting values. I prefer Knockout's @color(cssColor)
to Backbone's@set({color: cssColor})
although this is minor and perhaps you want to allow for bulk updates.
I can't help but feel that these types of libraries are the future. I hope there is lots of cross-pollination going on. Sproutcore focuses on the 5 percent of webapps that should be desktop style. Both Knockout and Backbone give lots of the same benefits, but allow a more flexible application style.
My only wish is for a language agnostic persistence protocol, with some socket.io and REST protocols implemented for most frameworks/languages. Ideally, I could use this protocol to sync with my iPhone/Android/HTML5 app, without changing the server side. This could get very hairy (FeedSync/LiveMesh/Wave), but something simple that accomplishes 90% would be a great.
* Declarative binding syntax (a very simple way to link model properties/functions to DOM elements without writing manual "render" functions or event handlers) * Automatic dependency tracking (so you can have arbitrary nested chains of computed properties that combine multiple observables, and so KO can work out on its own exactly which part of your UI to refresh after any given model change).
The templating stuff is a bit more baked in with KO too. Backbone, on the other hand, does more of the JSON data access stuff natively, whereas KO assumes you'll use normal jQuery Ajax for that.
(Disclaimer: I don't know backbone.js well, and I created Knockout, so you may want to make your own comparison.)
From what it looks like Knockout is all about the views and templating. Seems like the killer feature is auto-updating views and its templating system.
Backbone does do some things with callbacks and handling changes to your models, but you would update the views yourself.
I'm disappointed to see JavaScript back in attributes though. Can the bindings be defined programmatically?
http://github.com/SteveSanderson/knockout/blob/master/src/bi...
Perhaps Steve can comment on how well this performs in real-world views with thousands of DOM elements...
It's so much more convenient to do it this way (avoiding having to figure out where each bit of behaviour comes from), especially when you're generating UI from within templates.
I've been massacring functions that manipulate multiple elements and instead am directly tying the behaviors to the underlying data. My future self is very pleased with me.
I actually find it better to use Backbone, jQuery and Knockout together instead of heavy and bloated libraries like ExtJs and Cappuccino. These three libraries provides the necessary functionalities to build a medium sized JavaScript application. You'll have to take care of the design yourself, though.
Backbone is the main platform. You'll use it for pretty much everything except one thing "templating". Knockout will fit well with templating. The example that is present in the home page is what I think of. This will help separate the two processes. I'll have two different files reducing the complexity of each one. jQuery is the rescue when dealing with other DOM issues, animation and also AJAX.
I'm not saying this is bad. Just that I'm not going to jump on this until a simpler option come around. I am also a mvc fan.
I did work on my own take, using some of the ideas from SproutCore, though didn't get very far in polish (http://github.com/erudites/eventful)
I've only had a brief look, but the dependency tracking looks much cleaner than other solutions I've seen for partial template redrawing.
Do Backbone and Knockout interact well, or are there conflicts in getting them to play nicely together?
Also, I really like the way that bindings are done.
data-bind="click: foo();"
is so much nicer than
$(':checked').each(function(bar){/* do foo; */}).bind(this);
or whatever it was I was doing in jQuery the other day. I'm probably mixing up my prototype and jquery syntax there. :)
It takes almost 4 seconds to load and delays the site's rendering. Making it load much quicker is really the goal here. Also, it's 3000 x 2227 pixels large.
MVVM promotes testing, while allowing developers to build simplistic and decoupled apps. I for one am pumped to have found this!
Example right on the homepage, clear communication what it does, great list of examples on the other pages - way to go! :)
It helps to that the example is super-simple and easy to understand.
"The data-bind attribute isn’t native to HTML, though it is perfectly OK (it’s strictly compliant in HTML 5, and causes no problems with HTML 4 even though a validator will point out that it’s an unrecognized attribute)."
That said, this looks like an interesting library and worth playing around with. I'm loving the huge amount of JS framework experimentation going on.
I'm excited to play around with this