AngularJS vs KnockoutJS – Part 3


15 September 2015, by

In previous blog posts in this series, we examined the motivation behind some of the modern JavaScript frameworks that aim to make front-end code more maintainable. We also examined AngularJS and KnockoutJS as specific examples of how they individually integrate data models with HTML views.

This blog posts aims to compare how well the two work: we don’t want to fall in to the trap of suggesting that they are competing with each other as they both do different things. However, as two libraries that make front-end development easier through attributes, it’s rare you’ll use both and so you’ll often reach a time on a project where you have to make a decision between two.

Setting the Framework Up

Setting KnockoutJS up is as easy as you’d like it to be – you can pull the source file into your project by downloading it, linking to their CDN or using package management tools such as Bower. It works nicely with all major dependency tools such as RequireJS, or can be included globally in your project. All you need to do to get it working is call ko.applyBindings in one place. It works nicely with all of your code, and can be added at any stage in the project as it plays nicely with other libraries.

AngularJS is a bit more of a tricky beast – building a project around it from the beginning is not much more effort than KnockoutJS. There’s slightly more boilerplate at an early stage to deal with modularisation, but these costs are mostly compensated by not requiring the set-up of, say, RequireJS.

Adding AngularJS to an existing project, however, is significantly harder. Because of the opinionated idioms that come from the use of AngularJS, it’s often hard to make it integrate seamlessly with other code you’ve already written. We’ve used AngularJS with other module loaders, for example, but the cost of maintaining that has been far higher than expected.

Conclusion: On greenfield projects, both libraries perform well. KnockoutJS is easier to add incrementally to an existing project.

Browser Support

A minor point, but if you have to support Internet Explorer, then you may have a harder time with AngularJS that has a small number of outstanding issues on all IE builds; and no support for IE versions 8 and under. KnockoutJS goes all the way back to IE6.

Conclusion: If IE6 or 7 support is important, AngularJS cannot be used.

Community Support

One of things that makes JavaScript fascinating (or, if you’re one of the front-end nay-sayers: tolerable) is how fast the community moves. There are now more npm packages than there are Maven Central libraries, showing just how fast people rally behind languages to bolster its features.

We have to be careful about comparing raw statistics of two libraries of differing sizes. In terms of Google Search trends, AngularJS is over 12 times as popular, and exponentially rising. Angular is the second most installed bower package, whilst KnockoutJS doesn’t make the top 100.  The trends certainly suggest that AngularJS has more staying power.

AngularJS’s modular nature makes it a natural fit for community support as people can add directives, modules and services that can be easily pulled in and integrated with your code. This means that if you’re requirements are common, then you can use a large number of off-the-shelf libraries.

KnockoutJS does allow you to write bespoke additions by creating your own bindings, or extending the knockout object itself in an easy and well-documented manner. Although there are some KnockoutJS libraries to add features such as Pager.js for routing, there are definitely fewer. At least a few times I’ve thought “Surely someone’s done this already” when writing features with KnockoutJS.

Conclusion: AngularJS is much more popular, and has more community libraries.

Ease of Learning

The documentation and online tutorial for KnockoutJS are some of the best I’ve seen. Knockout is so simple and light-weight that when new developers see it, they’ve always taken to it immediately and are able to contribute to development teams very quickly.

AngularJS is a much bigger beast. Their documentation is, necessarily, much more heavyweight and bulky to reflect the larger amount of things that people have to learn. Almost everyone who has worked long enough with AngularJS is now happy with how it works and can contribute speedily, but it often takes longer to reach the same depth of understanding.

Conclusion: KnockoutJS has simplicity and brilliant documentation on its side; the larger AngularJS can’t compete.

Testability

AngularJS was made with testability at the very front of its mind, and there are lots of guides online about how to set up unit and integration testing on your AngularJS modules. We’ve had great experiences running our JavaScript unit tests on such projects with Karma and WallabyJS giving us instant feedback when things fail.

KnockoutJS is unopinionated about tests – it’s a much smaller library so we wouldn’t expect anything else. If KnockoutJS is used with some modularisation frameworks (which we always strongly recommend!) then good discipline, such as encapsulating all low-level DOM manipulation, makes unit testing no harder than with any other library.

Conclusion: Both libraries are testable, though AngularJS was written with this very much in mind, making set-up marginally easier and more documented.

So, which is better…?

We’ve found in projects at Softwire uses for both frameworks.

We typically favour KnockoutJS on projects that have less need for the larger, more opinionated AngularJS. This could be because there is less complex interactions between the user and the data; or because the project simply runs for a shorter time. For legacy projects, it allows us to use it minimally only where we need to, preventing a large initial investment of effort. A lot of developers here love KnockoutJS and many use it on their own pet projects because of its light-weight approach.

We have, however, used AngularJS successfully on a number of projects. We’ve found that the ramp-up time is slightly higher, as it takes control of more aspects of the code base. However, if there is sufficient complexity or on a project, or the code base is larger, the initial set-up and learning costs on a project quickly repay itself and it becomes our framework of choice on large projects with potentially complex user interactions.

We are, as we are with all technologies that we use, constantly examining the ecosystem for new and maturing options outside of these! For those interested in seeing more frameworks in action, TodoMVC is a great website that codes the same site using multiple different libraries.

David Simons trains developers in High-Quality Front-end JavaScript. Sign up to his next course here.

Tags: , , , ,

Categories: Softwire, Technical

«
»

Leave a Reply

* Mandatory fields


one × = 2

Submit Comment