Before getting into my personal thoughts on these frameworks, let’s take a look at a little background information. I am not going to give any code examples in this post since they can be found in numerous places around the web, including on each project’s respective website (knockoutjs.com and angularjs.org)
AngularJS was initially released in 2009 and has grown in popularity since then. According to the AngularJS Wikipedia article,
AngularJS is an open-source web application framework mainly maintained by Google and by a community of individual developers and corporations to address many of the challenges encountered in developing single-page applications. It aims to simplify both the development and the testing of such applications by providing a framework for client-side model–view–controller (MVC) and model–view–viewmodel (MVVM) architectures, along with components commonly used in rich Internet applications.
Which is a technical speak for “it gives developers a convenient and reusable way to maintain a data model on the client side for single page applications.”
Angular’s stated design goals are to decouple DOM manipulation from application logic and the client side of an application from the server side, and also to provide structure for the complete application creation process.
KnockoutJS was initially released the year after AngularJS in 2010, and its Wikipedia description is
Knockout’s stated key concepts are to allow declarative binding of the model to the view, automatic UI updates when the model changes, dependency tracking to automatically update computed values and to allow html templating.
It can be seen both from the description and key concepts that knockout puts much less emphasis on its ability to decouple parts of the application than Angular does.
The first difference that was immediately obvious to me is that Angular is not designed to play very nicely with non-angular parts of a site. You can make it work, but is definitely a challenge. With Knockout, it is quite easy to have even a very small Knockout part of an otherwise non-Knockout page and I have done this numerous times in existing .NET applications.
The other thing that struck me fairly quickly is that Angular is a complete framework for single page apps and as such is considerably more involved and feels a more intimidating to a beginner. With knockout, there is very little plumbing or understanding needed to get a simple example running. When I was first introduced to Knockout, it seemed quite intuitive, but Angular has taken me longer to warm up to.
One thing with Knockout that can initially be confusing to a beginner is the conversion that is needed between a regular JSON object and a Knockout observable. In order for any model to be operated on by Knockout, it needs to be an observable. Unfortunately, since your server side code will provide and accept only JSON objects, conversion is necessary after data comes from the server and before it is sent back. Angular on the other hand, works directly with JSON objects eliminating the need for conversion.
Another thing that is less streamlined in Knockout is the ability to reuse components. When combining Knockout with MVC.NET, it is not hard to treat pieces as reusable components by putting the markup in a partial that can then be placed in multiple locations, but the script that includes all of the model interactions must be included on any page where the component would be used. In Angular, the ability to add custom directives makes this much more obvious.
The last notable difference I observed was the habits that seem to form with the scripts for each framework. In my experience Knockout tends to encourage long rambling scripts and does not enforce or encourage separation of concerns among different parts of your model. Angular is quite the opposite. Separation of concerns seems to come more naturally.
The lists below give a summary of the pros and cons for each framework that were discussed:
- Complete solution for single page apps
- Works directly with JSON
- Built in way to create reusable components
- Separation of concerns is easier to implement and enforce
- Great informational links when a console error does show up
- Difficult to integrate into non-angular
- More intimidating to beginners
- Need to have a fairly good understanding of the overall system to get started
- Often there is no console error when something fails
- Easily integrated into existing sites and pages
- Fairly simple concept
- Can learn as you go
- Developer is responsible for converting between JSON and observables
- Less obvious how to reuse created components