var latestOrder = this.orders()[this.orders().length - 1]; // Read a value
latestOrder.isShipped(true);                               // Write a value

… with this:

var latestOrder = this.orders[this.orders.length - 1];     // Read a value
latestOrder.isShipped = true;                              // Write a value

… while still retaining all of Knockout’s capabilities of automatically refreshing your UI and automatically detecting dependencies between different model properties.

Basically, it’s all the goodness of Knockout, but without having to remember parentheses. It requires a moderately up-to-date browser (more about this later).

Getting started

Download knockout-es5.min.js and add a <script> reference after you reference Knockout itself, e.g.:

<script src='knockout-2.2.1.js'></script>
<script src='knockout-es5.min.js'></script>

Then you can declare model classes without needing any explicit references to ko.observable, e.g.:

function OrderLine(data) {
    this.item = data.item;
    this.price = data.price;
    this.quantity = data.quantity;
 
    this.getSubtotal = function() {
        return "$" + (this.price * this.quantity).toFixed(2);
    }
 
    // Instead of declaring ko.observable properties, we just have one call to ko.track 
    ko.track(this);
}

Notice that the properties are just plain properties, without being wrapped in ko.observable. This means that during computations, such as in getSubtotal, there’s no need to invoke them as functions to read their value (e.g., this.quantity()). Similarly if you wanted to change a value, you’d just use a plain old assignment, e.g.:

someOrderLine.quantity += 1;

… instead of function calls (e.g., someOrderLine.quantity(someOrderLine.quantity() + 1);).

How it works

It’s so very simple. ko.track walks the list of properties on your model object, and for each one, replaces it with an ES5 getter/setter pair that reads/writes a hidden underlying observable (initialised to the existing property value).

The neat thing is that the Knockout.js core library doesn’t need to know anything about this: when you get/set one of these properties, some observable is read or written, and therefore all of KO’s existing binding, computed, and dependency detection functionality just works perfectly. Knockout-ES5 doesn’t have to patch any of the KO internals, so it works with any recent version of KO.

Controlling which properties are upgraded

If you want to restrict which properties are upgraded to observability, pass an array of property names:

ko.track(someModelObject, ['firstName', 'lastName', 'email']);

By design, ko.track does not recurse into child objects. I would encourage you to declare child objects as instances of some class of your own, with its constructor having its own ko.track call — this gives you far more control over how much of the object graph is walked.

Accessing the observables

If you want to access the underlying ko.observable for a given property, e.g., so that you can subscribe to receive notifications when it changes, use ko.getObservable:

ko.getObservable(someModel, 'email').subscribe(function(newValue) {
    console.log('The new email address is ' + newValue);
});

About arrays

Array-valued properties are special. As well as upgrading them to support observability like other properties, Knockout-ES5 intercepts calls to push, pop, splice, etc., to trigger change notifications just as you’d expect. This means that any UI based on the array, such as a list, will update automatically if you add or remove items.

With Knockout-ES5, you can access the array’s subproperties directly, e.g.:

var numItems = myArray.length; // Don't have to write myArray().length

Also, Knockout-ES5 adds a few additional functions that have proven useful on ko.observableArray instances: remove, removeAll, destroy, destroyAll, replace.

Computed properties

The most important feature of Knockout.js, and what differentiates it from most other Model-View JavaScript libraries, is its “reactive” dependency-detection capabilities: its ability to chain computed properties, so that changes propagate through an arbitrary object graph into your UI, without needing you to declare those dependencies anywhere.

Traditionally, Knockout uses ko.computed for this. So how does it work in Knockout-ES5? There are a couple of different patterns you can choose from:

1. Just put a plain function on your model. In the example at the top of this blog post, getSubtotal is a plain old function. By invoking it from a binding, KO will detect the function’s dependencies (in this case, price and quantity) and will automatically refresh the UI when either changes:

   <span data-bind="text: getSubtotal()"></span>

   Pretty straightforward.

2. Use ko.defineProperty. This is provided by Knockout-ES5 and is a KO-style equivalent to Object.defineProperty. It lets you declare a computed property with a get (and optionally set) function, for example:

   ko.defineProperty(this, 'subtotal', function() {
       return this.price * this.quantity;
   });
    
   // Alternatively, the third arg can be an object like { get: function() { ... }, set: ... }

   The advantage of this is that (A) you can read the subtotal property without having to invoke it as a function (as in getSubtotal()), and (B) its value will be cached and reused for all future invocations until a dependency changes, instead of re-running your get logic for each evaluation:

   <span data-bind="text: subtotal"></span>

   To ensure dependencies can be detected, place ko.defineProperty calls after your ko.track call. Or, if you want to put ko.defineProperty first, make sure no other code tries to evaluate the computed property before ko.track runs (if it evaluates before dependencies are tracked, it won’t be able to detect those dependencies).

Browser support

Knockout-ES5 works in ECMAScript 5-capable browsers. Let’s consider whether that’s appropriate for your project.

Since the Age of Antiquity, browsers such as IE6 have supported the ECMAScript 3 (ES3) JavaScript specification. It’s a tired old workhorse of a spec. Since then, all modern browsers have moved to ECMAScript 5 (ES5). You’ve been running ES5 for some years already, at least since IE9/Firefox 4/Chrome 6. ES5 adds a wealth of language and runtime primitives that open up valuable new possibilities. It’s no surprise that, when deciding which older IE versions to leave behind, jQuery 2.0 chose to support only IE 9 and newer, where ES5 is available.

Of course, Knockout.js itself takes backward compatibility very seriously: it has 100% support for anything from IE6 and Firefox 2 onwards. You can drop it into pretty much any web app with confidence. That is not changing. But today there are many projects where you know for sure your code will run only in an ES5 environment, for example:

• Large, sophisticated public web apps (such as the one I currently work on) that already require at least IE9 or another modern browser
• Intranet applications for sane corporate environments
• PhoneGap apps targetting iOS/Android/WP8
• Server-side code running inside Node.js

Summary: Knockout.js itself continues to support ES3 browsers such as IE6, and Knockout-ES5 is an optional plugin for those projects where it’s safe to depend on ES5.

The source

If you’re have Knockout experience already and are interested in more details about the implementation of Knockout-ES5, see the source. It’s shorter than this blog post.

This may look like a native iOS app, but this UI is all implemented with HTML, CSS, and JavaScript (see the previous post for details about my new iPhone app, Touralot, built with PhoneGap). So, how does all this slidey stuff work?

Using “transform” and “transition” in lists

The basic principles here are:

• For animations to be smooth and hardware-accelerated, they have to be done with transform: translate3d
• Even so, element positions should still be determined by the DOM structure (minimizing use of JavaScript)

So, consider some markup like the following:

<ul class="items">
    <li>Monday</li>
    <li>Tuesday</li>
    <li>Wednesday</li>
    ...
</ul>

The element positions are determined by the DOM structure, but not using translate3d. Now consider the following CSS rules:

.items { position: relative; }
.items li { 
    position: absolute; top: 0; left: 0;
    transition: all 0.2s ease-out;
}
 
.items li:nth-child(1)  { transform: translate3d(0, 0%, 0); }
.items li:nth-child(2)  { transform: translate3d(0, 100%, 0); }
.items li:nth-child(3)  { transform: translate3d(0, 200%, 0); }
...

As you can see, the <li> elements will now be positioned absolutely against the parent <ul>, and we use translate3d to recover the usual vertical offset based on each element’s position in the DOM. What’s more, there’s a transition rule so that, whenever translate3d changes, the browser smoothly animates the element to its new position.

[Aside: For Webkit, you’d need prefixed rules as well (-webkit-transform and -webkit-transition). Current versions of IE and Firefox don’t require the prefixes.]

What’s the result? Well, now whenever you change the set of <li> elements inside the <ul>, all the other <li> elements will smoothly animate into their new positions, without you having to write any code to tell them to do so. This works wonderfully if you’re generating your DOM through any kind of templates/binding library such as with Knockout’s foreach binding, but also works nicely just with plain old DOM operations. Try this:

The add and remove functionality doesn’t have to tell the elements to animate. They just do that naturally. For example, the code for add is just:

$(".append").click(function () {
    $("<li>New item</li>").insertAfter($(".items").children()[2]);
});

Browser quirks

Webkit (or at least Chrome) has annoying bug whereby it doesn’t account for in-flight CSS transitions when computing the scroll extents of a container. So you’ll need to do something like the following to force it to recompute the scroll container bounds at the end of the transition:

// Workaround for Webkit bug: force scroll height to be recomputed after the transition ends, not only when it starts
$(".items").on("webkitTransitionEnd", function () {
    $(this).hide().offset();
    $(this).show();
});

Also, since IE<10 doesn’t support transform or transition, you might also want to include some conditional CSS like the following to get basic non-animated behaviour on older browsers:

<!--[if lte IE 9]><style type="text/css">
    /* Old IE doesn't support CSS transform or transitions */
    .list-example .items li { position: relative; display: inline-block; }
</style><![endif]-->

It works for grids, too

With this technique, there’s nothing special about one-dimensional vertical lists. It works exactly as well for two-dimensional grids, without any changes.

Well actually, this raises the question of where all those .items li:nth-child(x) rules are coming from. So far I assumed you were writing them by hand. But how many such rules should you write? Couldn’t we generate them programmatically? Why yes, of course. Try this utility function:

function createListStyles(rulePattern, rows, cols) {
    var rules = [], index = 0;
    for (var rowIndex = 0; rowIndex < rows; rowIndex++) {
        for (var colIndex = 0; colIndex < cols; colIndex++) {
            var x = (colIndex * 100) + "%",
                y = (rowIndex * 100) + "%",
                transforms = "{ -webkit-transform: translate3d(" + x + ", " + y + ", 0); transform: translate3d(" + x + ", " + y + ", 0); }";
            rules.push(rulePattern.replace("{0}", ++index) + transforms);
        }
    }
    var headElem = document.getElementsByTagName("head")[0],
        styleElem = $("<style>").attr("type", "text/css").appendTo(headElem)[0];
    if (styleElem.styleSheet) {
        styleElem.styleSheet.cssText = rules.join("\n");
    } else {
        styleElem.textContent = rules.join("\n");
    }
}

You can specify a maximum number of elements to account for, and the number of columns desired in your grid (or pass 1 for a single-column vertical list). Of course, it would be nicer still if we could write just one rule that specified the translate3d values as a function of the element index, but I’m not aware of any way of doing that in CSS 3. Let me know if you can think of one!

Here’s the result, as a three-column grid:

Supporting arbitrary reorderings

The technique so far is great for animating all elements other than the one you’re inserting or reordering. But if you remove and insert an element in a new position, it will appear there instantly, without a transition, because it is a brand new element as far as the CSS transition logic is concerned.

So, how would it be possible to achieve something like the following, where the “reorder” button smoothly moves elements to new positions? Try it: click the random order button:

One possible technique is to override the translate3d values for each element with a snapshot of their current values, so that the elements retain their coordinates independently of their DOM order. Then, after mutating the DOM, remove your snapshot values, and then the CSS transition will kick in to move the element smoothly to its final location.

Here’s are a couple of handle jQuery utility functions:

(function () {
    var stylesToSnapshot = ["transform", "-webkit-transform"];
 
    $.fn.snapshotStyles = function () {
        if (window.getComputedStyle) {
            $(this).each(function () {
                for (var i = 0; i < stylesToSnapshot.length; i++)
                    this.style[stylesToSnapshot[i]] = getComputedStyle(this)[stylesToSnapshot[i]];
            });
        }
        return this;
    };
 
    $.fn.releaseSnapshot = function () {
        $(this).each(function () {
            this.offsetHeight; // Force position to be recomputed before transition starts
            for (var i = 0; i < stylesToSnapshot.length; i++)
                this.style[stylesToSnapshot[i]] = "";
        });
    };
})();

Now you can achieve the random reordering thing as follows:

$(".reorder").click(function () {
    $(".items li")
        .snapshotStyles()
        .tsort({ order: "rand" })
        .releaseSnapshot();
});

This works just the same with two-dimensional grids as with vertical lists.

For convenience, I used the tinysort library here (I only just learned about it this morning – it’s very neat), which can also sort the elements in a meaningful way, not only randomly. But it would work exactly the same if you write manual code to reorder the elements.

Supporting drag-and-drop reordering

Getting to this point may have seemed complicated, but it has some great benefits. Since the animation and positioning is controlled entirely by CSS, it composes beautifully with many other techniques for modifying the DOM. For example, if a drag-drop library shuffles the DOM elements, then they will now animate.

As an example, we can throw in jQuery UI’s sortable mechanism to enable drag-drop reordering. But let’s make it slick, and also animate the “dropping” phase of the operation, where the element you dragged moves from wherever you’re holding it into its final position.

Here’s how you can do that:

$("ul.items").sortable({
    start: function (event, ui) {
        // Temporarily move the dragged item to the end of the list so that it doesn't offset the items
        // below it (jQuery UI adds a 'placeholder' element which creates the desired offset during dragging)
        $(ui.item).appendTo(this).addClass("dragging");
    },
    stop: function (event, ui) {
        // jQuery UI instantly moves the element to its final position, but we want it to transition there.
        // So, first convert the final top/left position into a translate3d style override
        var newTranslation = "translate3d(" + ui.position.left + "px, " + ui.position.top + "px, 0)";
        $(ui.item).css("-webkit-transform", newTranslation)
                    .css("transform", newTranslation);
        // ... then remove that override within a snapshot so that it transitions.
        $(ui.item).snapshotStyles().removeClass("dragging").releaseSnapshot();
    }
});

Here’s the result. Be sure to try this in a desktop browser, not a phone/tablet, because jQuery UI sortable doesn’t handle touch events by default. Also if you’re on IE, be sure to use IE10+ or you won’t see animations.

Weird flicker in Chrome? It only happens when the example is in this iframe. Try the “Edit in JSFiddle” link to see it without.

… and here’s a two-dimensional grid, with the same drag-drop code:

If you want better support for phones and tables, there are various ways of upgrading jQuery UI “sortable” to respond to touch events. Or write your own.

As a weekend project for the past few months, I’ve been building my first real mobile app: Touralot. Finally, it’s done, and it’s been approved on the iOS App Store!

Touralot lets you publish your own web-based guides to your favourite places to go and see. Maybe you’re off on vacation and would like to build a record of cool places you see, add photos, ratings, descriptions, plot them on a map, and then publish it all to the web. Or maybe you’re at home and are particularly knowledgeable about local restaurants, kids’ play centres, or whatever, and want to share your expertise.

This video gives a sense of the user experience:

Video looks blurry? Use a different browser, or open the video directly.

If you’re on an iPhone, you can get it now from the App Store (free).

The technology

Touralot is a Cordova/PhoneGap app, with the UI powered by Knockout.js, and a backend data service provided by Windows Azure Mobile Services (and a couple of other Azure facilities). It works entirely offline, except of course at the point where the user wants to log in and publish their stuff:

Why did I use HTML/JS and PhoneGap instead of native code (e.g., Objective-C)?

• I wanted to see how far I could push HTML/JS to match the quality experience that people expect from native apps. This includes:
  • Standardised UI elements that respond intuitively to touch, drag/drop, and swipe gestures
  • Butter-smooth hardware-accelerated transitions
  • Retina-sharp professional artwork
  • Offline/syncing support

  Assess the result for yourself – I don’t imagine that it would even occur to normal users, at least on reasonably up-to-date devices (iPhone 4S/5), that this isn’t native.

• This app can now be made cross-platform with relative ease. There’ll be some restyling effort involved, since Android and Windows Phone have different UI conventions, but hopefully it will mainly just be CSS changes.
• I don’t know much Objective-C…

Coming up

Over the next few weeks I’m planning a series of blog posts to describe many of the techniques I used and challenges I went through while developing this app, along with recommendations and tips for PhoneGap development. Some of these techniques are well known, some might even be original…

You can download Knockout 2.2.0 now from GitHub where we also have the source, and see the updated documentation and test suite.

What’s improved?

The theme for KO 2.2.0 was “all the small things”. We processed and closed many, many, many work items tracked on GitHub, fixed a bunch of niggly little issues, improved our code structure, and put in some enhancements we’ve been wanting for a while.

My favourite enhancement is that the foreach binding will now detect when you have reordered elements in an array, and will simply move the corresponding DOM elements into the new order (previously, a “move” was handled as an “add” and a “delete”). You don’t have to change your code to enable this – it just works, even if you’re moving, adding, and deleting multiple items as a single atomic operation. Example:

If you want to animate the movements of DOM nodes into their new positions, you can make use of the new beforeMove and afterMove callbacks.

We’ve also made some features work more like you might always have thought they should work. For example, the css binding can now attach programmatically-generated CSS class names to elements (previously, it was limited to toggling predefined CSS class names). Example:

Other improvements include: 

• The with, if, and ifnot bindings have been enhanced to preserve their original DOM elements on initial binding, so they are lighter and won’t unnecessarily strip out any special behaviours inserted by third-party libraries. I know a lot of people asked for this.
• The dependency detection mechanism is now smarter in many places to avoid registering subscriptions that would be unnecessary no-ops
• Support for IE10 (well, we basically already supported it, but there was one edge-case issue with autocompletion that we fixed)
• Improved AMD support (the ko variable is now available in the context of all custom binding handlers, even if it isn’t in global scope)
• The text binding can now be used in a virtual element (e.g., <!--ko text: myValue--><!--/ko-->)
• Observable and computed properties have a new peek function for advanced control over dependency detection
• Bugfixes

Big thanks to Michael Best and Ryan Niemeyer – my fellow KO core team members – and the many community members who contributed features, specs, and clearly-reproducible bug reports

I’ve been relying on it day-to-day for the last few months while working on a large JavaScript application, and now I’d be very distressed if I had to work without this instant, zero-effort safety net. So, what does it do?

1. It identifies definite, objective errors in your code (e.g., mistyped keywords, mistyped variable names, mismatched parentheses, and other syntactical slip-ups) before they end up in your browser.
2. Optionally, it enforces some basic code style consistency rules (e.g., no trailing whitespace, no use of the == operator, etc.), depending on how you configure it

Feature 2 – enforcing style consistency –  isn’t hugely beneficial for small, single-developer projects. But for longer-lived, multiple-developer projects, your team will surely benefit in the long run from a few consistency guarantees.

Feature 1 – typo detection – is the killer benefit from my point of view. I’ll show you a good example in a moment.

As you can probably guess, there are two common ways to use JSHint on a project:

• By integrating it into your build process (on a CI server). This enforces team-wide consistency.
• By integrating it into your IDE. This gives you instant feedback as you code.

My current project uses both, but primarily I appreciate having it in my IDE. So, in this post I’ll focus on a Visual Studio extension that makes it easy. Of course you can also find JSHint plugins for many other IDEs or code editors, such as my other favourite: Sublime Text 2.

Why it matters

Here’s an exaggeratedly simple example. Let’s say you have a perfectly OK function like this:

function averageHeight(heights) {
    var sum = 0, index;
    for (index = 0; index < heights.length; index += 1) {
        sum += heights[index];
    }
    return sum / heights.length;
}
 
var myAverageHeight = averageHeight([1.75, 1.78, 1.82]);

Now you decide you want to rename the function just to “average”, since it’s not really specific to heights at all. So you go ahead and change the function signature. But you forget to the change anything else:

function average(values) { // <-- This is the only line I remembered to change
    var sum = 0, index;
    for (index = 0; index < heights.length; index += 1) {
        sum += heights[index];
    }
    return sum / heights.length;
}
 
var myAverageHeight = averageHeight([1.75, 1.78, 1.82]);

Now you press Ctrl+S to save the changes. In the tiniest fraction of a second, and without waiting to build your server-side code, the JSHint extension I’m about to show you will return its verdict about your file:

Well, you’re going to notice this! The first three errors tell you exactly where you’ve forgotten to change “heights” to “values”, and they won’t go away until you fix every last one. The fourth warns you that you’re trying to invoke a function that no longer exists. The fifth tells you it’s quite pointless to have this new “average” function, because nobody uses it.

Even in this simple case it’s very nice to know exactly how many times you forgot to rename the “heights” variable. You can imagine how valuable (and reassuring) it is in more complex refactorings such as extracting a function.

I’m not saying this eliminates the need for automated testing. This merely adds to JavaScript a subset of the kinds of code validity checks that you might be accustomed to in C# or another strongly-typed language.

In addition, the kinds of optional common stylistic rules that JSHint can enforce include:

• Require braces around for/if/while/etc blocks
• Don’t leave “debugger” statements in your code
• Always use single/double quote characters
• Allow only one “var” statement per function scope, to ensure you don’t get hit by the subtle that-closure-isn’t-really-closed bug
• Well, just look at the list of “warn” options on the homepage

Possible drawbacks of JSHint

In the interest of balance, let me try to give you advance notice of a few downsides to using JSHint, which actually apply to pretty much any linting tool:

• It’s best when you’re writing fresh new code. When writing new code files, you can keep them compliant with your rules with little effort right from the beginning. But it’s not easy to start using JSHint on a large legacy codebase, because it will initially report thousands of violations. You can either invest a big chunk of time in cleaning everything up, or you can use /*ignore jslint */ comments to ignore your old files, removing those comments one-by-one as you clean up each file over the long term.
• It’s reliable, but not deeply sophisticated. JavaScript is fully dynamic, so the linter can’t know whether or not a given object will have a certain property at runtime. So, if for example you’re renaming properties as opposed to variables, don’t expect JSHint to find all the places where the old property name is still referenced. Don’t get caught believing that “no JSHint errors” guarantees “no bugs”.
• It needs a bit of configuration to give the best results. Depending on how you and your IDE work, you’ll need to toggle a bunch of checkboxes in the early days. You’ll get very annoyed if your IDE persistently inserts or reformats code in a way that violates your JSHint rules. Change the IDE settings or the JSHint settings or both.
• You need to start tracking global variables. In the long run, this is a benefit not a drawback, but it might feel like extra work at first. If you use third-party libraries whose APIs live in a global (e.g., $ for jQuery, ko for Knockout), you must explicitly tell JSHint about them otherwise it thinks you’re referencing undefined things. Eventually, though, you’ll be glad to have an unambiguous list of your dependencies.

So, what’s JSLint and how does it relate to JSHint?

Historically, JSHint is derived from the longer-established JSLint project from Douglas Crockford. The reason why JSHint exists is just to offer more flexibility: JSHint has a modest set of rules derived from common use, whereas JSLint is stricter and requires you to code exactly like the legendary Mr Crockford does.

The following Visual Studio extension lets you choose between JSLint and JSHint with a simple config option. Try out both and see which one you like.

Integrating JSHint into Visual Studio 2010

Yes, I know Visual Studio 2012 was just released this week! We’ll get to that in a minute. Not everyone upgrades during the first week…

The VS extension I’ve been using for the last few months is called JSLint for Visual Studio 2010. It’s free and open source, and you can install it directly from inside VS. Go to Tools > Extension Manager. Click Online Gallery then in the search box (top-right), enter jslint.

Once it’s installed, you’ll find a new menu entry: Tools > JS Lint Options. Personally, I like to set it up like this:

I’m not even going to discuss the multitude of code style options represented by the big grid of checkboxes. If you’ve coded JavaScript for a while, you probably have plenty of opinions of your own.

Notice that you can export and import configurations as XML files. You’ll probably want to store a standard team-wide setup in source control.

Now when you’ve got a JavaScript file open, any time you hit Ctrl+S, the Visual Studio extension will populate the IDE’s “Error” pane with any issues it found – extremely quickly, because it already has a live JavaScript runtime loaded in memory. Double-click to jump to that line. Either fix it, or modify your config settings to make the linter more tolerant.

Issues with this extension

Of course, it’s not totally perfect. Here are a couple of minor niggles I’ve experienced with this extension:

• I don’t see a way of making it load project-specific rulesets. This means that all of the projects you work on will need to share the same configuration (or you have to keep importing different configurations manually).
• It collects errors from every JavaScript file you open. So for example if you open jquery-x-x-x.js to see how something is implemented, JSLint for VS2010 will freak out and report more than 1,000 errors. The errors don’t go away when you close that particular tab, so you must manually right-click on the error list and choose Clear JS Lint Errors. Not a big deal, but adds a touch of friction.

Integrating JSHint into Visual Studio 2012

Unfortunately, there isn’t yet a “JSLint for Visual Studio 2012” on the extensions gallery, or at least not one that I could find. And if you try to download the .vsix file for the VS2010 version, it won’t let you install it into VS2012:

So, how come the screenshot earlier in this blog post shows it running in VS2012? Well, I guess the extension’s developers haven’t got round to testing on VS2012 yet, but if you’re impatient and want it installed right now, it’s just a matter of modifying the “manifest” in the .vsix file to make it allow installation. Here’s what I did:

1. Rename JSLint.VS2010.vsix to JSLint.VS2010.zip. Turns out these things are really zip archives. Extract the files to a temporary folder.
2. Open extension.vsixmanifest in Notepad.
3. Find <VisualStudio Version=”10.0″> and change it to <VisualStudio Version=”11.0″>.
4. Zip all the files back up, and rename the result so it has a .vsix extension.
5. Install it.

This is totally unsupported, off piste, entirely at your own risk, and no technical support questions will even be acknowledged much less answered. But hey, it seems happy enough on my machine:

Hopefully the extension’s developers will get a chance to make VS2012 support official in the near future. Maybe you (yes – actually you!) could submit a patch. This is open source, after all.

A week ago was the Throne of JS conference in Toronto, perhaps the most interesting and different conference I’ve been to for a while. Quoting its website:

It’s no longer good enough to build web apps around full page loads and then “progressively enhance” them to behave more dynamically. Building apps which are fast, responsive and modern require you to completely rethink your approach.

The premise was to take the seven top JavaScript frameworks/libraries for single-page and rich JavaScript applications — AngularJS, Backbone, Batman, CanJS, Ember, Meteor, Knockout, Spine — get the creators of all of them in one location, and compare the technologies head to head.*

Disclaimer: I was there to represent Knockout, so obviously I’m not neutral. In this post my focus is on what the creators said about the scope and philosophy of their technologies, and not so much on whether I agree or disagree.

* Yes, I know that’s eight frameworks, not seven. This part was never fully explained…

TL;DR Executive Summary

• For many web developers, it’s now taken for granted that such client-side frameworks are the way to build rich web apps. If you’re not using one, you’re either not building an application, or you’re just missing out.
• There’s lots of consensus among the main frameworks about how to do it (Model-View-* architecture, declarative bindings, etc. — details below), so to some extent you get similar benefits whichever you choose.
• Some major philosophical differences remain, especially the big split between frameworks and libraries. Your choice will deeply influence your architecture.
• The conference itself was stylish and upbeat, with a lot of socialising and conversations across different technology groups. I’d like to see more like this.

Technologies: Agreement and Disagreement

As each SPA technology was presented, some fairly clear patterns of similarity and difference emerged.

Agreement: Progressive enhancement isn’t for building real apps.

All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code.

Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s not even a novelty any more).

Agreement: Model-View-Whatever.

All the technologies made use of model-view separation. Some specifically talked about MVC, some about MVVM, and some specifically refused to define the third piece (just saying it’s models, views, and some kind of application thing that makes them work together). The net result in each case was similar.

Agreement: Data binding is good.

All except Backbone and Spine have a built-in notion of declarative data binding in their views (Backbone instead has a “bring your own view technology” design).

Agreement: IE 6 is dead already.

In a panel discussion, most framework creators said their IE support focus was limited to version 7+ (in fact, Ember and AngularJS only go for IE8, and Batman requires an ES5 shim to run on IE older than v9). This is the way of things to come: even jQuery 2 is set to drop support for IE older than v9.

The only stalwarts here appear to be Backbone and Knockout which support IE6+ (I don’t know about Backbone’s internals, but for KO this means transparently working around a lot of crazy edge-case IE6/7 rendering and eventing weirdnesses).

Agreement: Licensing and source control.

Every single one is MIT licensed and hosted on GitHub.

Disagreement: Libraries vs frameworks.

This is the biggest split right now. You could group them as follows:

Numbers in brackets are a point-in-time snapshot of the number of GitHub watchers, as a crude indicator of relative influence.

What does this mean?

• Libraries slot into your existing architecture and add specific functionality
• Frameworks give you an architecture (file structure, etc.) that you are meant to follow and, if you do, are intended to handle all common requirements

By far the most passionate advocate of the framework model is Ember, whose creator Yehuda Katz is formerly of the Rails and SproutCore projects (similar philosophy). His argument was that anything less is just not ambitious enough and isn’t seriously advancing the state of the art. The counter-argument is that libraries are more focused, and hence can be easier to learn, adopt, customize, and help minimise project risk because your architecture isn’t so deeply tied to a specific external project. Based on my conversations, I’d say the audience was split and supported both sides of this debate.

Note that AngularJS is arguably somewhere in between library and framework: it doesn’t require a particular layout of files at development time (library-like), but at runtime it provides an “app lifecycle” that you fit your code into (framework-like). I’m listing it as a framework because that’s the terminology the AngularJS team prefers.

Disagreement: What’s flexible, what’s integrated.

Each technology has different levels of prescriptiveness:

As expected, whenever a library leaves a decision open, they argue it is better overall to guarantee composablity with arbitrary 3^rd-party libraries. And the obvious counter-argument is that integration can be more seamless if built-in. Again, based on my conversations, the audience was split and opinions went in all directions — usually based on how much other technology stack an individual was wedded to.

Quote from Tom Dale of Ember: “We do a lot of magic, but it’s good magic, which means it decomposes into sane primitives.“

Disagreement: String-based vs DOM-based templates

(As shown in the above table.) For string-based templates, almost everyone used Handlebars.js as the template engine, which seems to dominate this space, though CanJS used EJS. Arguments in favour of string-based templates include “it’s faster” (debatable) and “theoretically, the server can render them too” (also debatable, as that’s only true if you can actually run all of your model code on the server, and nobody actually does that in practice).

DOM-based templates means doing control flow (each, if, etc.) purely via bindings in your actual markup and not relying on any external templating library. Argument include “it’s faster” (debatable) and “the code is easier to read and write, because there’s no weird chasm between markup and templates, and it’s obvious how CSS will interact with it“.

In my view, the strongest argument here came from the AngularJS guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. AngularJS is from Google, so they are already working on this with Chromium and standards bodies.

Disagreement: Levels of server-agnosticism

Batman and Meteor express explicit demands on the server: Batman is designed for Rails, and Meteor is its own server. Most others have a goal of being indifferent to what’s on your server, but in practice the architecture, conventions, and some tooling in Ember leans towards Rails developers. Ember absolutely works on other server technologies too, though today it takes a little more manual setup.

The technologies — quick overview

Here’s a rundown of the basic details of each technology covered:

Backbone

• Who: Jeremy Ashkenas and DocumentCloud
• What:
  • Model-View in JavaScript, MIT licensed
  • Most minimal of all the libraries — only one file, 800 lines of code!
  • Extremely tightly-scoped functionality — just provides REST-persistable models with simple routing and callbacks so you know when to render views (you supply your own view-rendering mechanism).
  • The best-known of them all, with the most production deployments on big-name sites (perhaps easy to adopt because it’s so minimal)
• Why:
  • It’s so small, you can read and understand all of the source before you use it.
  • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
  • Jeremy seems to exist in a kind of zen state of calm, reasonable opinions about everything. He was like the grown up, supervising all the arguing kids.
• Where: GitHub and own site
• When: In production for nearly 2 years now

Meteor

• Who: The Meteor development group, who just raised $11.2 Million so they can do this full-time
• What:
  • Crazy amazing framework from the future, barely reminiscent of anything you’ve ever seen (except perhaps Derby)
  • Bridges a server-side runtime (on Node+Mongo) with a client-side one, so your code appears to run on both, including the database. WebSockets syncs between all client(s) and server.
  • Does “live deployments” every time you edit your code – client-side runtimes are updated on the fly without losing their state
  • Makes more sense if you watch the video
  • Like everyone I spoke to at the event, I really want this to succeed — web development needs something this radical to move forwards
• Why: You’ve had enough of conventional web development and now want to live on the bleeding edge.
• Where: GitHub and own site
• When: It’s still early days; I don’t know if there are any production Meteor sites yet except built by the core team. They’re totally serious about doing this, though.

Ember

• Who: Yehuda Katz (formerly of jQuery and Rails), the Ember team, and Yehuda’s company Tilde
• What:
  • Everything you need to build an “ambitious web application”, MIT license
  • Biggest framework of them all in both functionality and code size
  • Lots of thought has gone into how you can decompose your page into a hierarchy of controls, and how this ties in with a statemachine-powered hierarchical routing system
  • Very sophisticated data access library (Ember.Data) currently in development
  • Intended to control your whole page at runtime, so not suitable for use in small “islands of richness” on a wider page
  • Pretty heavily opinionated about files, URLs, etc., but everything is overridable if you know how
  • Design inspired by Rails and Cocoa
  • Tooling: They supply project templates for Rails (but you can use other server platforms if you write the code manually)
• Why: Common problems should have common solutions — Ember makes all the common solutions so you only have to think about what’s unique to your own application
• Where: GitHub and own site
• When: Not yet at 1.0, but aiming for it soon. API will solidify then.

AngularJS

• Who: Developed by Google; used internally by them and MIT licensed.
• What:
  • Model-View-Whatever in JavaScript, MIT licensed
  • DOM-based templating with observability, declarative bindings, and an almost-MVVM code style (they say Model-View-Whatever)
  • Basic URL routing and data persistence built in
  • Tooling: they ship a Chrome debugger plugin that lets you explore your models while debugging, and a plugin for the Jasmine testing framework.
• Why:
  • Conceptually, they say it’s a polyfill between what browsers can do today and what they will do natively in a few years (declarative binding and observability), so we should start coding this way right now
  • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
• Where: GitHub and own site
• When: In production now (has been at Google for a while)

Knockout

• Who: The Knockout team and community (currently three on the core team, including me)
• What:
  • Model-View-ViewModel (MVVM) in JavaScript, MIT licensed
  • Tightly focused on rich UIs: DOM-based templates with declarative bindings, and observable models with automatic dependency detection
  • Not opinionated about URL routing or data access — combines with arbitrary third-party libraries (e.g., Sammy.js for routing and plain ajax for storage)
  • Big focus on approachability, with extensive documentation and interactive examples
• Why:
  • Does one thing well (UI), right back to IE 6
  • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
• Where: GitHub and own site
• When: In production for nearly 2 years now

Spine

• Who: Alex MacCaw
• What:
  • MVC in JavaScript, MIT license
  • Worked example originally written for an O’Reilly book grew into an actual OSS project
  • Is a kind of modified clone of Backbone (hence the name)
• Why: You like Backbone, but want a few things to be different.
• Where: GitHub and own site
• When: It’s past v1.0.0 now

Batman

• Who: the team at Shopify (an eCommerce platform company)
• What:
  • MVC in JavaScript, almost exclusively for Rails+CoffeeScript developers, MIT licensed
  • Most opinionated of them all. You must follow their conventions (e.g., for file layout and URLs) or, as they say in their presentation,”go use another framework“
  • Full-stack framework with pretty rich models, views, and controllers and routing. And observability mechanism of course.
  • DOM-based templating.
• Why: If you use Rails and CoffeeScript, you’ll be right at home
• Where: GitHub and own site
• When: Currently at 0.9. Aiming for 1.0 in coming months.

CanJS

• Who: the team at Bitovi (a JavaScript consulting/training company)
• What:
  • MVC in JavaScript, MIT licensed
  • REST-persistable models, basic routing, string-based templating
  • Not widely known (I hadn’t heard of it before last week), though is actually a reboot of the older JavaScriptMVC project
• Why: Aims to be the best of all worlds by delivering features similar to the above libraries while also being small
• Where: GitHub and own site
• When: Past 1.0 already

Summary

If you’re trying to make sense of which of these is a good starting point for your project, I’d suggest two questions areas to consider:

• Scope. How much do you want a framework or library to do for you? Are you starting from blank and want a complete pre-prepared architecture to guide you from beginning to end? Or do you prefer to pick your own combinations of patterns and libraries? Either choice has value and is right for different projects and teams.
• Design aesthetic. Have you actually looked at code and tried building something small with each of your candidates? Do you like doing it? Don’t choose based on descriptions or feature lists alone: they’re relevant but limited. Ignoring your own subjective coding experience would be like picking a novel based on the number of chapters, or a spouse based on their resume/CV.

Despite the differences, I’d argue there is one killer feature all the above technologies share: the idea of Model/View separation. This is a classic design pattern that predates the web itself by about 20 years. If you’re building even the most basic kind of web application UI, you’ll almost certainly benefit from applying this on the client.

1. Getting started with Node and Express using WebMatrix 2 — 12 minutes
2. Building a web app with static UI / dynamic API architecture — 20 minutes
3. (This post) Hints and tricks for optimising for mobiles — 14 minutes

This third video puts the focus on mobile devices, which is the main target audience for our app. You’ll see ways of improving the user experience on small screens, using caching to make the app load incredibly quickly even over a low-bandwidth connection, and pushing real-time updates to clients. Finally you’ll see a few iOS-specific tricks.

Here’s the video. Be sure to watch it full-screen in 720p quality, by the way, for the most readable code…

Want to download the code?

As before, the source repo is on GitHub. Or, you can download the exact version of the code corresponding to the end of the part 3 video.

1. Getting started with Node and Express using WebMatrix 2 — 12 minutes
2. (This post) Building a web app with static UI / dynamic API architecture — 20 minutes
3. Hints and tricks for optimising for mobiles — 14 minutes

In this second video, we build on the Node.js + Express skills learned in the first video, and create a fun social web app that demonstrates how you can totally separate your application’s UI from its underlying API by using Express’s ability to mount one application inside another. This isn’t only about keeping your code tidy: it also enables some dramatic performance benefits, as you’ll see in Part 3, and means you could easily attach multiple UI technologies to the same underlying backend.

OK, here’s the video. Be sure to watch it full-screen in 720p quality, by the way, for the most readable code…

Want to download the code?

If you want to get a closer look at the code created in this tutorial, you can download the version corresponding to the end of part 2, or browse the whole source repo on GitHub.

Delay no longer! Get WebMatrix 2 (Release Candidate) and it will take care of installing all the bits you need (Node, Node Package Manager, and IISNode), and will give you a first-rate IDE experience including fancy features like autocompletion that understands Node packages and conventions.

Tutorial videos

So then, what can you do with Node and WebMatrix? This is the first in a three-part series of videos about building a mobile web app with Node.js, Express, and WebMatrix:

1. (This post) Getting started with Node and Express using WebMatrix 2 — 12 minutes
2. Building a web app with static UI / dynamic API architecture — 20 minutes
3. Hints and tricks for optimising for mobiles — 14 minutes

The material is based on a talk I gave at DevSum in Stockholm a month or two back.

OK, here it is! Be sure to watch it full-screen in 720p quality, by the way, for the most readable code…

With this release we welcome new core team member Michael Best, who implemented a lot of the 2.1.0 goodness. One of my favourite new features is the $index context variable. Here’s a short usage example:

The cool thing is that $index is an observable and is updated automatically as you add or remove items in any collection bound to a foreach (and so your UI will update to match). Impressively, Michael was able to add this new functionality while simultaneously improving the performance of foreach whether or not you are using $index!

We also benefited from pull requests, issue reports, and feature suggestions from many others in the community. Special thanks to neonstalwart and mtscout6 for not only implementing AMD module loader support and putting up with a lot of questions from me, but even including full documentation pages in their pull request – flawless OSS etiquette!

Again, if you want to know more about what’s new in KO 2.1.0, head on over to Ryan’s post for a full rundown.