Node: Up and Running
Tom Hughes-Croucher
Mike Wilson
Copyright 2012 Tom Hughes-Croucher, Mike Wilson
OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (.
Nutshell Handbook, the Nutshell Handbook logo, and the OReilly logo are registered trademarks of OReilly Media, Inc. Node: Up and Running , the image of a common tree shrew, and related trade dress are trademarks of OReilly Media, Inc.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and OReilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps.
While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
O'Reilly Media
Foreword by Ryan Dahl
Ryan Dahl, creator of Node.js
In 2008 I was searching for a new programming platform for making websites. This was more than wanting a new language; indeed, the details of the language mattered very little to me. Rather, I was concerned about the ability to program advanced push features into the website like I had seen in Gmailthe ability for the server to push data to the user instead of having to constantly poll. The existing platforms were tightly coupled to the idea of the server as something that receives a request and issues a response sequentially. To push events to the browser, the platform needed to be able to constantly handle a number of open and mostly idle connections.
I knew how to make this work at the system call layer, in C. If I used only nonblocking sockets, the overhead per connection was very small. In small tests, I could demonstrate a server that could handle thousands of idle connections or pretty massive throughput. I knew that this was the optimal way for a user-space Unix server to be implemented. However, I didnt want to work in C; I wanted the beautiful fluidness of a dynamic language. Although it was possible to issue the exact system calls I wanted in every programming language, it was very ugly and was always the alternative method of socket programming. My theory was that nonblocking sockets were not actually difficult at all, as long as everything was nonblocking.
Google announced Chrome and its new JavaScript engine V8 in late 2008. A faster JavaScript engine made for a faster Weband V8 made the Web a lot faster. Suddenly there was this idea of a JavaScript arms race between Google, Apple, Mozilla, and Microsoft. This, combined with Doug Crockfords book JavaScript: The Good Parts (OReilly), shifted JavaScript from the language everyone despised to an important language.
I had an idea: nonblocking sockets in JavaScript! Because JavaScript has no existing socket libraries, I could be the first to introduce this new and hopefully better interface. Just take V8 and glue it to my nonblocking C code, and I should be done. I quit my contracting job and began working on this idea full time. Once I made the very first version available, I immediately had users who reported bugs; I started fixing those bugs, and then three years passed.
It turns out that JavaScript jibes extremely well with nonblocking sockets. This was not clear from the start. The closures made everything possible. People were able to build very complex nonblocking servers in just a couple of lines of JavaScript. My initial fear that the system would be unusably niche was quickly alleviated as hackers from all over the world began to build libraries for it. The single event loop and pure nonblocking interface allowed libraries to add more and more complexity without introducing expensive threads.
In Node, users find a system that scales well by default. Because of the choices made in the core system, nothing in the system is allowed to do anything too terrible (such as block the current thread), and thus performance never degrades horribly. It is an order of magnitude better than the traditional blocking approach, where better is defined as the amount of traffic it can handle.
These days, Node is being used by a large number of startups and established companies around the world, from Voxer and Uber to Walmart and Microsoft. Its safe to say that billions of requests are passing through Node every day. As more and more people come to the project, the available third-party modules and extensions grow and increase in quality. Although I was once reserved about recommending it for mission-critical applications, I now heartily recommend Node for even the most demanding server systems.
This book gracefully takes the reader through a discussion of and guided exercises for Node and many third-party modules. By learning the material covered here, you go from basic familiarity with JavaScript to building complex, interactive websites. If youve used other server-side web frameworks in the past, youll be shocked at how easy it is to build a server in Node.
Foreword by Brendan Eich
Brendan Eich, creator of JavaScript
In April 1995 I joined Netscape in order to add Scheme to the browser. That recruiting bait from a month or two earlier immediately morphed into do a scripting language that looks like Java. Worse, because the negotiation to put Java in Netscape was underway, some at Netscape doubted that a second language was necessary. Others wanted to build something like PHP, an HTML templating language for a planned server-side offering called LiveWire.
So in 10 days in May 1995, I prototyped Mocha, the code name Marc Andreessen had chosen. Marc, Rick Schell (vice president of engineering at Netscape), and Bill Joy of Sun were the upper-management sponsors who supported my work against doubts about a second language after Java. (This is ironic since Java has all but disappeared in browsers, while JavaScript is dominant on the client side.)
To overcome all doubts, I needed a demo in 10 days. I worked day and night, and consequently made a few language-design mistakes (some recapitulating bad design paths in the evolution of LISP), but I met the deadline and did the demo.
People were amazed that Id created a language compiler and runtime in less than two weeks, but Id had a lot of practice over the decade since switching from a physics major in my third year to math/computer science. I had always loved formal language and automata theory. Id built my own parsers and parser generators for fun. At Silicon Graphics, I built network-monitoring tools that included packet-header matching and protocol description languages and compilers. I was a huge fan of C and Unix. So knocking out Mocha was really a matter of sustained application and concentration.
Sometime in the fall of 1995, Netscape marketing renamed Mocha LiveScript, to match the LiveWire server-side product name. Finally, in early December 1995, Netscape and Sun concluded a trademark license, signed by Bill Joy, Founder on behalf of Sun, and LiveScript was renamed JavaScript (JS).
Because of the LiveWire server plans, in the first 10 days I implemented a bytecode compiler and interpreter as well as a decompiler and runtime (the built-in JS objects and functions we know today: Object, Array, Function, etc.). For small client-side scripts, bytecode was overkill, but the LiveWire product included the feature of saving compiled bytecode for faster server-app startup.