AngularJS vs KnockoutJS – Part 1


1 September 2015, by

In Softwire, we’ve used AngularJS and KnockoutJS on a variety of projects, and have found that this makes web development a lot easier and a lot more pleasant! With this series of blog posts, I’m hoping to share what we’ve found out about these, and other, data-binding libraries along the way by looking at:

  • What groups all these libraries together?
  • How do these libraries work?
  • Which library is the “best” one?

The Traditional Way

Not so long ago, the front-end of a web-site was made up of static tags (like “h2”) to represent page structure. These had a default styling that CSS altered. JavaScript was maligned – at first because it was mostly copied and pasted from sites to give annoying visual effects (Snowflakes!). As it became more of a key player in professional applications, it didn’t have the mature support necessary to create well-structured, well-encapsulated applications.

Not using JavaScript was not an option, so libraries tried to encapsulate a lot of the lower-level visual aspects – from Dojo’s toolkit to jQuery – to varying success. What none of them did, however, was provide meaningful structure to the code, still encouraging you to merge your business and your visual concerns. This has made JavaScript unmaintainable and very hard to test.

Many of the large JavaScript libraries that are becoming more mainstream are an attempt to solve this.

An Example

The aim of many of these libraries and frameworks (such as KnockoutJS and AngularJS) is to move the logic determining how something looks to the traditional HTML files. The underlying frameworks will then interpret these additions to the HTML according to data that is backing the page.

For example, you are able to attach a “for each” command onto an HTML element. AngularJS uses namespaced “ng-“ properties to invoke its magic. A bullet-pointed list containing all elements of an array would be written like this:

<ul>
  <li ng-repeat="name in names">
    {{ name }}
  </li>
</ul>

Exactly where, and how, we let this portion of the code know where to find the “names” variables differs from framework to framework. Its benefit is in allowing us to separate the concern of finding and producing these names; from rendering the visual DOM aspects of the list.

The MV* Pattern

 This aim – to separate low-level concerns from more interesting, data-driven logic – is not a new issue in coding, and a lot of the motivations and ideas are the same as those that lead to the MVC (Model-View-Controller) pattern becoming so prevalent in traditional server-side languages such as Java. These aren’t new patterns, we’re just moving our focus on quality to a different part of our tech stack.

Obviously the parallels aren’t perfect. JavaScript applications are mostly smaller and don’t require quite as rigid a structure. As such, many of the existing libraries use simpler patterns to match the view to the data model, from KnockoutJS’s MVVM (Model-View-View Model) to Backbone’s MVP (Model-View-Presenter) to AngularJS’s MVW (Model-View-Whatever).

Existing Libraries

There are a large number of libraries and frameworks out there that try to solve this problem – and the number grows weekly! In a future blog post, we’ll take a deep dive into two different libraries that solve this problem with data-binding (KnockoutJS and AngularJS). This isn’t the only way to solve this, however, and ReactJS, Ember and Backbone have also proven very popular. The fast-moving JavaScript ecosystem means that there may be another big name soon!

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


× 2 = two

Submit Comment