Node’s aim is to provide an easy method to build many scalable network programs. For example, the two second delay does not stop the server from handling the new requests. The node tells the operating system through the epoll, kqueue, /dev/poll or select that it should be observed when the 2 seconds are up or if a new connection is being made. Then it goes to sleep. In the meantime, if someone new connects then it would execute the callback and if the timeout expires then it would execute the inner callback. Each connection is just a small heap allocation.

This is in contrast to today’s more common concurrency model where the OS threads are being employed. The thread-based networking is relatively inefficient and is also very difficult to use. The node will show much better memory efficiency under the high loads rather than the systems that allocates 2mb thread stacks for each connection. The users of the Node are free from the issues of dead-locking the process as there are no locks. Most of the functions in the Node do not directly perform the I/O and hence the process never blocks. Since nothing blocks, the less-than-expert programmers are able to develop fast systems.

The node is similar in design and influenced by the systems like Ruby’s Event Machine or the Python’s Twisted. The node takes an event model a bit further. It presents the event loop as a language construct instead of a library. In other systems there is a blocking call to begin the event-loop. One defines behaviour through the callbacks at the start of a script and at the end begins a server through a blocking call like EventMachine::run().

In the node there is nothing such as start-the-event-loop call. The node simply enters the event loop after it executes the input script. The node exits the event loop when there are no more callbacks as such to perform. This behaviour is just like the browser javascript where the event loop is hidden from the user.

The HTTP is a first class protocol in the Node. The node’s HTTP library has grown out of the author’s experiences developing and working with the web servers. An illustration to this is the streaming data through most of the web frameworks is certainly impossible. The node tries to correct these problems in its HTTP parser and API. Coupled with the node’s purely event infrastructure, it makes a good base for the web libraries or the frameworks.

In case of the multiple-processor concurrency the threads are necessary to scale the programs to the multi-core computers. The processes are necessary to scale to the multi-core computers and not memory-sharing threads. The fundamentals of the scalable systems are fast networking and non-blocking design and the rest is via message passing. In the future versions, the node will be able to fork the new processes using the Web Workers API but this is something that will fit well into the present design.