O'Reilly logo

Node for Front-End Developers by Garann Means

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 1. Getting Node Set Up

Depending on your environment, Node is easy to set up or very easy to set up. Node runs on Unix-compatible systems and, more recently, Windows. The former means it runs on Macs, Linux machines, and most environments you’re likely to be developing for. There are companies offering Node hosting with all kinds of great features like monitoring tools and deployment via version control tools like Git. However, you can also install Node on any server you can SSH into where you have the ability to create files and directories.

For purposes of getting something running, let’s assume you’re installing Node locally on a Mac. We’ll highlight the differences for Windows and remote server setup as we go.

Node and NPM

There are numerous ways to install Node itself, depending on your environment. The easiest option is to download one of the installers available for Windows or Mac from the Node website (these include npm, as well). You can also install it in one line using Homebrew or the Advance Packaging Tool. On any supported operating system, if you have Git installed, you can clone Node directly from the repository and build it yourself.

Since it’s fairly universal, let’s look at getting Node from GitHub. This assumes that Git is already installed and available.

$ git clone git://github.com/joyent/node.git
$ cd node
$ git checkout v0.6.6
$ ./configure
$ make
$ make install

All we’re doing is cloning the GitHub repository, running a configuration script, and then building and installing Node. Pay special attention to the third line, though, because we’re also switching to the branch containing the most recent stable version of Node. That changes frequently, so if you decide to install from the command line, check the Node.js website first to find out what the current stable version is, or use git tag to list available versions.

It’s no longer necessary to install npm separately, but if you need or want to for some reason, command-line installation is very straightforward. For all environments where npm is currently supported, the preferred method of installation is Curl:

$ curl http://npmjs.org/install.sh | sh


npm is Node’s package manager. It maintains a registry of Node modules and allows one-line installation and version management of third-party packages. You can find modules in npm from the command line using npm search search term.


REPL stands for Read-Eval-Print-Loop, and is a utility included with Node that can be very handy when you’re getting started. It works like the debug console in your browser and you can execute whatever commands you want. You don’t need to do anything to install it—you’ll have it available from the command line wherever Node is available. Before even creating an application you can start poking around and see what Node can do by typing node on the command line. If you don’t specify an application to run, you get the REPL instead.

After typing node at the command prompt, you can test a few simple lines of JavaScript, and they should evaluate as normal:

> ["Hello","World"].join(" ")
'Hello World'
> 2 + 3

You can exit the REPL by pressing Ctrl+C.

Let’s say you’re researching modules to manage asynchronous code paths in your project. There are numerous modules to handle asynchronous code and flow control—let’s assume you’ve found a couple you’d like to compare, but neither has a documented API (in reality, the one we’re using below has very nice documentation). To get a better picture of what’s included, you can install them with npm and then use the REPL to investigate them. If you installed the async module, for instance, you could do this:

$ node
> var async = require("async");
> console.dir(async);

That will cause the module to spit out a list of its properties, which you can investigate further from that point, should you so desire. Of course you could just read the source, but it’s useful to know you can open the REPL and see exactly what Node sees. You can also use Tab to auto-complete function and variable names within your code, which may be a faster reference than searching online if you’re in the midst of testing something.

File Organization

With Node installed, we can begin creating the scaffolding for a web application. Since we control how our application serves files, we can put them almost anywhere we want. There are, however, a few conventions it makes sense for us to follow. It’s expected that the main application file we want to run is in the root directory of the site, as is the package.json file (which we’ll create below). Some common directories we might expect to find in the root would include:


Your locally installed modules from npm


Utilities and other custom modules that belong to your application

public, www, or similar

The static, client-side piece of your application

When setting up a directory structure, all that really matters is whether it makes sense to you. If you’ll be using the Model-View-Controller (MVC) pattern for your application, you may choose to have models, views, and controllers directories in your root. If you’re going to use the Express application framework or model your application’s organization on Express, you may have a root directory called routes. Aside from keeping your organization clear and consistent in case someone else needs to work with it, being in control of how your application finds and delivers files means you can put them wherever you think they belong.

We also want to create a package.json file, which is a manifest for our application. This file is especially important for modules that will be published or shared, but it should also be present for our local application. There are lots of things we might add to a package.json file, but for now let’s create a simple one with some meta information about the application and a couple of dependencies:

  "name": "myNodeApp",
  "author": "Jaime Developer",
  "description": "my test node.js application",
  "version": "0.0.1",
  "dependencies": {
    "connect": "1.8.x",
    "express": "2.5.x"
  "engine": "0.6.x",
  "main": "app.js"

Most of those keys are exactly what they sound like. The last two, engine and main, refer to the version of Node and the path to the main application file, respectively. The dependencies object is important to note, as it will come in handy if we ever want to move this application. If that object contains all the npm modules our application uses and their correct versions, we can run the command npm install from the root of our application’s new home to install all the required modules at once.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required