Node's goal is to provide an easy way to build scalable network programs. In
the "hello world" web server example above, many client connections can be
handled concurrently. Node tells the operating system (through
select) that it should be notified when a new connection is made,
and then it goes to sleep. If someone new connects, then it executes the
callback. Each connection is only a small heap allocation.
This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. See: this and this. Node will show much better memory efficiency under high-loads than systems which allocate 2mb thread stacks for each connection. Furthermore, users of Node are free from worries of dead-locking the process—there are no locks. Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems.
Node is similar in design to and influenced by systems like Ruby's Event
Machine or Python's Twisted. Node takes the event model a bit further—it
presents the event loop as a language construct instead of as a library. In
other systems there is always a blocking call to start the event-loop. Typically
one defines behavior through callbacks at the beginning of a script and at the
end starts a server through a blocking call like
EventMachine::run(). In Node there is no such start-the-event-loop
call. Node simply enters the event loop after executing the input script. Node
exits the event loop when there are no more callbacks to perform. This behavior
HTTP is a first class protocol in Node. Node's HTTP library has grown out of the author's experiences developing and working with web servers. For example, streaming data through most web frameworks is impossible. Node attempts to correct these problems in its HTTP parser and API. Coupled with Node's purely evented infrastructure, it makes a good foundation for web libraries or frameworks.
But what about multiple-processor concurrency? Aren't threads necessary to scale programs to multi-core computers? Processes are necessary to scale to multi-core computers, not memory-sharing threads. The fundamentals of scalable systems are fast networking and non-blocking design—the rest is message passing. In future versions, Node will be able to fork new processes (using the Web Workers API ) which fits well into the current design.