In part 2, we explored the call stack and execution context in detail and examined how slow functions impact the synchronous, single-threaded nature of JavaScript.

In part 3, we will dive into the asynchronous operations and the role of the event loop in facilitating these async operations. By the end of this section, you will have a comprehensive understanding of the concurrency model in JavaScript.

Here is the table of contents for your easy access.

An overview of the JS Engine & Memory Heap
Call Stack and Execution Context in details
Event Loop and the Concurrency Model – Task Queue
Event Loop and the Concurrency Model – Microtask Queue (coming soon)
Advanced JavaScript: Chunking, Threading, Parallelism, and Web Workers (coming soon)
Explanation of Interview Question (coming soon)

Let’s begin with the JavaScript Runtime Environment which is the critical part of understanding how the async works.

JavaScript Runtime Environment

JavaScript Runtime Environment serves as an overarching environment and it’s more than just the JavaScript engine that interprets and runs your JS code. Specifically, within browsers, this runtime extends its capabilities by integrating various Web APIs. These APIs provide JavaScript with powerful features, allowing it to interact with the DOM, make network requests, tap into hardware functionalities, and much more.

All these components in the illustration, working in tandem, constitute the ecosystem known as the JavaScript Runtime Environment.

Web API

Web APIs are integral to the JavaScript Runtime Environment, enabling the JS engine to interact with the browser and perform more complex operations that the JavaScript language itself wouldn’t natively support such as fetch() and setTimeout().

In the JavaScript Runtime Environment, Web APIs are non-blocking and asynchronous. When an API is called within JavaScript, it’s handed off to the browser to take care of. This might involve fetching data over the network with fetch(), waiting for a user event to occur using setTimeout(), or running an operation in the background using Web Workers.

While the browser is processing these tasks, JavaScript continues to execute other code. Once the browser completes the task, it sends a message to the JavaScript engine signalling that the operation is complete, typically by using mechanisms like callbacks, promises, or async/await.

These asynchronous operations are handled through a system where the Web API, once completed, places a message in the Task Queue. The JavaScript engine, while executing other code, periodically checks this queue. If the main thread is free – meaning the Call Stack is empty – it will take the next message from the queue and process it. This loop of checking the queue and processing tasks is known as the Event Loop, which we will explore in the next section.

Task Queue

The task queue (also known as callback queue or message queue) in JavaScript is a crucial component in the runtime environment where callback functions associated with asynchronous operations wait for their turn to be executed. When the JavaScript engine performs an operation that will take some time to produce a result, such as an API fetch or a timer delay, it uses Web APIs to handle these tasks separately. Once these tasks complete, their callback functions are placed into the task queue.

Tasks in the queue are only executed when the call stack is empty. This means that if the stack is busy with other operations, even immediate tasks (setTimeout with a delay of 0) must wait.

The task queue operates on a First-In-First-Out (FIFO) principle, ensuring that tasks are executed in the exact sequence they arrive.

This is in contrast to the call stack, which operates on a Last-In-First-Out (LIFO) basis, where the most recently added stack frame is the first to be executed and removed.

Event Loop (Concurrency Model)

The JavaScript concurrency model is what allows JavaScript, a single-threaded language, to perform tasks asynchronously and handle concurrency, despite its linear execution path. This model’s relationship with the event loop is integral to how JavaScript manages to execute long-running tasks, like I/O operations, HTTP requests, and timers, without blocking the main thread and thus keeping the application responsive.

Concurrency Model

Concurrency in JavaScript means that the engine can process multiple tasks in a non-blocking manner. This model ensures that any heavy lifting done by asynchronous tasks doesn’t freeze the main thread, which is crucial for maintaining the responsiveness of the application. For example, while a data fetch operation is waiting for a response from a server, the main thread can continue to process user inputs, animate page elements, or execute other queued scripts.

The event loop, task queue, and call stack are interwoven components that form the backbone of JavaScript’s concurrency model. Together, they allow JavaScript to execute complex tasks asynchronously, maintain a responsive environment, and ensure that operations are completed in an orderly fashion.

Event Loop

The event loop applies the concurrency model, deciding when to run callbacks from the task queues based on the state of the call stack. It constantly checks if the call stack is empty and looks at the task queues to see if there are any tasks waiting to be run. If the stack is clear but there are tasks in the microtask queue, which we will talk in details in the following section, those are run first.

Once the microtask queue is empty, the event loop moves on to the task queue. It’s a continuous loop of checking and running tasks, ensuring that JavaScript can execute callbacks as soon as the stack is clear, without any interruption to the ongoing processing.

In summary, the concurrency model and the event loop together enable JavaScript to manage tasks in a way that seems concurrent, allowing for the efficient execution of complex applications. It’s a system designed to utilise the single-threaded nature of JavaScript to its advantage, ensuring that web applications remain interactive and performant.

Now let’s take a look at an example with setTimeout and see how the async operation works.

setTimeout – 2000ms delay

To comprehend how setTimeout works within the JavaScript runtime environment, let’s examine a simple example where setTimeout is used with a delay of 2000 milliseconds (2 seconds).

Here’s the code snippet:

function first() {
  console.log('First function');
}

setTimeout(function() {
  console.log('setTimeout: 2 sec');
}, 2000);

function second() {
  console.log('Second function');
}

first();
second();

Can you predict the order in which the messages will be logged to the console?

The output will be:

First function
Second function
setTimeout: 2 sec

Now, let’s break down how this sequence is executed in the JavaScript runtime environment.

1. Creating Phase

When the script initially loads, the JavaScript engine enters the creation phase. In this phase, the engine scans through the script to identify and hoist function declarations and variable declarations. It sets up the memory space for variables and functions. The functions, first, second and the callback inside setTimeout are hoisted, and their references are stored in memory.

2. Execution Phase

After the creation phase, the execution phase begins, where the code executes line by line.

2-1. Scheduling setTimeout

The script encounters the setTimeout call first. The setTimeout function instructs the Web API to set a timer for 2000 milliseconds. The Web API holds the callback function and starts the timer. Meanwhile, the JavaScript engine continues executing the rest of the script.

2-2. Executing first()

Next, the first() function is called. This function’s execution context is pushed onto the call stack, it logs First function to the console, and then it’s popped off the stack.

2-3. Executing second()

The execution continues to second(), which is then called. Similar to first(), it logs Second function and is then removed from the call stack.

2-4. Delay Completion

Once the 2 seconds have elapsed, the timer set by setTimeout expires. The callback function is then moved into the task queue.

2-5. Event Loop Processing

The event loop checks if the call stack is empty. Finding it so, it moves the setTimeout callback from the task queue to the call stack.

2-6. Executing setTimeout Callback

The callback from setTimeout is finally executed, logging setTimeout: 2 sec to the console.

Now let’s take a look at another interesting example.

Understanding the Real Duration of setTimeout’s 2000ms Delay

Now let’s take a look at if the 2 seconds delay is happening really after 2 seconds. To demonstrate it, I have added the longTaskFunc().

function first() {
  console.log('First function');
}

setTimeout(function() {
  console.log('setTimeout: 2 sec');
}, 2000);

function longTaskFunc() {
  // this function contains operations that take a long time
  for (let i = 0; i < 1e9; i++) { } 
  console.log('Long Task Function');
}

function second() {
  console.log('Second function');
}

first();
longTaskFunc();
second();

We have a setTimeout function set with a delay of 2000 milliseconds (2 seconds), but is this delay always accurate?

This is the output.

First function
Long Task Function
Second function
setTimeout: 2 sec

The 2-second timer for setTimeout starts immediately after it's invoked in the execution sequence. However, the actual callback execution might not happen precisely 2 seconds after the call. The reason lies in how JavaScript handles the event loop and task queue as we discussed above. Let's explore its execution phase.

The flow

1. Scheduling setTimeout

The setTimeout is scheduled with a delay of 2000 milliseconds (2 seconds). This task is handed over to the Web APIs provided by the browser.

The Web API starts the timer for the specified delay, in this case, 2 seconds. During these 2 seconds, the timer runs independently of the JavaScript call stack and execution context. This is crucial as it allows the JavaScript engine to continue executing other tasks without being blocked by the delay.

2. Executing first()

The first() function is called and logs "First function" to the console. It's then removed from the call stack.

3. Executing `longTaskFunc()`

The longTaskFunc() is a blocking operation, consuming significant time on the call stack.

During this time, the 2 seconds have elapsed so the setTimeout callback is moved to the task queue. However, it must wait there until the call stack is clear. If longTaskFunc() takes more than 2 seconds to complete, the setTimeout callback has to wait, effectively extending the real wait time beyond 2 seconds.

4. Executing second()

After longTaskFunc() completes, the second() function is called, logging "Second function" again.

5. `setTimeout` Callback Execution

Only after longTaskFunc() and second() have finished and been removed from the call stack, the event loop will transfer the setTimeout callback onto the call stack for execution.

The critical point is that the setTimeout callback is placed in the task queue after the 2-second delay, regardless of the execution time of other functions. But its execution depends on the state of the call stack: it will only execute once the call stack is clear.

Therefore, the total time from the scheduling of setTimeout to the execution of its callback could be exactly 2 seconds if other functions complete within 2 seconds. Or if longTaskFunc() takes, let’s say, 5 seconds to complete, the total time from the scheduling of setTimeout to its callback execution will be around 7 seconds = 5 seconds of blocking operation plus the 2-second delay.

This behaviour is a key aspect of JavaScript's asynchronous nature, where the execution of callbacks is managed based on the availability of the call stack, independent of the Web API's timer duration.

setTimeout - 0ms delay

This time, the delay of setTimeout is now set to 0ms.

function first() {
  console.log('First function');
}

setTimeout(function() {
  console.log('setTimeout: 0 sec');
}, 0);

function longTaskFunc() {
  // this function contains operations that take a long time
  for (let i = 0; i < 1e9; i++) { } 
  console.log('Long Task Function');
}

function second() {
  console.log('Second function');
}

first();
longTaskFunc();
second();

With 0ms delay, can you guess the order of the console.log?

Given the 0ms delay in setTimeout, it might seem intuitive to expect its callback to execute immediately. However, the output is:

First function
Long Task Function
Second function
setTimeout: 0 sec

Is it something you expected? Why does this happen?

Even though setTimeout is called with a delay of 0 milliseconds, it does not execute its callback immediately. Let’s break it down.

The flow

1. Scheduling setTimeout

Same as the example above, the JS engine schedules the setTimeout callback. Despite the delay being 0ms, the callback doesn't execute right away. Instead, it's handed off to the browser's Web API environment to handle the timer. This is an asynchronous action, and the JavaScript engine doesn't wait for it to complete. Instead, it moves on to execute the rest of the synchronous code.

2. Executing `first()`, `longTaskFunc()` and `second()`

The first(), longTaskFunc() and second() functions are called, logging “First function”, “Long Task Function” and"Second function". At this point, the call stack is still occupied with synchronous calls.

3. Event Loop and Task Queue

After the 0ms delay, the callback of setTimeout is moved to the task queue. However, the event loop doesn't immediately execute tasks from the task queue if the call stack is not empty. It waits until the call stack is clear of all currently executing scripts.

4. Clear Call Stack

Once the synchronous code (first(), longTaskFunc() and second() functions) finishes executing, the call stack is cleared.

5. Callback Execution

Now, the event loop takes the setTimeout callback from the task queue and place it on the call stack. The callback executes, logging "setTimeout: 0 sec".

The output order demonstrates that, in JavaScript, asynchronous callbacks, even with a delay of 0ms, are placed in the task queue and only executed once the call stack is clear of all other tasks.

In this execution sequence, even though setTimeout is scheduled first, the nature of JavaScript's event-driven, non-blocking execution model means that the actual logging of "setTimeout: 0 sec" will occur after the other functions have been logged. This allows the immediate execution of subsequent functions (first, longTaskFunc and second) before the callback of setTimeout is processed.

In summary, the event loop checks the task queue for callbacks (like those from setTimeout) only when all synchronous code execution has completed and the call stack is empty. In the code example, the setTimeout callback is queued almost immediately, but it doesn't execute until the synchronous code (first(), longTaskFunc(), second()) has finished executing. Only after the second() function is popped off the call stack, the event loop moves the setTimeout callback from the task queue to the call stack.

setTimeout - 2000ms delay and 0ms delay together

Let's consider a scenario where we have two setTimeout calls: one with a 2000ms delay and another with a 0ms delay and see how the execution order of tasks in the task queue works.

function first() {
  console.log('First function');
}

setTimeout(function() {
  console.log('setTimeout: 2000 sec');
}, 2000);

setTimeout(function() {
  console.log('setTimeout: 0 sec');
}, 0);

function longTaskFunc() {
  // this function contains operations that take a long time
  for (let i = 0; i < 1e9; i++) { } 
  console.log('Long Task Function');
}

function second() {
  console.log('Second function');
}

first();
longTaskFunc();
second();

Now let’s focus on the two setTimeout and revisit what we have learnt so far.

When a setTimeout function is called, the browser's Web API handles the timing mechanism. The Web API starts a timer for the specified duration (2000ms and 0ms in our cases) and, once the timer expires, moves the callback function to the task queue. It's crucial to note that the Web API operates independently of the JavaScript call stack.

The flow

1. Web API and Timers

When you call setTimeout, the Web API starts a timer for the specified delay. In the code, there are two setTimeout calls: one with a 2000ms delay and another with a 0ms delay. Even though the 2000ms setTimeout is called first, its timer is longer.

2. Processing the 2000ms `setTimeout`

The Web API starts a 2000ms timer. While this timer counts down, the JavaScript engine continues executing other code. The callback for this setTimeout remains within the Web API's scope until the 2000ms elapse.

3. Processing the 0ms setTimeout

Almost immediately after, the Web API starts a timer for the 0ms setTimeout. Since the delay is virtually non-existent, this timer finishes almost instantly. Therefore, the callback for this setTimeout is moved to the task queue much quicker than the 2000ms one.

4. Order in the Task Queue

In the task queue, tasks are processed in a first-in, first-out (FIFO) order which contrasts with the call stack’s last-in, first-out (LIFO) nature. Thus, the 0ms setTimeout callback, which finishes its timer first and is queued first, will be at the front of the queue. The 2000ms setTimeout callback, on the other hand, will join the task queue only after its timer expires, which will be much later, positioning it behind the 0ms callback in the queue.

5. Event Loop and Execution

The event loop constantly monitors the call stack and the task queue. It only moves tasks from the task queue to the call stack when the call stack is empty. Therefore, even though the 0ms delay callback is queued first, it will not execute until the call stack is clear of all synchronous code, including functions like longTaskFunc() and second().

Therefore, the output will be:

First function
Long Task Function
Second function
setTimeout: 0 sec
setTimeout: 2000 sec

How to Manage Long Tasks in JavaScript

Having understood how the Web API and task queues operate, let's explore an example of mitigating slow tasks utilising these concepts.

The Importance of the Main Thread

The main thread plays a vital role in web development. It's responsible for executing JavaScript code, rendering pages, and handling user interactions. However, when a long task is executed on the main thread, it can block other critical operations, such as rendering and responding to user inputs, leading to a degraded user experience. Therefore, managing these long tasks efficiently is crucial to maintaining a smooth and responsive interface.

Mitigating Long Tasks with `setTimeout`

One approach to manage long tasks is by breaking them down into smaller chunks using setTimeout. This allows other tasks, including browser rendering and event handling, to be interleaved between these chunks, thus reducing the impact on the main thread's responsiveness.

Let’s take a look at the code snippet:

function first() {
  console.log('First function');
}

function longTaskFunc() {
  for (let i = 0; i < 1e9; i++) { } // Simulates a long task
  console.log('Long Task Function');
}

function second() {
  console.log('Second function');
}

first();

setTimeout(function() {
  longTaskFunc();
}, 0);

second();

In this code, first() and second() functions are executed immediately and synchronously. They will complete their executions before the browser can do anything else, like updating the UI or responding to user interactions. This is because JavaScript runs on a single thread and these functions occupy the call stack.

The setTimeout function is used here to defer the execution of longTaskFunc(). By setting the timeout to 0, we are telling the browser to execute longTaskFunc() as soon as possible after the current call stack is clear and the event loop checks the task queue. This means longTaskFunc() will execute after first() and second() have finished, and the JavaScript runtime is free to handle other tasks.

While this method is effective for ensuring that first() and second() run before longTaskFunc(), it's important to note that longTaskFunc(), being a long-running operation, can still block the main thread when it eventually runs. This can be problematic if longTaskFunc() is intensive enough to cause a noticeable delay in the user interface or other asynchronous operations.

Also, using setTimeout in this way doesn't make the long task any less intensive; it merely postpones its execution. If maintaining responsiveness is critical, we might want to explore breaking the long task into smaller chunks and processing these chunks over multiple event loop cycles. Let’s take a look at the example for it.

function processLargeData(data, chunkSize) {
  let index = 0;

  function processChunk() {
    const chunkEnd = Math.min(data.length, index + chunkSize);

    for (; index < chunkEnd; ++index) {
      // process data[index]
    }

    if (index < data.length) {
      setTimeout(processChunk, 0);
    }
  }

  setTimeout(processChunk, 0);
}

// Example usage
processLargeData(largeArray, 100);

In this code, we are breaking down a potentially long-running task into smaller chunks to avoid blocking the main thread in JavaScript. Let's go through the code step by step:

1. Example Usage (line 20): processLargeData is called with largeArray (the data to be processed) and 100 (the size of each chunk). This starts the entire process of chunked data processing.

2. Function Declaration (line 1): processLargeData is a function that takes two parameters: data, which is an array or a large dataset, and chunkSize, which specifies how many items of the data should be processed in each chunk.

3. Variable Initialisation (line 2): Inside processLargeData, the variable index is initialised to 0. This index will keep track of the current position in the data array.

4. Starting the Process (line 16): The initial call to setTimeout(processChunk, 0) outside of processChunk starts the chunk processing. It schedules the first invocation of processChunk.

5. processChunk Function (line 4): Inside processLargeData, there's another function defined called processChunk. This inner function is responsible for processing a single chunk of data at a time.

6. Processing a Chunk: In processChunk, a variable chunkEnd is calculated, which is the smaller of either the end of the data array or the current index plus the chunk size. This determines the end of the current chunk (line 5). A for ... loop then iterates over the data array from the current index to chunkEnd, processing each item. This could be any operation, like calculations or transformations (line 7-9).

7. Scheduling Next Chunk: After processing a chunk, the function checks if there are more items left to process in the data array, index < data.length (line 11). If setTimeout(processChunk, 0) is called, this schedules the processChunk function to be called again, but not immediately. It allows the event loop to handle other pending tasks (like UI updates, user interactions, etc.) before processing the next chunk. This is crucial for keeping the application responsive.

In summary, this code efficiently processes a large dataset in smaller portions, allowing other tasks to be executed between each chunk. This prevents the long-running process from blocking the main thread, thus maintaining the responsiveness of the web page.

Limitations

However, the processLargeData function, while effective in breaking down a large task into smaller chunks, comes with its own set of limitations.

1. Increased Overall Processing Time: By splitting the task into smaller chunks and scheduling each chunk with setTimeout, there are small delays introduced between the processing of each chunk. These delays can add up, resulting in a longer total processing time compared to executing the entire task in a single, uninterrupted process.

2. Complexity in Managing Chunk Size: Determining the optimal size for each chunk can be challenging. If the chunks are too large, the main thread could still be blocked for noticeable periods, negatively impacting user experience. Conversely, if the chunks are too small, the overhead of scheduling each chunk could outweigh the benefits, and the total processing time could become excessively long.

3. Juggling Responsiveness with Performance: This technique involves a trade-off between keeping the application responsive and completing the task efficiently. While it improves responsiveness by allowing other tasks (like UI updates) to interleave between chunks, it might do so at the cost of overall task efficiency.

4. Handling Asynchronous Operations: If the data processing involves asynchronous operations, managing them within each chunk can further complicate the logic. Ensuring that asynchronous operations are completed before moving on to the next chunk requires careful handling of promises or callbacks.

5. Not Suitable for All Types of Tasks: This method is primarily beneficial for tasks that can be easily broken down into smaller, independent chunks. It might not be as effective for tasks that require processing a large dataset in a specific sequence or where each step depends on the output of the previous one.

While this chunking technique is a useful way to prevent long tasks from blocking the main thread, it's essential to understand and consider these limitations. For some use cases, other strategies or more advanced APIs might offer better solutions. The subsequent parts of this serises will explore more advanced APIs and techniques that provide better control and efficiency in managing long tasks, without overburdening the main thread.

What's in Part 4?

In Part 3, we explored the JavaScript Runtime Environment, focusing on its structure and functionality. We learned the orchestration of the call stack, Web API, and task queue in detail, and also about the concurrency model and event loop through various coding examples.

In Part 4, we will dive into another crucial concept: the Microtask Queue, which plays a key role in the execution order of asynchronous operations in JavaScript. We'll examine how it interacts with the event loop, ensuring more efficient and predictable handling of tasks. Additionally, we will learn Animation Frame Queue too.

I hope you're enjoying this series on the JavaScript engine. Please don't forget to join our newsletter for more JavaScript insights below. And also let's connect on LinkedIn and discuss more JavaScript topics!