At the Forge - Node.JS

Want to write high-performance network server applications? Node.JS uses JavaScript to do exactly that.

Back in 1995, a number of my coworkers and I went to a big event in New York City where Sun Microsystems, a major UNIX vendor at the time, was announcing its new programming language, Java. Java, of course, was impressive in many ways, but what wowed us was the ability to write “applets”, little Java programs that executed inside the browser. Also at that event was browser powerhouse Netscape Communications, who demonstrated a separate programming language that executed inside the browser. Netscape originally called the language LiveScript, but in the wake of the hype that Java generated, Netscape renamed it JavaScript.

Fast-forward to today, and it's amazing to see how much of this story has changed. Sun is no more, having been bought out by Oracle. Netscape is no more, although its crown-jewel browser has been turned into a leading open-source project. Java has become popular and ubiquitous, and there no longer is any need to convince programmers that it's worthwhile to learn. And, although in-browser applets still exist, they are a tiny fraction of what people now do with Java.

The most interesting part of this whole story is JavaScript. Originally meant to be a simple language put inside browsers, then renamed as part of a marketing effort, you could say that JavaScript had a troubled childhood. Each browser's implementation was slightly different, making it hard to write programs that would work on all browsers. Many implementations were laughably unstable or insecure. One friend of mine enjoyed demonstrating this with a Web page that contained a “while” loop that opened an infinite number of “alert” dialog boxes. Execution was fairly slow and used a large amount of memory. And, of course, there were all sorts of language features that were hard to understand, ambiguous, implementation-dependent or annoying. Adding insult to injury was the odd standardization process that JavaScript went through, giving it an official name of ECMAScript. (Of course, no one really calls it that.)

Nearly everything about JavaScript seems to have changed in the past few years. JavaScript used to be the language everyone used for lack of an alternative. Now, JavaScript is coming into its own. This is certainly true for client-side programming. The ease with which it's now possible to create good interfaces is a testament not only to front-end developers, but also to libraries, such as Prototype, MooTools and jQuery, that make it enjoyable, rather than painful, to work with JavaScript.

Because so many sites now use JavaScript extensively, the need for fast, stable JavaScript engines has grown dramatically. Each of the major open-source browsers (Firefox, Chrome and Safari) now has a team of specialists working to make JavaScript better in all ways, and the improvements are obvious to those who have upgraded their browsers in the past year. JavaScript is getting a great deal of love and attention, and you can expect further improvements during the coming months and years.

Some of these modern JavaScript implementations now are available outside the browser as independent libraries. This means if you want to create a non-browser program that uses JavaScript, you can do so without too much trouble.

About a year ago, a friend and colleague told me that JavaScript was starting to show some potential as a language for server applications. I laughed this off, saying it was probably a fad or a crazy project. After all, I asked him, who would want to use JavaScript as a server-side language, when we have such excellent languages and frameworks already?

Of course, the joke is on me. In the past year, more and more people have started to use JavaScript as a server-side language. This is due in no small part to the emergence of Node.JS, an amazingly fast engine for network applications written in JavaScript, which also was covered by Avi Deitcher in last month's LJ.

The secret to this speed isn't just JavaScript, although that's certainly part of the equation. Node.JS uses Google's V8 JavaScript engine, along with native C++ and JavaScript code. The other reason for Node.JS's high speed is that it is event-driven. Rather than handling incoming traffic with many different processes (à la classic Apache) or threads (modern Apache, as well as some other servers), Node.JS handles all incoming connections in a single process and a single thread. This form of programming is a bit strange at first, but it works very well—so well, in fact, a large community has formed around Node.JS with many plugins and extensions.

This month, I take a quick look at Node.JS, what you can do with it, and why its usage is growing, especially in high-demand Web applications. Even if you never end up using Node.JS in your own work, I assure you that after you've seen what it can do, it'll change your thinking about what JavaScript is and how you write Web applications.