There’s a lot of talk of various client-side kind-of-mvc libraries. Three of the popular ones I’ve used are Knockout, Backbone and Angular.
While there are other comparisons of the three, I feel many of them don’t really touch on some of the aspects that I’ve come to learn from my experiences with the three.
First off, some observations of the individual libraries
Knockout
This was the first of the bunch I used. It offers a way to bind data into HTML by using special attributes and such.
Very easy to get started with, Knockout is the easiest to pick up of the three and gets you to doing things quickly.
It’s very good if you want to do things the library supports out of the box.
Where it fails in my experience is when you start getting more complicated behaviors or models. It becomes harder and harder to link behaviors with the data binding system when your models become more complex.
Backbone
Backbone is rather different from the other two. It doesn’t really give you a data binding facility as such, but rather a bunch of objects you can build your own MVC-ish solution with.
It’s quite nice when you want to build some more complex interactions or more complex models. It doesn’t really limit you because it doesn’t really give you anything high level either.
The downside of Backbone is boilerplate. You end up writing lots of code that’s mostly for wiring things together – things you get by default from Knockout and Angular with a few markup attributes. It also requires more understanding of how Backbone’s whole set of objects work together before you can do a lot.
Angular
In a similar sense as Knockout, Angular offers you data binding into DOM, but also a bunch of other things such as controllers and a ready to use set of “services” for building single page apps and other things.
Angular offers a quite easy entry into using it, but some of it can feel confusing. It uses more advanced features such as dependency injection quite a lot.
The main downside to Angular for me was that it was much harder to understand at first. Sure, the basics are easy to grasp, but once you need to do something it doesn’t do out of the box for you, it requires a much deeper understanding than the other two.
Comparing the libraries to each other
Knockout vs Angular
I think in most aspects, Knockout is easier to start with. Angular’s data binding feels more powerful than Knockout’s, but some of the ways it behaves can be hard to understand at first.
Angular relies much more on “magic” – things that seem to just work somehow – than Knockout. For example, Angular uses dependency injection to bring dependencies into components. This can be made to work purely by naming your function arguments with specific names, which can seem pretty weird at first – where does all that stuff come from?
However, Angular does not suffer from the problem Knockout has with more complex models: I think this is where Knockout’s limitations in the way it does data-binding starts to show, as you will need to craft your data into more Knockout-specific styles for it to work correctly with it. Angular on the other hand can handle a much wider variety.
Angular also has the added benefit of not requiring you to use “observables” in your model. In order for Knockout to be able to data bind things into the DOM, things must be wrapped into observables. Angular on the other hand uses more magic to solve this. Angular’s approach isn’t really that magical, but it’s rather opaque and you don’t see what’s happening under the hood as readily as with observables.
Knockout and Angular vs Backbone
I grouped this into one section since the comparisons for both Angular vs Backbone and Knockout vs Backbone are quite similar.
Backbone is the least “magical” of the bunch. This is simultaneously a good thing and a bad thing: It’s good because Backbone code is easier to understand in a way since everything you do usually needs to be explicitly coded, but the bad side is that it causes Backbone applications to require more boilerplate coding that isn’t necessary with Knockout or Angular.
Backbone is also quite easy to grasp. Everything is pretty much as it appears, quite simple JavaScript “classes” that have certain functions in them and certain ways they can be used. In Knockout you really don’t use that much objects from the library beyond observables and the data-binding features in the DOM, but when using data-binding you don’t really see what goes on in the background. Same applies to Angular, but to an even higher degree because Angular uses additional things like dependency injection which again is something that is done for you by the library’s own mechanisms that work hidden from you.
Backbone also has the least amount of surprises. Again because you need to wire things manually via your favorite DOM library and Backbone’s easy to use event system, you pretty much know what’s going on… templates are being created, values are assigned, etc.
Some surprises you can encounter with the other two are performance issues or obscure bugs/features with the data-binding not working the way you expected it to. In particular with Angular, it doesn’t always behave exactly like you’d think (could be because I still lack a full understanding of it – just goes to show…). An issue I had with both Knockout and Angular is also surprises in performance as mentioned: Certain situations can lead the data-binding code being extremely slow and requiring you to instead just generated the DOM by hand with the DOM APIs or other approaches.
So, which one comes out on top?
None of the three is clearly superior in every aspect.
Knockout has very low barrier of entry and if you need to put something quickly together, I think it comes out on top easily. However, if you need to build anything more complicated, it might be better to look at Angular.
Backbone is not just a data-binding facility; it has the groundwork to build all kinds of things. It does require more boilerplate, but it comes on top when you need to build more specialized solutions such as integrating with WebGL or 3rd party libraries.
Angular is very powerful. It seems very suitable for building more advanced apps, but certain aspects of it can be harder to understand. If you can put the time to learning it or have someone on hand to help, it can be a very good choice as the code it produces can be very readable and it has full support for automatic testing out of the box.
If I had to pick one of the bunch that wins, it would be Angular. It is however not a clear winner: It merely inches above the rest due to its power and convenience combined into one. It can require a lot of learning though to be able to use it to its full potential.