David Owen Bailey

Welcome to my little code garden.


A brief introduction

12 December 2012

In a previous article I wrote about TypeScript and how it aims to help developers create enterprise-level applications using JavaScript. Since I was on the subject, I decided to cast my net a little wider and investigate other technologies aimed at improving client-side development experiences. With this article I continue my exploration of JavaScript-related technologies by looking at the Knockout.js framework.

What is Knockout, and why should I care?

Knockout is a framework built entirely in JavaScript which uses a Model, View View-Model (MVVM) type pattern for implementing data-aware client-side User Interfaces. The MVVM pattern allows for a very neat separation of concerns by separating the business-related logic and data into the Model;  the presentation logic into the View-Model and the actual UI elements that the user interacts with into the View. The benefits of using the MVVM pattern are legion and I encourage you to quickly go read up on the basics of the MVVM pattern before continuing with this post. Ok enough about patterns, you’re here to learn more about Knockout. So, at it’s very core, Knockout promises to enable developers to easily create rich responsive user interfaces build on top of a clean underlying data model. Knockout doesn’t try to compete with other low-level type JavaScript libraries like jQuery. The jQuery framework is aimed at solving the increased complexity of using JavaScript to perform DOM operations. As client-side applications become increasingly sophisticated and complex, so does the complexity of updating the UI as the underlying data backing the UI changes. With jQuery or *gasp* pure JavaScript, the developer will have to directly manage DOM elements in order to update the UI as the underlying data changes. DOM operations are considered low-level operations, and jQuery helps a lot in this regard. Knockout on the other hand tries to solve a very different problem. Knockout does not require the developers to concern themselves with low-level DOM operations. Removing or adding <li> type tags, for instance, are handled for you by the framework. This allows developers to rather focus on the data and how the UI should respond to changes in the underlying data model - Knockout takes care of the low-level dirty work for you.

The Good

  • Written in JavaScript - this allows Knockout to work using any client- or server-side technology.
  • Compact - the Knockout library is small (around 13kb when zipped)
  • Works on all mainstream browsers (Chrome, Firefox, IE, Safari, etc.)
  • Elegant dependency tracking - the observer pattern type implementation of Knockout allows the correct sections of the UI to update as the model backing the UI changes.
  • Declarative bindings - Knockout utilizes simple and descriptive markup to bind the UI elements with the underlying data model.
  • Complexity simplified - the declarative bindings makes data binding increasingly complicated dynamic UI’s a breeze.
  • Extensible - it is trivial to implement custom behaviors as new declarative bindings which can be reused as well.

The Bad

I honestly can’t think of anything bad to say about Knockout at this time. I am currently exploring its applications in various scenarios and I might be able to unearth something to gripe about in due time. For now, I consider Knockout an amazing technology built on tried-and-tested software engineering patterns and I look forward to test the limits of client-side UI complexity in the months to come.

About David

  • David Bailey
  • David is a tech geek who has been working in the software industry for more than 8 years. He is currently working as a Technical Team Lead at Digioutsource where he is involved in the design and building of a range of software products.