Knockout.js - a nice framework comes with a new major release

The year ends, development never stops. Knockout.js releases a new major version 2.0.0 (http://www.knockoutjs.com). Even the first major version was a great framework to design and architect your JavaScript SPAs (Single Page Application :-).

Release notes: http://blog.stevensanderson.com/2011/12/21/…

Now with release 2 the Knockout.js gets even better. I tried and studied some JS framework in the last year an KO was the one which convinced me most. It delivers a nice design concept by applying the MVVM pattern. Integration of templating and the excellent data binding makes creating HTML frontenend application fun and incredibly efficient.

I would see knockout.js as a macro-framework. It's not a replacement for a swiss-army-knife library like jQuery on which KO is built, btw. Rather it is concerned about the general structure of a browser application. This is one of the key pain-points of the browser as an application platform. While doing little things quickly is easy and done quickly, an app often tangles up into a chaos of interweaved functions while growing larger. KO help to overcome this by delivering a clean and easy design (MVVM) which can be applied on application and widget/component scope and helps keeping up maintainability.

Key points I like:

• introduces clean application design
• helps to solve the biggest web application development problem: structure and know your application
• no constraint on the view side - everthing goes
• powerful observable model with dependency tracking
• great data binding to synch model and view automatically
• great template integration re-rendering templates automatically on model change

Note: ko is not a component library with standard widgets; do-it-yourself or use the component library of your choice,


MVVM
The application is based on a view model with contains an observable data model and the activities to access and manipulate these data. Based on Observables a model can be put together quickly by enforcing a clean design. Once the model is defined the UI can be attached to and synched with that model out-of-the box.

Observable model
Great approach as known from other stuff out there (e.g. backbone.js, spine.js, JavaScript MVC). An observable model triggering change events. Observable can even be chained to other obsrevables (dependentObservables in v1 or computedObervables in v2)

Data binding
An excellent data binding is key for a efficient web development experience. Knockout.js has it and it's great! The observable model can be bound to DOM elements with 'data-bind' attributes. This makes it easy to render JavaScript data into DOM elements. On a model change the templates are re-rendered automatically. This way an application developer has only to be concerned about the business functionality manipulating the model while the view updates automatically.

When doing UI development having data and UI in synch is a big share of work- mostyl trivial but time consuming. Having this done by the framework saves time to make the UI incredible and awesome (or, sadly, simply cheaper ;-) Knockout.js makes 

button.attr("disabled", "disabled")

never clutter your js code again as you quickly bind such stuff to an observable model value and make the framework synch the UI on model change:

<button data-bind="enable: myItems().count < 5">Add</button>

Templating
Knockout.js is based on jQuery and integrates with the templating engine of Boris Moore (Microsoft) nicely. Templates in the page can be attached to DOM elements by data binding and are executed by KO automatically. It's and deep and efficient integration. Changes on an data item of a collection make only render again these view elements belonging to that particular item and not the entire collection.

With 2.0.0 templates integrate even nicer. A template can now simply be part of the DOM (as of version 1.x templates are included in a script element with type text/tmpl or similar). That way the markup code is very clean. I guess it's the approach which delivers the least ugly markup template code I've ever seen. No other template language I know is cleaner. This might be a detail, but knowing that there is no template language which is not ugly for advanced templates, this can be a real plus regarding maintanability. Beside that, having the template markup parsed by the browser while page loading is an appreciated perfomance boost for large apps.

So now, if you ever have to do web application development for desktop you definitly should check out knockout.js. It's not only great but supports browsers back to the stone edge (IE6). Documentation is extensive and the framework is easy to use, helps you keep things together and greatly supports the knitty-gritty, boring house-keeping web dev work browser developers have to tackle.

Pusher - websockets made simple and easy

While visiting the Falsy Values Conference in Warsaw I stumpled upon pusher.com. Pusher offers an interesting websocket infrastructure which makes jumping into websocket application development easy.

Currently websocket technology on the server side is not as widely available and common as traditional HTTP server technology. In the Java ecosystem there are pleinty of  well known http server implementations available which use non-blocking I/O. However, non-blocking HTTP is rather new in the Java world and has just been added to the most recent JEE6 specification.  A particular websocket implementation is not part of the current Java spec.

Grizzly (Glassfish) offers a Websockets implementation, Jetty does as well and Atmosphere even aims for a portable solution. Tomcat, the most popular Servlet container does not.

Traditional webservers bind each connection to a thread. This limits scalability for websockets and look-a-likes tremendously. NIO implementations like node.js or Java Servlets 3 are event driven. One (node.js) or more worker threads are dispatching events. That way many connections are handled by a single thread which allows for better scalability especially for connection held open for a long time.

It seems that he protocol and NIO technology required for doing websockets add complexity to web applications which is currently not common for the community and hence not that easy to achieve. However, applications based on websockets mostly need nothing more than some kind of publish-subscribe mechanism. Publish-subscribe is easy to use, but very powerful and flexible.

Thats exactly what Pusher offers. A Websocket (or Flash-socket) based service to publish and subscribe JSON messages. On the browser side a JavaScript provided by Pusher is included to do the the websocket work. Browsers not offering Websocket support are supported by a Flash fallback. This is of great value and not a snap to achieve by a homebrew solution. Today it's essential to have a good and proven third-party library to achieve solid websocket applications targeted to a main-stream web audience.

An application subscribes for a given event and gets its callback called when a given event occurs.

var pusher = new Pusher('KEY');
pusher.subscribe('iam');
pusher.bind('news',
  function(data) {
    document.getElementById("news").innerHTML = "<p>" + data.msg + "</p>";
  }
);

Trigger events is not only possible from within the browser. Pusher offers a REST interface to trigger events from any language supporting HTTP. It's not a suprise to find implementations in many languages listed on the Pusher website. There is a Java library for Google App Engine for Pusher available at github. As I'm not using Goolge App Engine and required a adapted solution so I forked the project and provided a implementation based on Jakartas HttpClient. The refactored project added some more OO style eg. to have it easily available in a Spring environment or other IOC containers. This has been mostly achieved by removing the rather static nature of the GAE solution. Have a look at my fork at github.  The GAE implementation of Stephan Scheuermann was of great value for me. The code was well-structured and his implementation of creating appropriate hashed signatures worked for me like plain vanilla and helped me having a nice solutions quickly. Thx for that nice work!

Sending an event to a Pusher application from within Java is easy that way:

Pusher Transport httpClientTransport = new HttpClientPusherTransport();
PusherChannel channel = new PusherChannel("iam", APPLICATION_ID,
          APPLICATION_KEY, APPLICATION_SECRET,  httpClientTransport);

PusherResponse response = channel.pushEvent("news", JSON_STRING);
PusherResponse response = channel.pushEvent("news", ANOTHER_JSON);

I like that Pusher stuff. I can easily create a Websocket implementation without going into other solutions as node.js, kaazing or Glassfish offer and for which it's is hard to find hosting providers. I can stick to the server environment which I and my server administrator is used to and opt-in websockets with Pusher for those applications relying on websockets (which are not that many by now). Having a solid client-side solution with support for many browsers is another big plus.

HTML5 datasets and their socio-political underpinnings

While skimming through the HTML5 features I stumbled upon the dataset attribute feature. In HTML5 developers are allowed to put some data-* attributes on an HTML element to bind data to it:

<ul>
   <li id="switzerland" 
      data-continent="Europe" data-population="7000000" data-id="23">Switzerland</li>
   <li id="germany" 
      data-continent="Europe" data-population="83000000" data-id="12">Germany</li>
   <li id="egypt" 
      data-continent="Africa" data-population="81000000" data-id="16">Egypt</li>
 </ul> 

Thinking about it I found many interesting aspects for this feature in particular and the HTML5 specification in general.

At first it's about the new philosophy with which the HTML5 specification has been done. Sometimes this is called the 'paving the cow path' principle. The HTML5 specification does not only envision a bright future where everything should be better. Instead many features and techniques currently implemented by browser vendors or often done by webdevelopers became part of the standardization process.  Dataset attributes is such an example. Many JavaScript libraries already augment HTML tags with proprietary attributes to communicate data from a server side page template to a script of the library.  Dojo, among others, is a famous example doing this. By including dataset attributes the W3C provides a way for such approaches to become a standard compliant feature instead of an clever hack.

Another nice thing about dataset attributes is that, in spite of not being standard compliant prior to HTML5,  it works nicely on older browsers as well. It does not hurt in a way that a browser reports an error and furthermore it can be implemented with JavaScript when browser support is missing. So its easy to enable older browsers to support the feature and once a time all browsers support the feature it comes out of the box.

In HTML5 browsers the data on the above li elements can be accessed easily by using the HTML5 API:

var data = document.getElementById('switzerland').dataset;
log( "population: " + data.population );

Currently browser support for that feature is very bad. But as mentioned above we can implement this easily by using the good old DOM API:

function init() {
    // get data for a single li element
    var dataItem = getData(document.getElementById('switzerland'));
 
    log( "population: ", dataItem.population );
};
 
 
function getData(domElement) {
    var atts = domElement.attributes, // get the attributes of the dom element
    len = atts.length,                // get the length once
    i = len,                          // get the length once
    dataset = {};                     // the object ot store the HTML5 microdata properties
 
    // fast loop over attribute array (especially for DOMElementCollections). i-- not JSLint compliant! 
    while(i--) {
        var att = atts[(len-1) - i];                       // get the attribute
        if (att.name.indexOf("data-") == 0) {              // filter HTML5 data attributes
            dataset[att.name.substring(5)] = att.value;    // add as property to the store object
        }
    }
    return dataset;
}

If you are a JQuery user you are already on the save side. jQuery comes with the data() method which does automatically include HTML5 dataset attributes. So accessing the above data with jQuery is a snap:

$('document').ready(function() 
 
  // a single elements data
  log("jquery switzerland.data() --->" , $('#switzerland').data()); 
 
  // match each li to call the function with it
  $('li').each(function(idx) {
     // jQuery includes HTML5 data attributes in its data feature
     var dataset = $(this).data();
     // log to firebug console
     log("data item of list item " + idx + " -->", dataset );
  });
}); 

The dataset feature of HTML5 exemplifies how standards could try to catalyse an already ongoing process. Picking a common technique or coding practice and streamline it to a standardized way of doing it. This way developers, vendors and library providers are not only encouraged to go along the same track but it does really 'pave the path' in a way that further negotiations or specification efforts are minimized by referencing to the standard. I economic history such an approach is highlighted by Douglass C. North with the concept of minimized transaction costs which he sees as the main advantage of socio-political institutions (http://www.librarything.com/work/154133). The very same can be applied to the institution of technical standards as the W3C specs are, especially if hegemonial leaders or monopolists support them as well. 

Whenever a databinding feature should be implemented or a communication technique between your server-side templating framework and a JavaScript library, HTML5 dataset attributes should be on your radar.