First, let's take an accurate look at the total time cost when your program asks the system to perform different kinds of services. I/O is expensive. In the following chart (taken from Ryan Dahl's original presentation on Node), we can see how many clock cycles typical system tasks consume. The relative cost of I/O operations is striking:

The reasons are clear enough: a disk is a physical device, a spinning metal platter — storing and retrieving that data is much slower than moving data between solid-state devices (such as microprocessors and memory chips), or indeed optimized on-chip L1/L2 caches. Similarly, data does not move from point to point on a network instantaneously. Light itself needs 0...

The following three points are important to remember, as we break down the event loop:

• The event loop runs in the same (single) thread your JavaScript code runs in. Blocking the event loop means blocking the entire thread.
• You don't start and/or stop the event loop. The event loop starts as soon as a process starts, and ends when no further callbacks remain to be performed. The event loop may, therefore, run forever.
• The event loop delegates many I/O operations to libuv, which manages these operations (using the power of the OS itself, such as thread pools), notifying the event loop when results are available. An easy-to-reason-about single-threaded programming model is reinforced with the efficiency of multithreading.

For example, the following while loop will never terminate:

let stop = false;
setTimeout(() => {
  stop = true;
}, 1000);

while...

Modern network software, for various reasons, is growing in complexity and, in many ways, changing how we think about application development. Most new platforms and languages are attempting to address these changes. Node is no exception — and JavaScript is no exception.

Learning about Node means learning about event-driven programming, composing software out of modules, creating and linking data streams, and producing and consuming events and their related data. Node-based architectures are often composed of many small processes and/or services communicating with events — internally, by extending the EventEmitter interface and using callbacks, and externally, over one of several common transport layers (for example, HTTP, TCP), or through a thin messaging layer covering one of these transport layers (for example, 0MQ, Redis PUBSUB, and Kafka...

Timers are used to schedule events in the future. They are used when one seeks to delay the execution of some block of code until a specified number of milliseconds have passed, to schedule periodic execution of a particular function, and so on.

JavaScript provides two asynchronous timers: setInterval() and setTimeout(). It is assumed that the reader is fully aware of how to set (and cancel) these timers, so very little time will be spent discussing the syntax. We'll instead focus more on gotchas and less well-known details about timeouts and intervals.

The key takeaway will be this: when using timers, one should make no assumptions about the amount of actual time that will expire before the callback registered for this timer fires, or about the ordering of callbacks. Node timers are not interrupts. Timers simply promise to execute as close as possible to the specified...

Members of the Node community develop new packages and projects every day. Because of Node's evented nature, callbacks permeate these codebases. We've considered several of the key ways in which events might be queued, dispatched, and handled through the use of callbacks. Let's spend a little time outlining the best practices, in particular, about conventions for designing callbacks and handling errors, and discuss some useful patterns when designing complex chains of events and callbacks. In particular, let's look at the new Promise, Generator, and async/await patterns that you will see in this book, and other examples of modern Node code.

Simplifying control...

Let's apply what we've learned. The goal is to create a server that a client can connect to and receive updates from Twitter. We will first create a process to query Twitter for any messages with the hashtag #nodejs, and write any found messages to a tweets.txt file in 140-byte chunks. We will then create a network server that broadcasts these messages to a single client. Those broadcasts will be triggered by write events on the tweets.txt file. Whenever a write occurs, 140-byte chunks are asynchronously read from the last-known client read pointer. This will happen until we reach the end of the file, broadcasting as we go. Finally, we will create a simple client.html page, which asks for, receives, and displays these messages.

While this example is certainly contrived, it demonstrates:

• Listening to the filesystem for changes...

Programming with events is not always easy. The control and context switches, defining the paradigm, often confound those new to evented systems. This seemingly reckless loss of control and the resulting complexity drives many developers away from these ideas. Students in introductory programming courses normally develop a mindset in which program flow can be dictated, where a program whose execution flow does not proceed sequentially from A to B can bend understanding.

By examining the evolution of the architectural problems, Node is now attempting to solve for network applications—in terms of scaling and code organization, in general terms of data and complexity volume, in terms of state awareness, and in terms of well-defined data and process boundaries. We learned how managing these event queues can be done intelligently. We saw how different event sources...