One of the things that's often hard to unerstand about Node.js is that, in addition to being a server, it's also a runtime environment in the same way that Perl, Python and Ruby are. As such, while we often refer to Node.js as "server-side JavaScript," that doesn't really accurately describe what Node.js does. One of the best ways to get to grips with Node.js is to use Node REPL ("Read-Evaluate-Print-Loop"), an interactive Node.js programming environment. It's great for testing out and learning about Node.js. You can try out any of the snippets in this book using Node REPL. In addition, because Node is a wrapper around V8, Node REPL is an ideal place to easily try out JavaScript. However, when you want to run a Node program you can use your favourite text editor save it in a file and simply run node filename.js. REPL is a great learning, or exploration tool but we don't use it for production code.

Let's launch Node REPL and try out a few bits of JavaScript to warm up. Open up a console on your system. The system I'm using is a Mac with a custom command prompt, so your system might look a little different, but the commands should be the same:

              $Enki:~ $ node
> 3 > 2 > 1
false
> true == 1
true
> true === 1
false

            

Having a live programming environment is a really great learning tool, but you should know a few helpful features of Node REPL to make the most of it. It offers meta-commands, which all start with a period (.). Thus, .help shows the help menu, .clear clears the current context, and .exit quits Node REPL. The most useful command is .clear, which wipes out any variables or closures you have in memory without the need to restart the REPL.

              > console.log('Hello World');
Hello World
> .help
.clear  Break, and also clear the local context.
.exit   Exit the prompt
.help   Show repl options
> .clear
Clearing context...
> .exit
Enki:~ $

            

When using REPL, simply typing the name of a variable will enumerate it in the shell. Node tries to do this intelligently so a complex object won't just be represented as simple Object, but actually through a description that reflects what's in the object. The main exception to this involves functions. It's not that REPL doesn't have a way to enumerate functions, it's that functions have the tendency to be very large. If REPL enumerated functions, a lot of output could scroll by.

              Enki:~ $ node
> myObj = {};
{}
> myObj.list = ["a", "b", "c"];
[ 'a', 'b', 'c' ]
> myObj.doThat = function(first, second, third) { console.log(first); };
[Function]
> myObj
{ list: [ 'a', 'b', 'c' ]
, doThat: [Function]
}
> 

            

While REPL gives us a great tool for learning and experimentation, the main application of Node.js is as a server. One of the specific design goals of Node.js is to provide a highly scalable server environment. This is an area where Node differs from V8, which I described in Chapter 1, Introduction. Although the V8 runtime is used in Node.js to interpret the JavaScript, Node.js also uses a number of highly optimized libraries to make the server efficient. In particular, the HTTP module was written from scratch in C to provide a very fast non-blocking implementation of HTTP. Let's take a look at the canonical Node "Hello World" example using an HTTP server.

              var http = require('http'); 
http.createServer(function (req, res) { 
    res.writeHead(200, {'Content-Type': 'text/plain'}); 
    res.end('Hello World\n'); 
}).listen(8124, "127.0.0.1"); 
console.log('Server running at http://127.0.0.1:8124/'); 
                    
            

The first thing that this code does is use require to include the HTTP library into the program. This concept is used in many languages, but Node uses the CommonJS module format, which we'll talk about more later in the chapter. The main thing to know at this point is that the functionality in the HTTP library is now assigned to the http object.

Next we need an HTTP server. Unlike some languages such as PHP, which run inside a server such as Apache, Node itself acts as the Web server. However, that also means we have to create it. The next line calls a factory method from the HTTP module that creates new HTTP servers. The new HTTP server isn't assigned to a variable, it's simply going to be an anonymous object in the global scope. Instead we use chaining to initialize the server and tell it to listen on port 8124.

When calling createServer, we passed an anonymous function as an argument. This function is attached to the new server's event listener for the request event. Events are central to both JavaScript and Node. In this case, whenever there is a new request to the Web server, it will call the method we've passed to deal with the request. We call these kinds of methods callbacks. That's because whenever an event happens, we "call back" all the methods listening for that event.

Perhaps a good analogy would be ordering a book from a bookshop. When your book is in stock they call back to let you know you can come and collect it. This specific callback takes the arguments req for the request object and res for the response object.

Inside the function we created for the callback, we call a couple of methods on the res object. These calls modify the response. This example doesn't use the request, but typically you would use both the request and response objects.

The first thing we must do is set the HTTP response header. We can't send any actual response to the client without it. the res.writeHead method does this. We set the values 200 (for the HTTP status code 200 OK) and pass a list of HTTP headers. In this case the only header we specify is Content-type.

After we've written the HTTP header to the client, we can write the HTTP body. In this case we use a single method to both write the body and close the connection. The end method closes the HTTP connection, but since we also passed it a string, it will send that to the client before it closes the connection.

Finally, the last line of our example uses the console.log. This simply prints information to STDOUT, much like the browser counterpart supported by Firebug and Web Inspector.

Let's run this with Node.js on the console and see what we get:

              Enki:~ $ node
node> var http = require('http'); 
node> http.createServer(function (req, res) { 
...     res.writeHead(200, {'Content-Type': 'text/plain'}); 
...     res.end('Hello World\n'); 
...   }).listen(8124, "127.0.0.1"); 
node> console.log('Server running at http://127.0.0.1:8124/'); 
Server running at http://127.0.0.1:8124/ 
node> 


            

Here I start a Node REPL and type in the code from the sample (I'll forgive you for pasting it from the web site). Node REPL accepts the code using ... to indicate that you haven't completed the statement and should continue entering it. When we run the console.log line, Node REPL prints out Server running at http://127.0.0.1:8124/. Now we are ready to call our Hello World example in a web browser (Figure 1.1, “Viewing the Hello World Web Server from a browser”).

Figure 1.1. Viewing the Hello World Web Server from a browser

It works! While this isn't exactly a stunning demo, it is notable that we got "Hello World" working in 6 lines of code. Not that I would recommend that style of coding, but we are starting to get some where. In the next chapter we'll look at a lot more code but first let's think about why Node is how it is.

When I first started writing web applications, more than 10 years ago, the web was much smaller. Sure we had the .com bubble but the sheer volume of people on the Internet was considerably less, and the sites we made were much less ambitious. Fast forward and we have the advent of Web 2.0 and widely available Internet connections on cell phones. So much more is expected of us as developers. Not only are the features we need to deliver more complex, more interactive, more real but many more people are using them more often from more devices than ever before. This is a pretty steep challenge. While hardware continues to improve we also need to make improvements to our software development practices to support such demands. If we kept just buying hardware to support ever increasing features or users it wouldn't be very cost effective.

Node is an attempt to solve this problem by introducing the architecture called event-driven computing to the programming space for web server. As it turns out Node isn't the first platform to do this, but it is by far the most successful, and I would argue the easiest to use. We are going to talk about event-driven programming in a lot more detail later in the book, but let's do a quick intro. Imagine you connect to a web server to get a web page. The time to reach that web server is probably 100ms or so over a reasonable DSL connection. When you connect to a typical web server it creates a new instance of a program on the server that represents your request. That program runs from the top to the bottom (follow all of the function calls) to provide your web page. This means that the server has to allocate a fixed amount of memory to that request until it is totally finished including the 100ms+ to send the data back to you. Node doesn't work that way. Instead Node keeps all users in a single program. Whenever Node has to do something slow like wait for a confirmation you got your data (so it can mark your request as finished) it simply moves on to another user. I'm glossing over the details a bit but this means Node is a lot more efficient with memory than traditional servers and can keep providing a very fast response time with lots and lots of concurrent users. This is a huge win. This approach is one of the main reasons people like Node.

Another reason people like Node is JavaScript. JavaScript was created by Brendan Eich in 1995 to be a simple scripting language for use in web pages on the Netscape browser platform. Surprisingly almost since its inception JavaScript has been used in non-browser settings. Some of the early Netscape server products supported JavaScript (known then as LiveScript) as a server-side scripting language. While server-side JavaScript didn't really catch on then, that certainly wasn't true for the exploding browser market. On the Web JavaScript competed with Microsoft's VBScript to provide programming functionality in Web pages. It's hard to say why JavaScript won, perhaps Microsoft allowing JavaScript in Internet Explorer^[1] did it. Perhaps it was the JavaScript language itself, but win it did. This meant by the early 2000s JavaScript had emerged as the Web language. Not the first choice, but the only choice for programming with HTML in browsers.

What does this have to do with Node.js? Well the important thing to remember is that when the AJAX revolution happened and the Web became big business (think Yahoo, Amazon, Google, etc) the only choice for the "J" in AJAX was JavaScript there simply wasn't an alternative. As a result a whole industry needed an awful lot of JavaScript programmers, really good ones at that, rather fast. The emergence of the Web as a serious platform and JavaScript as its programming language meant that we, as JavaScript programmers needed to shape up. We can equate the change in JavaScript as the second or third programming language of a programmer to the change in perception of its importance. We started to get emerging experts who lead the charge in making JavaScript respectable.

Arguably at the head of this movement was Douglas Crockford. His popular articles and videos on JavaScript have helped many programmers discover that inside a language much maligned there is a lot of inner beauty. Most programmers working with JavaScript had spent the majority of their time working with the browser implementation of the W3C DOM API for manipulating HTML or XML documents. Unfortunately, the DOM is probably not the prettiest API ever conceived, but worse its various implementations in the browsers are inconsistent and incomplete. No wonder that for a decade after its release JavaScript was not thought of as a "proper" language by so many programmers. More recently Douglas' work on "the good parts" of JavaScript have helped create a movement of advocates of the language which recognize that it has a lot going for it despite the warts.

In 2010 we now have a proliferation of JavaScript experts advocating well written, performant, maintainable JavaScript code. People such as Douglas Crockford, Dion Almaer, Peter Paul Koch (PPK), John Resig, Alex Russell, Thomas Fuchs, and many more have provided research, advice, tools, and primarily libraries that have allowed thousands of professional JavaScript programmers worldwide to practice their trade with a spirit of excellence. Libraries like jQuery, YUI, Dojo, Prototype, Mootools, Sencha and many others are now used daily by thousands of people and deployed on millions of Web sites. It is in this environment where JavaScript is not only accepted, but widely used and celebrated that a platform larger than the web makes sense. When so many programmers know JavaScript its ubiquity has become a distinct advantage.

When I speak at conferences I can ask a room full of Web programmers what languages they use. Java and PHP are very popular, Ruby is probably next most popular these days or at least closely tied with Python and Perl still has a huge following. However, almost without exception anyone who does any programming for the web has programmed in JavaScript. While backend languages are fractured in browser programming is united by the necessities of deployment. Various browsers and browser plugins allow the use of other languages, but they simply aren't universal enough for the web. So here we are with a single universal web language. How can we get it on the server?

Fairly early in the days of the Web we had the infamous browser wars. Internet Explorer and Netscape competed viciously on Web features, adding various incompatible programmatic features to their browsers and not supporting the features in the other browser. For those of us who programmed the web this was the cause of much anguish because it made Web programming really tiresome. Internet Explorer more or less emerged the winner of that round and became the dominant browser. Fast forward a few years, Internet Explorer has been languishing at version 6 and a new contender, Firefox emerges from the remnants of Netscape. Firefox kicks off a new resurgence in browsers being followed by Webkit (Safari) and then Chrome. Most interesting about this current trend is the resurgence of competition into the browser market.

Unlike the first iteration of the browser wars today's browser compete on two fronts, adhering to the standards that emerged after the previous browser war and performance. As Web sites have become more complex users want the fastest experience possible. This has meant that browsers not only need to support the Web standards well, allowing developers to optimize, but also to do a little optimization of their own. JavaScript being a core component of Web 2.0, AJAX web sites has become part of the battleground.

Each browser has their own JavaScript runtimes: Spider Monkey for Firefox, Squirrel Fish Extreme for Safari, Karakan for Opera, and finally V8 for Chrome. As these runtimes compete on performance it creates an environment of innovation for JavaScript. In order to differentiate their browsers vendors are going to great lengths to make them as fast as possible.