PIcking Your Javascript Mobile Framework: Part 15 - KnockoutJS

The main site for Knockout, knockoutjs.com, is a fantastic resource. Maybe it errs a teensy bit on the garish side, but it’s more informative (and exciting with that information) than any of the other sites on here.

I highlighted the outstandingly easy and comprehensive tutorials before. The structure is the same as that of other tutorials on jsFiddle, but it looks better and is more… structured.

Let’s look at the main claims on the home page. Knockout has:

• Declarative Bindings – another word of saying you can tie values in the model to elements in your DOM – both directions
• Automatic UI Refresh – changes anywhere in the model are pushed back to all the DOM elements that need to know
• Dependency Tracking – not only does the DOM follow the model and vice versa, but changes in the model can percolate throughout it (and back to the DOM)
• Templating – yes, you can have templates…

In addition to that, Knockout points out it’s small (54k minified) and has no dependencies on other packages. Again, this is mostly of interest to web developers, not to mobile app developers. But it’s nice, nonetheless. Plus, you already know that Knockout can’t be bad for performance and can’t be a typing tutor, since it’s still in the running.

The Todo app shows a lot. First, Knockout by itself requires very little code. Adding Require to the mix, though, makes the application stand out in performance and gets it to 8th rank.

The main difference between the Require version of the app and the standalone version is that whoever did the latter implementation realized that lots of files load slowly. On the other hand, Require’s ability to magically make a single loadable file allows the implementation to spread its wings. From two files (index.html and an app.js) we go to 6:

1. index.html – quite different in both versions, by the way. The one with Require (from now on the default) shows that Knockout has data-bind attributes that are actually dynamic – they are scripts of sort. Take this example: <footer id="footer" data-bind="visible: completedCount() || remainingCount()">
   In it, the footer is made visible if either the count of completed items is not zero or that of the remaining items. That’s good logic, but notice how here the visible attribute is set based on the result of operations (function calls) and not based on attributes.
2. main.js – the main entry point, which simply defines where to find the knockout library (require does that, and if you don’t follow the convention, you don’t get the giant require Javascript collection); it loads the todos from local storage, and sets up the bindings.
3. global.js – provides just two global values (the key into localStorage and the key code for the Enter key)
4. handlers.js – which** takes care of bindings** for the Enter key and selection (frankly a whole lot of code for not a lot of functionality)
5. todo.js – the core functionality – adding, editing, removing todo items and storing them into local storage
6. Todo.js – this one uppercase, is the object definition; Knockout chooses to use only one object, and let the list be a simple collection. In this implementation, localStorage will contain the “editing” flag, which indicates whether the todo is being edited. That’s pretty stupid, since there is no point in presenting back the item being edited on next load and it adds to storage requirements. But, as they say, “whatever”

Aside from the odd mix of attributes and function calls in the data-bind attributes, I could easily live with Knockout. Certainly, relatively zippy performance and the compact size of the code make me even fonder of it. And let’s face it, when they put so much emphasis on documentation, who is to say no?