As per the project description:

“Backbone supplies structure to JavaScript-heavy applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing application over a RESTful JSON interface.”

There are a ton of good ‘getting started’ posts out there, so rather than duplicate those I thought I would put together a few of my favorite resources. Hopefully some of you might find them useful.

• Backbone.js : The main github site- Here you will find valuable reference documentation as well a simple examples to introduce you to backbone. Be prepared to spend a little time here
• Underscore.js : “It’s the tie to go along with jQuery‘s tux, and Backbone.js‘s suspenders.”  If you haven’t heard about underscore do yourself a favor on go check it out. There is nothing magical about it, yet I can’t say enough. Even if you aren’t using backbone, I highly recommend this library (some folks are using it on the server with node.js as well).
• Todo.js : A simple Todo list example using backbone.js
• TodoMVC : Compare a truck load of JS MVC frameworks – “a project which offers the same Todo application implemented using MVC concepts in most of the popular JavaScript MVC frameworks of today.”
• Backbone.js Fundamentals : A book on Backbone.js targeted at beginners and advanced users alike – by Addy Osmani (and contributors). This guide is quickly becoming the ‘mini-bible’ for backbone. Chalked full of nuggets, from beginning concepts to the more advanced.
• The Backbone Boilerplate : “Backbone Boilerplate is a set of best practices and utilities for building Backbone.js applications”
• Organizing Your Backbone.js Application With Modules : Some guidance around how you might structure your application using modules (esp valuable for larger applications).
• Organizing your application using Modules (require.js) : Similar to the previous article, but makes use of AMD & Require.js to wire up the application.
• Derick Baileys blog on Lostechies : Derick has been blogging on backbone for 6 mos or so. I appreciate reading Dericks blog because he has done such a good job of cataloging his experiences as he has learned the framework. When I found myself stumbling with backbone, my searches often led over to Dericks blog.
• Backbone.js Screencast – Introduction and Views : A nice “basic introduction on how to bootstrap a new Backbone.js application and go in-depth on how to use Backbone Views in particular”. Joey now also has screencasts available over at his site http://backbonescreencasts.com/
• Backbone.js walkthrough of Models and Views (Part 1/2) Screencast : Enough said!
• Using node.js + backbone.js + socket.io for real-time goodness : I haven’t actually implemented this yet, but am excited about the possibilities. Check out here here and here for some examples. (seeing how the middle tier in this app is MVC.net, I may opt to swap socket.io for signalR. Hoping to take the node.js plunge at some point).

Updated:

• http://backbonetraining.net/resources : Excellent collection of resources
• http://recipeswithbackbone.com/ : Strategies to accelerate development
  with Backbone.js ($24 e-book)

That’s all for now. Please feel free to reach out with any other resources you found helpful and Ill add them on here. I am still very much learning and would love to read your posts. More to come-

1. Functions
2. Objects
3. Prototypes
4. Enforcing New on Constructor Functions
5. Hoisting
6. Automatic Semicolon Insertion
7. Static Properties and Methods
8. Namespaces
9. Reusing Methods of Other Objects
10.   The Module Pattern
11.   Functional Initialization

In a previous post I already discussed the phenomenon of hoisting in JavaScript. In that post I showed the effects of variable hoisting and why it’s important to declare all variables at the top of a function body. For this post I want to briefly focus on function hoisting. Let’s start off with an example to illustrate this concept.

functionExpression();        // undefined
functionDeclaration();        // "Function declaration called."        

var functionExpression = function() {
    console.log('Function expression called.');
};

functionExpression();        // "Function expression called."
functionDeclaration();        // "Function declaration called."

function functionDeclaration() {
    console.log('Function declaration called.');
}

functionExpression();        // "Function expression called."
functionDeclaration();        // "Function declaration called."

In order to understand what’s going on here, we first need to understand the distinction between a function expression and a function declaration. As it’s name implies, a function expression defines a function as part of an expression (in this case assigning it to a variable). These kind of functions can either be anonymous or they can have a name.

// 
// Anonymous function expression
//
var functionExpression = function() {
    console.log('Function expression called.');
};

// 
// Named function expression
//
var functionExpression = function myFunctionExpression() {
    console.log('Function expression called.');
};

On the other hand, a function declaration is always defined as a named function without being part of any expression.

So, for the example shown earlier, the function expression can only be called after it has been defined while the function declaration can be executed both before and after it’s definition. Let’s look at how JavaScript actually interprets this code in order to explain why it behaves that way.

var functionExpression,        // undefined
    functionDeclaration =  function() {
        console.log('Function declaration called.');
     };

functionExpression();        // Still undefined
functionDeclaration();        // "Function declaration called."        

// The assignment expression is still left at the original location
// although the variable declaration has been moved to the top. 
functionExpression = function() {
    console.log('Function expression called.');
};

functionExpression();        // "Function expression called."
functionDeclaration();        // "Function declaration called."

// Here we originally defined our function declaration
// which has been completely moved to the top.

functionExpression();        // "Function expression called."
functionDeclaration();        // "Function declaration called."

JavaScript turns our function declaration into a function expression and hoists it to the top. Here we see the same thing happening to our function expression as I explained in the previous post on variable hoisting. This also explains why the first call of our function expression results in an error being thrown because the variable is undefined.  

So basically, JavaScript applies different rules when it comes to function hoisting depending on whether you have a function expression or a function declaration. A function declaration is fully hoisted while a function expression follows the same rules as variable hoisting. It definitely took me a while to wrap my head around this.

Until next time.

1. Functions
2. Objects
3. Prototypes
4. Enforcing New on Constructor Functions
5. Hoisting
6. Automatic Semicolon Insertion
7. Static Properties and Methods
8. Namespaces
9. Reusing Methods of Other Objects
10.  The Module Pattern

I just want to quickly share some beautiful JavaScript code I picked up while watching the most excellent screencast 11 More Things I Learned from the jQuery Source by Paul Irish.

var base = dom.getElementByTagName('base')[0] | | (function() {
     // Do some stuff
     return someElement.insertBefore(dom.createElement('base'), someElement.firstChild) ;
})(); 

This single line of code basically checks whether there’s a base tag somewhere in the DOM. If there is one, then it assigns the reference for the first element to the base variable. If it’s not in the there, then a self-executing function inserts a new base tag into the DOM and returns the reference to the new element.

I don’t know about you, but I think this is pretty neat.

1. Functions
2. Objects
3. Prototypes
4. Enforcing New on Constructor Functions
5. Hoisting
6. Automatic Semicolon Insertion
7. Static Properties and Methods
8. Namespaces
9. Reusing Methods of Other Objects

The module pattern is quite popular in the JavaScript community as is heavily applied by many JavaScript developers. There’s also the CommonJS initiative, which defines a specification for a common set of JavaScript API’s that are organized using self-contained modules. These specifications are supported by a growing community as they provide the foundation for the modules that are built into Node.js and numerous other open-source JavaScript libraries. This pattern has become so widespread because it’s an excellent way to package and organize an independent, self-containing piece of JavaScript code. The module pattern is composed by using self-executing functions combined with namespaces. Let’s show a simple example.

namespace('media');

media.podcast = (function(name) {
    var fileExtension = 'mp3';        

    function determineFileExtension() {
        console.log('File extension is of type ' + fileExtension);
    }

    return {
        download: function(episode) {
            console.log('Downloading ' + episode + ' of ' + name);
            determineFileExtension();
        }
    }
}('Astronomy podcast'));

First we define a namespace called media. Then we use a self-executing function that returns an anonymous object with a method named download that can be invoked by external code. Inside the self-executing function we have a variable fileExtension and a function determineFileExtension that are private and can only be used inside the module. Notice that we provide a fixed parameter value for the self-executing function. This technique is usually applied to pass in some kind of global object. jQuery uses this same approach to inject a reference to the global window object into the scope of its module.

We can use the download method of our module like so …

media.podcast.download('the first episode');

… which outputs what we expect:

Downloading the first episode of Astronomy podcast

File extension is of type mp3

The way we implemented the module pattern here has at least one major downside. We’re able to completely replace the implementation of the download method that is exported by the anonymous object returned from the self-executing function. This can become quite troublesome if we have other functions inside our module that also make use of the download method and thereby rely on its functionality. The way to fix this issue is to make all functions private and export them using the anonymous object:

namespace('media');

media.podcast = (function(name) {
    var fileExtension = 'mp3';        

    function determineFileExtension() {
        console.log('File extension is of type ' +fileExtension);
    }

    function download(episode) {
        console.log('Downloading ' + episode + ' of ' + name);
        determineFileExtension();
    }

    return {
        download: download
    }
}('Astronomy podcast'));

The download method exposed by the anonymous object can still be replaced, but at least the correct implementation is preserved by the private download function for other functions that rely on its behavior. This approach is commonly called the “revealing module pattern”. 

Another neat approach is to export a constructor function instead of an anonymous object.

namespace('media');

media.Podcast = (function() {
    var fileExtension = 'mp3';        

    function determineFileExtension() {
        console.log('File extension is of type ' +fileExtension);
    }

    var podcastConstructor = function Podcast(name) {
        if(false === (this instanceof Podcast)) {
            return new Podcast();
        }

        this.getName = function() {
            return name;
        }
    }

    podcastConstructor.prototype.download = function (episode) {
        console.log('Downloading ' + episode + ' of ' + this.getName());
        determineFileExtension();
    }

    return podcastConstructor;
}());

Instead of returning an anonymous object from our self-executing function, we create another function and add the download method to the prototype of this constructor function. Notice that we also moved the name parameter to the constructor function instead of passing it into the self-executing function. At the end of the self-executing function we just return this constructor function like we did with the anonymous object.

We can now use this module like so …

var astronomyCast = new media.Podcast('Astronomy podcast');
astronomyCast.download('the first episode');

… which yields the same output as before.

The module pattern is a very powerful concept in JavaScript. Being able to expose and use JavaScript code, treating it as a black box, is a very common technique that is used in lots of JavaScript libraries and frameworks.

Happy coding!

1. Introduction
2. Threads vs. Events
3. Using Non-Standard Modules
4. Debugging with node-inspector
5. CommonJS and Creating Custom Modules

The community around Node.js is definitely thriving at the moment. As a consequence, new versions of Node.js are being released very rapidly. While the 0.2.x versions of Node.js are considered stable, the 0.3.x versions contain all the new features and latest enhancements. I usually develop against the more stable 0.2.x versions of Node.js while spiking the new stuff in the latest 0.3.x versions in order to get a feel of what’s coming. This means that we need to manage multiple versions of Node.js on our development box while being able to easily switch between the different binaries.

There are a couple of alternative solutions out there that deal with the issue of version management for Node.js. First, there’s nvm which is a simple bash script for managing multiple versions of Node.js. Then there’s also nave which is another shell script that basically does the same thing. But the solution that I’m currently using and going to discuss in this blog post is a tool called n.

We can very easily install n with npm by issuing the following command:

npm install n

Installing a particular version of node.js is a easy as executing n, specifying the version number:

n 0.2.6

n will get the source code for the requested version and automatically configures/compiles in order to get the binaries. The last version that gets installed this way also automatically becomes the active binary. If we just want to install the latest version of Node.js, we can also use the following command:

n latest

We can easily check which versions of Node.js that we have installed on our development machine by just executing the following command:

n

which outputs something like this:

   0.2.3

o 0.2.6

   0.3.7

You can also check the current version of node.js by executing the following command:

node — version

Running a Node.js application is still done using the same command as before:

node server.js

Changing the current active version of Node.js is as simple as executing the same command that we used for installing that particular version:

n 0.2.3

This switches the used version of Node.js back to v0.2.3. We can also run an application using a particular version, overriding the current active version:

n use 0.2.6 server.js

Removing a particular version is pretty easy as well. Just use the following command:

n rm 0.2.3

That’s it! Being able to quickly switch between the many different versions of Node.js has been a huge time-saver for me so far. 

Until next time.  

1. Introduction
2. Threads vs. Events
3. Using Non-Standard Modules
4. Debugging with node-inspector

In a previous blog post, I already discussed how to make use of the built-in and third-party modules inside a Node.js application. For this post I’m going to briefly touch on CommonJS and show how to create custom modules.

Most programming languages out there, like Java, Ruby, Python, C#, C++, etc …,  all come with some sort of standard library that provides developers with an API for building all kinds of applications on a variety of platforms. These libraries and/or frameworks provide all kinds of basic functionality for accessing the file system, doing network I/O, parsing command-line arguments, etc. … . Unfortunately, JavaScript doesn’t come with such a standard library. This is something that the CommonJS initiative is trying to fix. CommonJS tries to go beyond the standard JavaScript specification by defining a common set of API’s for building a broad range of systems like command-line, server-side and GUI applications. If you’re interested, you can have a look at the current specifications and proposals in development.

What does this have to do with Node.js? Well, Node.js implements the CommonJS specification for its built-in modules. Knowing how to leverage your own custom modules is not only very important for structuring your Node.js applications but also recommended for providing portability with other CommonJS compliant frameworks like narwhal. Creating a custom module is very easy. We just have to provide a JavaScript file, name it after the module that we want create and add the necessary JavaScript code. That’s it!

Let’s look at a very simple example of how to build such a custom module using the CommonJS system provided by Node.js. Suppose that we want to create a module named podcast that exposes functionality for downloading .mp3 files. As mentioned earlier, we have to create a JavaScript file named podcast.js and add the necessary JavaScript code that provides the download functionality.

exports.download = function(episode) {
    console.log('Downloading: ' + episode);
}

A slight variation to this that I see quite often used both in the built-in as the third-party modules looks like the following:

var podcast = exports;

podcast.download = function(episode) {
    console.log('Downloading: ' + episode);
}

In order to use this exciting new piece of code, we just have to add a require statement to our client code and we’re good to go:

var podcast = require("./podcast");
podcast.download('Astronomy podcast #89');

This might look very simple and easy but there’s plenty going on behind the scenes. First of all, Node.js ensures that the content of the JavaScript file that makes up our custom module gets loaded into its own scope. By doing this, Node.js automatically prevents naming collisions with other modules. When loading our custom module, Node.js provides a number of objects like module, exports and require. These are also called pseudo globals.

We use the exports object for exposing public members to external code. You can consider exports as the this reference for our module. This also means that we can just add regular JavaScript functions to our custom module without adding them to the global namespace and without the external code being able to call these ‘private’ functions as long as we don’t add them to the exports object.

var podcast = exports;

podcast.download = function(episode) {
    downloadDataFor(episode);
}

function downloadDataFor(episode) {
    console.log('Downloading: ' + episode);
}

The external code is not able to call the downloadDataFor function which is only available inside our custom module:

var podcast = require("./podcast");
podcast.download('Astronomy podcast #89');

console.log(typeof podcast.download);            // function
console.log(typeof podcast.downloadDataFor);    // undefined
console.log(typeof downloadDataFor);            // undefined

I just mentioned that a module is provided with a couple of pseudo global objects. One of these is named module which provides a reference to the current instance of the module. This means that we are able to replace the reference that is hold by the exports property of the current module in order to provide a single export per JavaScript file. Let’s talk code: 

function Podcast() {
    if(false === (this instanceof Podcast)) {
        return new Podcast();
    }
}

Podcast.prototype.download = function(episode) {
    console.log('Downloading: ' + episode);
}

module.exports = Podcast;

We now have to use restructure the client code as well:

var Podcast = require("./podcast");

var astronomyCast = new Podcast();
astronomyCast.download('Astronomy podcast #89');

The advantage of this approach is that both the code of our custom module as well as the client code are organized in the same way as we would write regular JavaScript objects. 

I can only hope that the CommonJS initiative succeeds in its goals by providing a common set of API’s that can be used for building a wide range of applications using JavaScript. Using modules interchangeably on all kinds of platforms still sounds very appealing .

Until next time.

1. Functions
2. Objects
3. Prototypes
4. Enforcing New on Constructor Functions
5. Hoisting
6. Automatic Semicolon Insertion
7. Static Properties and Methods
8. Namespaces

In one of my previous posts, I mentioned that functions in JavaScript are plain objects that can have their own properties and methods. One of these methods that are available for every function object is a method named call(), which is defined on the prototype of Function. This method allows you to ‘reuse’ a method from another object. Let’s talk code.Suppose we have an object called podcast which has a download() function:

var podcast = {
    name : 'Astronomy podcast',
    download : function(episode) {
        console.log('Downloading ' + episode + ' of ' + this.name);
    }
};

podcast.download('the first episode');

The output we get by executing this function is exactly what we expect it to be:

“Downloading the first episode of Astronomy podcast”

Now suppose we bring on another object called screencast :

var screencast = {
    name: 'Node tuts'
};

Wouldn’t it be nice if we could somehow reuse the download() method of the podcast object so that we can download a screencast as well. We can do this by invoking call() on the download() method like so: 

podcast.download.call(screencast, 'the last episode');

This gives us the following output:

“Downloading the last episode of Node tuts”

What exactly happened here? Well, we just invoked the call() method on the download function object, specifying a reference to the screencast object and a string argument that describes the particular episode. The download() method got invoked with the screencast object bound to this. Therefore, the download() method uses the name property of the screencast object instead of the name of the podcast object.

There’s also another method with similar functionality defined on the Function prototype named apply(). This method behaves exactly the same as the call() method, except that the arguments passed to the underlying method in question need to be passed as an array.

podcast.download.apply(screencast, ['the last episode']);

Utilizing the call()/apply() methods is a very powerful way to reuse features of objects that are built into JavaScript (like Array, String, etc. …) or from third-party libraries. But I don’t recommend applying this technique when you own the code of the method you want to reuse. A simple refactoring like extracting the particular method into another object is a much better approach.

Until next time.

1. Functions
2. Objects
3. Prototypes
4. Enforcing New on Constructor Functions
5. Hoisting
6. Automatic Semicolon Insertion
7. Static Properties and Methods

In my previous post, I showed how you can ‘emulate’ static members in JavaScript without having a dedicated syntax for it. For this post, I’m going to discuss namespaces in JavaScript. In order to reduce the number of objects and functions that are added to the global scope in our applications, using namespaces in JavaScript is definitely a recommended practice. Just like static members, namespaces don’t have any dedicated syntax built into the language either. But we’re able to get the same benefits by creating a single global object and adding all our objects and functions to this object.

var AppSpace = AppSpace || {};

AppSpace.Podcast = function {
    this.title = 'Astronomy Cast';
    this.description = 'A fact-based journey through the galaxy.';
    this.link = 'http://www.astronomycast.com';
};

AppSpace.Podcast.prototype.toString = function() {
    return 'Title: ' + this.title;
}

This way we lower the possibility of naming collisions when using our code in conjunction with other JavaScript libraries. We can also use the same naming conventions for namespaces as in any other programming language that does provide syntactical support. Suppose we want to use a namespace like “MyCompany.MyApplication.Model”. We can accomplish this by using the same approach as shown earlier:

var MyCompany = MyCompany || {};
MyCompany.MyApplication = {};
MyCompany.MyApplication.Model = {};

or something like the following:

var MyCompany = MyCompany || {
    MyApplication: {
        Model: {}
    }
};

However, this approach can become very cumbersome and hard to maintain when our code expands over time. In order to overcome this issue we can use a general purpose namespace function to achieve the same thing using a single line of code.

var model = namespace('MyCompany.MyApplication.Model');

model.Podcast = function {
    this.title = 'Astronomy Cast';
    this.description = 'A fact-based journey through the galaxy.';
    this.link = 'http://www.astronomycast.com';
};

model.Podcast.prototype.toString = function() {
    return 'Title: ' + this.title;
}

Here’s an example of how we can implement such a namespace function.

function namespace(namespaceString) {
    var parts = namespaceString.split('.'),
        parent = window,
        currentPart = '';    

    for(var i = 0, length = parts.length; i < length; i++) {
        currentPart = parts[i];
        parent[currentPart] = parent[currentPart] || {};
        parent = parent[currentPart];
    }

    return parent;
}

Using this approach requires less typing and the resulting code also looks less verbose. Some JavaScript libraries, like YUI and the Dojo Toolkit, provide their own implementations for such a namespace utility function. I encourage you to take a look at their implementations as well.

Until next time. 

1. Functions
2. Objects
3. Prototypes
4. Enforcing New on Constructor Functions
5. Hoisting
6. Automatic Semicolon Insertion

In this post, I’m going to quickly show you how to set up static properties and methods in JavaScript. This can come in handy for constant values and/or utility functions. C# and most other class-based languages have a special syntax for static members. Not so for JavaScript. Although JavaScript doesn’t provide a dedicated syntax for static members, we’re still able to get what we want by adding properties and methods to a constructor function. This is possible because functions in JavaScript are plain objects that can have properties and methods of their own. 

Let’s show some code.

function Podcast() {};

Podcast.FILE_EXTENSION = 'mp3';
Podcast.download = function(podcast) {
    console.log('Downloading ' + podcast + ' ...');
};

Podcast.prototype.play = function() {
    console.log('Playing this podcast ...');
};

Here we created a constructor function named Podcast with a static property called FILE_EXTENSION and a static method named download. We also added the instance method play() to the prototype of our constructor function.

Getting the value of a static property or invoking a static method is done as follows:

Podcast.FILE_EXTENSION;                // 'mp3'
Podcast.download('Astronomy cast');    // 'Downloading Astronomy cast ...'

When we create a Podcast object and invoke the instance method play(), we obviously get the expected outcome.

new Podcast().play();    // 'Playing this podcast ...'

But it’s surely not possible to statically invoke an instance method like so:

Podcast.play();        // undefined

It’s also not possible to invoke a static method on a Podcast instance object either.

new Podcast().download('Railscasts');    // undefined

There you go. Knowing how to provide static members in JavaScript might come in handy when you feel inspired of writing your own Math class in JavaScript .

Until next time.

1. Introduction
2. Threads vs. Events
3. Using Non-Standard Modules

Writing unit tests for your code drastically reduces the amount of debugging. This is the case for practically any programming language that you work in. But when the shit hits the fan, having a debugger with some decent features at your disposal is a must. However Node.js doesn’t come with a debugger out of the box. Thankfully there are a couple of debuggers out there like ndb, node-debug and node-inspector, which I’ll going to be demonstrating in this blog post. For this blog I’m going to show you some of the nice capabilities of node-inspector.

Installing node-inspector is actually pretty easy when you have npm installed. Just issue the following command:

npm install node-inspector

Now we can startup node-inspector …

node-inspector &

which shows the following output if all goes well:

Now that we have node-inspector running, we can start debugging our node.js application in another console:

node --debug server.js

which outputs the port on which the debugger is listening.

Now you can open Chrome and point it to the following URL:

http://127.0.0.1:8080/

If all goes well, then we’ll get to see some JavaScript source code:

Note that you’ll have to use Chrome or another WebKit based browser for opening node-inspector. I also tried it in Firefox, but the page doesn’t show at all.

You can then select the JavaScript source file that contains the code you wish to debug and add breakpoints like you would normally do in an IDE like Visual Studio.

Now we can start using our application until we hit a breakpoint.

On the right of the page we can add watch expressions, look at the call stack and the current values of the scope variables. In the code window we have the usual suspects like “Step over”, “Step into next function” and “Step out of current function”. We can even do live editing and all of this right in the browser! Tooltips also work as expected.

Another nice feature is the console window that can be shown/hidden below or taking over the entire window by clicking the menu button at the top of the page.

Because I’ve been using version 0.2.3 for developing my very first application using Node.js, I had to install an older version of node-inspector. If you decide to use the latest version of Node.js, you will see that a couple of interesting new features have been added, like heap snapshots. Make sure to watch this short screen cast to get up and running in no time with node-inspector.

Using node-inspector while developing Node.js applications can really save you a lot of grief. It certainly helped me to find a couple of bugs that would otherwise be hard to track down. It’s also a great learning tool if you would like to learn more about how Node.js behaves at runtime.

Until next time.