I just rolled out Tekpub’s latest drop for the MVC 3 series: BackboneJS with MVC 3, and a lot of people are curious why I didn’t use Knockout. So here ya go - my thoughts on the two.
http://www.pimpartworks.com/artwork/gmayhew/dance-off
They Don’t Do The Same Thing
It’s important to realize straight away that Knockout’s focus is different than Backbone. You can do the same things with Knockout that you can with Backbone - and vise-versa - but all they definitely are not two of the same framework.
Knockout
Knockout’s focus is two-way binding. You bind a DOM element to something on your ViewModel to orchestrate a behavior.
For instance - I might have a ViewModel called “Product”:
var viewModel = {
name : ko.observable("Default Name"),
price : ko.observable(0)
}
ko.applyBindings();
This is declaring that I want to use this viewModel and its settings to orchestrate some stuff on my page. To do that, I wire up events on those elements:
Product Name: < input type='text' data-bind = 'value : name'/>
Price :
When “ko.applyBindings()” goes off, it scours the page and pulls out the data-bind attributes, and then figures out what to do with those elements. If I have more complicated stuff, I can extend the viewModel with custom methods or constructors to handle what it is I need to do.
Of course this is the simplest of the simple in terms of examples - however it’s the core of what Knockout does: you explicitly declare a viewModel and its behaviors, then bind that to the DOM elements.
Pros
It’s very easy to get started (for the most part) and the tutorials/demos are amazing. The community is alive and vibrant and Steve Sanderson is an amazingly bright guy.
There’s a video where he demos the creation of a simple UI that is mind-blowing - you should really watch it.
The amount of “instrumentation” you can do on a page, right off the bat, is rather stunning - and it’s all powered by jQuery and jQuery templates so you can keep the custom functions to a minimum.
Cons
It can get messy, quick. I’ll start off with a personal bias: I can’t stand seeing code markup in attributes. It’s confusing, to say the least, and leads people who don’t know JS very well to do some really weird stuff.
The best way to see this is to take a stroll through the StackOverflow tag and see what people are doing with the framework. Some are … very interesting.
This isn’t Knockout’s fault - however it’s sort of a trap that’s easy to fall into when you’re trying to get work done and the mechanism for instrumenting your UI is right there, in the attribute. Seeing this kind of thing is all too common (this is from an answer):
I sent Steve an email (as well as Ryan Niemeyer, a very active community member) and they assured me that this isn’t what you’re supposed to be doing (I’ll also be reflecting on Backbone cruft in a bit… hang tight).
But time and time again - on blogs and in StackOverflow - the examples just looked … hideous.
I asked Ryan in particular if he could show me a complex example - a master/detail page with wired up links that showed an editor - and he did just that. It’s a really neat example and works really well.
In truth, if you compared the amount of code in Ryan’s example with that of a Backbone app - it would be the same. My problem is that I can’t follow it at all - I have to jump between the HTML and Script file to figure out what clicking a button does and, again, this is a personal bias and I’m well aware of it.
This part’s not a bias: most of the time spent learning a thing means Googling for answers - usually for specific problems or just some overall “guidance” in terms of making sure you’re doing it right. I can’t find anything like that for Knockout.
In fact the more I tried to use it for the latest MVC 3 episode, the more confused I became. I began to think that I *did* need to write the stuff I saw on StackOverflow - and it turned me off.
Redundancy. If you go through the demos you’ll quickly notice that your ViewModel begins to look a lot like your real model, real quick. You have to explicitly declare your ViewModel’s properties (unless you use the mapping plugin) and if you have need for more than one model on a page it can get complex rather quickly.
Data. This is left entirely up to you - the fetching and sending of data. It’s understandable why - everyone has their own ways of doing things. It would be nice if the team just picked one and went with it - allowing you to override if needed.
One person has created a plugin (thelinuxlich) that you can use to have some “data awareness”, although I haven’t tried it.
Summary
The Cons section is a lot bigger than the Pros section - but that’s because I like to add as much detail as I can if I’m going to be critical. I like Knockout, in general, and I’m sure that if you’re a Knockout fan you’ll have some corrections for me. Just do me a favor and add some details - I’ll edit this post as needed.
Backbone
Backbone’s focus is different than Knockout in that it gives you a “harness” with which you wire up your events and data. It’s referred to as an “MVC” javascript framework and I suppose that applies a bit… but don’t be distracted by trying to figure out which is M, V, and C.
I’ll also say this up front: it’s not easy. Not in the least and there’s a heavy learning curve. Once you get it, however, it clicks and you find that as you climb the complexity curve, Backbone stays there with you.
Pros
The creator, Jeremy Ashkenas, is quite active in the community - he’s the creator of CoffeeScript and is a rather smart dude. The Community, like Backbone, is very very active and it’s not difficult to find answers to problems.
Using the StackOverflow test, once again, you’ll not only find very detailed answers - but often you’ll find people suggesting better ways to write the thing the OP is asking about.
It didn’t take me long to figure out a few key things I was missing - and about 3 different times I realized I was doing things completely wrong. I realized this based on SO answers as well as reading the docs and examples. In short: Backbone pushes you to do “the right thing” with respect to javascript.
Data-Ready. Backbone comes with constructs that are ready to go in terms of pushing and pulling data to and from the server (the Collection):
Product = Backbone.Model.extend({});
Products = Backbone.Collection.extend({
model: Product,
url: "/products"
});
products = new Products();
products.fetch();
var myProductData = products.toJSON();
Validations. There is a simple to use validations framework that you can use if you don’t have one you’re already using:
Product = Backbone.Model.extend({
validate : function(atts){
if("Name" in atts && _.isEmpty(atts.Name)){
return "Name can't be empty";
}
}
});
Routing. Knockout has a facility to remember a user’s history with “hash-bangs”, but with Backbone that’s built right in. The Router (which used to be called the Controller) has a specific function with a specific mandate - this is incredibly helpful when your app gets more complex.
Eventing. It took me a while to fully grok the eventing thing - but once you understand triggering… it’s really a beautiful thing.
Readable. I find that I can read Backbone code much more readily than I can that of Knockout. Maybe I’m a bit more used to it - but I think it’s more than that. This is the sample code for the app I built in the MVC 3 episode that I just pushed. I can read that code and know what’s going on - I don’t need my View page open as well.
Cons
Be prepared to suck. It took me 3 weeks to “get it” - and I am fairly certain I still don’t really “get it”. I think this would be the case with either framework - but Backbone packs a lot more “conceptual stuff” into the mix, and you’ll need to play around a lot to see what’s going on.
Custom Events. There are some events that are missing, and should be there in my opinion. Such as when a model is saved - it would be nice if it would let its collection know, and the collection spawn its own event. You can do this manually with “trigger()” - but it’s a bit silly.
Manual Binding. One thing I like about knockout is it’s rather straightforward to bind a DOM element to your model, and you see the changes to that model propagate straight away. With Backbone - that’s not the case. You have to explicitly bind your model’s change event in the view you’re working on. I’d LOVE to see a more comprehensive way to do this in Backbone - something like:
FormView = Backbone.View.extend({
//...
bindings : {
"#myform input" : this.model
}
//..
});
This is freehanded silly-code, but the idea here is you’re binding all inputs on a form to a model. I do know that Dereck Bailey is working on something like that…
get/set. Backbone doesn’t use do notation - it can’t due to the events it’s firing all over during set and get. This isn’t a knock, necessarily, on Backbone - but in general it’s a major PITA to remember to use “product.get(“Name”)” instead of the usual dot notation. If you try “product.Name” you’ll get an undefined error. In addition - set is a bit noisy with “product.set({Name: “Stuff”})” - but again, that’s due to the language.
Summary
Backbone provides some strong opinion and structure to the javascript app-building process. This can be a good thing in that it pushes you into writing better code, it can be a bad thing if you’re rusty at javascript like I am.
So, Backbone or Knockout?
I can’t tell you which to use - all I can do is show you what I’ve found. I will tell you that I decided to use Knockout for the MVC 3 episode early on, and I changed my mind after about 5 hours. I liked Knockout’s simple approach and the way you could get more done with less code.
I didn’t like how I began to struggle with … “weirdness” after the complexity started to mount. I couldn’t leverage the Knockout approach to do what I wanted it to do - and I also couldn’t find examples online that helped me where I needed help.
I had to force myself through the Backbone concepts - and when PeepCode came out with their Backbone production - that’s when it all popped for me. After that introduction it was, literally, downhill.
All of that said - if you don’t have to work up a complex JS app - Knockout may very well fit the bill for you. It does what it does very well: instrument the UI according to settings on the viewModel. This is a powerful concept and for a lot of people, it’s all you need.
My name is Rob Conery and I am the owner/smooth operator of Tekpub, creator of
This Developer's Life, and an avid Ruby/Rails/.NET developer.
Find Something
