JavaScript plays an important role in web development, especially in understanding its asynchronous functionalities.

In this series, we’ll dive deep into how the JavaScript engine works, covering everything from asynchronous operations to more complex topics like chunking, threading, parallelism, and web workers.

The series includes:

An overview of the JS Engine & Memory Heap
Call Stack and Execution Context in details (coming soon)
Event Loop and the Concurrency Model – Task Queue (coming soon)
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)

At the end of this series, you’ll have a much better idea of these concepts, equipping you with the knowledge to help you write efficient JS code.

Moreover, after reading this article, as these topics frequently appear in technical interviews, you’ll feel more confident in your next interview when you are asked similar questions.

Let’s kick off with a potential interview question to get a glimpse of what to expect.

Interview Question

Given the JavaScript code snippet below, your task is to predict the sequence in which the messages will be printed to the console.

This exercise is designed to assess your understanding of JavaScript’s asynchronous nature, event loop mechanics, and the execution order of synchronous vs. asynchronous callbacks.

Pay close attention to the use of setTimeout, the resolution of Promises, and the execution of long-running tasks. After analysing the code, provide a detailed explanation of the output order and the reasons behind it.

console.log('Init');

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');

  forth();
}

Promise.resolve().then(() => console.log('Promise'));

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

function third() {
  console.log('Third function');
}

function forth() {
  console.log('Forth function');
}

console.log('Start');
first();
longTaskFunc();
second();
third();
console.log('End');

Here is the answer for the output:

Init
Start
First function
Long Task Function
Second function
Forth function
Third function
End
Promise
setTimeout: 0 sec
setTimeout: 2 sec

If the reasoning behind the output isn’t immediately clear, don’t worry. We will dive into the key principles surrounding JavaScript Engines to build a solid foundation of understanding. As we progress and cover the material and based on what you learn throughout this series, we’ll circle back to this question in part 6. By then, you’ll be fully equipped to confidently explain the output.

Now, let’s begin by the overflow of JS runtime environment which we are going to use throughout this topic.

Overall JS Engine Flow

Just as HTML and CSS undergo specific processes to render content on the screen, the JavaScript engine follows its unique architectural procedures. The diagram below outlines the overall structure of the JavaScript engine.

We will take a closer look at each one in detail, ensuring you have a clear understanding of how they all work together. But before diving into it, let’s briefly first touch base the Computer Science 101 – Preliminary JS Engine Overview.

Preliminary JS Engine Overview

JavaScript engines are complex pieces of software designed to process and execute JavaScript code. While different engines like V8 (used in Chrome and Node.js), SpiderMonkey (used in Firefox), and JavaScriptCore (used in Safari) may have specific optimisations and features, they all generally operate in a similar manner. In this section, we’ll quickly go over some initial concepts that are good to be aware of, though you don’t necessarily need to memorise them.

Parsing Phase

Lexical Analysis(Tokenization)

The engine reads the raw source code and breaking it down into ‘tokens,’ which are essentially the building blocks of the language—things like keywords, symbols, and identifiers.

Syntax Analysis(Creating the AST)

These tokens are then organised into an Abstract Syntax Tree (AST), which is a tree-like representation of the code’s structure, following the language’s syntax rules.

Compilation & Interpretation Methods

JavaScript engines use a Just-In-Time (JIT) compilation strategy, blending both compilation and interpretation.

Compilation

In traditional compilation, the entire source code is translated into machine code all at once, and then saved as a binary file for later execution.

Interpretation

The interpreter, on the other hand, directly executes the source code line by line, without pre-compiling it.

JIT Compilation

The entire code is compiled into machine code all at once but is executed immediately without being saved for later. This allows for optimisations during runtime.

This is just a brief touch on these complex processes and again you don’t need to memorise these details, but having an initial understanding can be helpful.

Now let’s dive into the crucial parts of how JavaScript engines function, which are essential for us to grasp as engineers.

Synchronous and Single threaded

JavaScript operates in a synchronous and single-threaded manner. Let’s break down these concepts and understand their implications in executing JavaScript code.

Synchronous Execution

When we say JavaScript is synchronous, it means that its code is executed in a sequence – one line at a time. Each line of code is executed in the exact order it appears. If a particular line of code takes longer to execute, it will block or delay the execution of subsequent lines until it is completed.

Let’s take a look at the following code snippet:

console.log('Statement 1');
longRunningFunction(); // this will take time to execute
console.log('Statement 3');
console.log('Statement 4');

In this example, Statement 1 will log first, but the subsequent logs (3 & 4) will have to wait until longRunningFunction() completes its execution. They are essentially blocked by the time-consuming longRunningFunction().

Single-threaded Execution

The term “single-threaded” in JavaScript’s context means that there’s only one call stack, and JavaScript can process one task at a time. If a function takes longer to complete, it occupies the call stack, preventing other functions from running until it is finished.

We will deep dive into the call stack through this series, so don’t worry if you are not sure what the call stack is and how it exactly works now.

Let’s take a look at another example:

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

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

function third() {
  console.log('Third Function');
}

function fourth() {
  console.log('Fourth Function');
}

first();
longTaskFunc();
third();
fourth();

In this scenario:

firstFunc() gets pushed onto the call stack and quickly pops off after it's executed.
longTaskFunc() goes next onto the call stack. However, due to its time-consuming loop, it remains there for a significant amount of time.
thirdFunc() and fourthFunc() have to wait until longTaskFunc() completes and is removed (or "popped off") from the call stack.

So, while we've discussed the synchronous and single-threaded nature of JavaScript, you might also be aware that JavaScript is capable of handling asynchronous operations. Let’s quickly talk about what async is.

How about async?

As we discussed above, JavaScript's main execution is synchronous. But it's equipped with features that allow it to handle operations asynchronously.

In the context of JavaScript, asynchronous operations allow code to be executed independently of the main program flow. This means that JavaScript doesn't wait for an async task to complete and can move on to the next task. Once the async operation is done, it reintroduces the result into the main flow through mechanisms like callbacks, promises, or async/await.

Let's consider the use of setTimeout, a classic example of asynchronous behaviour in JavaScript:

console.log('Start');

setTimeout(function() {
  console.log('Async operation using setTimeout');
}, 2000);

console.log('End');

In this situation, can you predict the sequence in which the messages will appear?

It will be:

Start
End
Async operation using setTimeout

So Start is logged first. And then the setTimeout function schedules a function to be executed after 2 seconds. JavaScript doesn't wait for those 2 seconds to elapse; it immediately logs End. After the 2 seconds have passed, Async operation using setTimeout is logged.

Now let’s change the delay time to 0.

console.log('Start');

setTimeout(function() {
  console.log('Async operation using setTimeout');
}, 0);

console.log('End');

Now can you guess the sequence of the messages?

It will still be:

Start
End
Async operation using setTimeout

Surprised? We will deep dive into why it works this way but before getting into it, let’s briefly talk about the async operations and other parts of the JS engines which will finally help you understand the entire flow of the async operations.

Brief Explanation of Asynchronous Operations

Asynchronous operations in JavaScript don't block the execution of the subsequent lines of code or functions. Instead, they offload tasks that might take a while, such as I/O operations or timers, to the browser's Web APIs. Once the browser completes the task, the callback (or other mechanisms like promises) gets pushed into a task queue. The Event Loop checks this queue and pushes callbacks into the call stack (where functions are executed) when the call stack is empty.

In summary, although JavaScript remains single-threaded and mainly synchronous, its environment allows it to manage asynchronous operations efficiently.

In the upcoming sections, we will dive deeper into understanding of asynchronous JavaScript, JS Runtime Environment, Web APIs, Task Queue, Event Loop, Memory Heap and Call Stack and related concepts.

Memory Heap & Call stack

At a high level, the JavaScript engine's architecture comprises two primary components: the memory heap and the call stack.

Briefly, the memory heap is a dynamic storage area where JavaScript allocates memory for objects and other complex data structures, whereas the call stack is a structured, LIFO-based (Last In, First Out) region dedicated to tracking the execution of functions and storing primitive data types. While the heap offers flexibility for variable-sized data storage, the call stack ensures orderly execution and tracking of function calls.

Let's take a closer look at their roles and functionalities, starting with the memory heap.

Memory Heap

Memory heap serves as JavaScript's large, flexible data store, primarily catering to dynamic memory allocation storing objects (arrays are special kinds of objects in JS).

This expansive space allows the memory heap to house the data structures of both objects and arrays. However, the actual connection to these stored structures isn't direct. Instead, a reference, akin to a map marker, is positioned on the call stack. This marker directs operations to the precise location within the memory heap where the desired data resides.

Consider the array declaration: let numbers = [1, 2, 3, 4, 5];. In this scenario, the contents of the array, [1, 2, 3, 4, 5], are allocated space within the memory heap. Meanwhile, the variable numbers remains on the call stack, serving as our guidepost to the array's location in the heap.

Garbage Collections

In the JavaScript world, an essential process ensures that memory which is no longer in use gets cleaned up. This process is called "garbage collection." It prevents potential issues such as memory leaks, which can hinder performance over time.

JavaScript automatically reclaims this memory, meaning developers don't always need to manually free up space. The browser's JavaScript engine efficiently handles memory management in most cases.

But how does the engine determine what memory to reclaim? The primary criterion is reachability. If objects or data structures are no longer accessible or referenceable from the root or main execution context, they are considered "unreachable.”

Let's illustrate this with a simple example:

function createPlanet() {
  let planet = { name: "Pluto" };
  return planet;
}

let pluto = createPlanet();

Initially, when the createPlanet function is called, a new object is created, and its reference is assigned to the pluto variable. This object is "reachable" because it can be accessed using the pluto variable.

However, when we later set pluto to null, the original object has no references pointing to it. It becomes "unreachable."

function createPlanet() {
  let planet = { name: "Pluto" };
  return planet;
}

let pluto = createPlanet();
pluto = null;

At this point, the garbage collector recognises this and can safely reclaim the memory allocated to that object.

Garbage collection does a lot to help, but sometimes memory leaks still happen. These leaks can slow down our apps. Let's explore a few examples to understand how they occur.

Memory Leaks

Memory leaks occur when applications allocate memory for some operations but fail to release it back to the system once those operations are done. This retained memory, which isn't in use but hasn't been reclaimed, is what we call a "leak." Over time, such leaks can accumulate, causing the application to slow down or even crash due to exhaustion of available memory.

Even with tools like garbage collection assisting in memory management, leaks can still emerge from various programming patterns or oversights. Let’s take a look at some examples of memory leak scenarios.

1. Global variables

Global variables, while occasionally useful, come with the risk of introducing memory leaks into your JavaScript applications. If not managed correctly, they can retain references to objects long after those objects have served their purpose.

Over time, these unnecessary references accumulate, steadily consuming memory. This clutter in the memory heap can lead to diminished performance, and in severe cases, can cause the browser to become sluggish or even unresponsive.

Imagine an application where global variables are used to temporarily store data fetched from an API.

let globalData = null;

function fetchData() {
    // Simulated API call
    globalData = {
        largeDataSet: new Array(1000000).fill('data')
    };
}

If globalData is not properly managed, it will keep occupying memory even if the data it holds isn't needed anymore.

To mitigate such risks:

Prioritise Local Variables: Always lean towards using local variables within functions, as they get garbage collected once the function's execution context is popped off the call stack.
Nullify Global Variables: When you're done with a global variable, explicitly set its value to null. This breaks the reference, allowing the garbage collector to reclaim the memory.

2. Event Listeners

Event listeners that aren't properly removed can hold onto memory, especially if the DOM elements they're attached to are deleted.

Let’s take a look at an example.

var button = document.getElementById('myButton');
button.addEventListener('click', onClick);

// Later in the code
button.remove();  // The element is removed, but the event listener still exists

To resolve the issue, ensure event listeners are properly removed, especially before deleting their associated DOM elements:

button.removeEventListener('click', onClick);
button.remove();

3. Intervals and Timers

Intervals and timers in JavaScript can unintentionally retain references to objects. This means that even if you attempt to de-reference an object by setting it to null, it remains in memory due to the active interval or timer.

Here is an example.

let someObject = {
  data: "I'm an object!"
};

let interval = setInterval(function() {
  console.log(someObject.data);
}, 1000);

// Later
someObject = null;  // The original object is still referenced by the interval

To free up the memory, always ensure you clear the intervals or timeouts when they're no longer required, particularly when they reference objects you intend to release:

clearInterval(interval);
someObject = null;

4. Clousures

Closures allow functions to maintain access to an outer function's scope even after that outer function has concluded its execution. This powerful feature, while offering flexibility and novel programming patterns, also behaves as a double-edged sword. If not managed with awareness, closures can inadvertently cause memory leaks by retaining more data than necessary.

Note: I will be publishing a dedicated article that deep-dives into the closures in a future article, so stay tuned for a comprehensive exploration.

Let’s take a look at the example below.

function outerFunction() {
  let largeArray = new Array(1000000).fill('data');

  return function() {
    return largeArray[0];
  }
}

let innerFunction = outerFunction();

The outerFunction creates a big array, largeArray then proceeds to return an inner function, a closure, which retains a reference to largeArray. After the execution of outerFunction(), its context doesn't vanish from memory due to the inner function's ongoing reference to largeArray. Consequently, the entirety of largeArray remains in memory, although the inner function merely taps into its first element. Such behaviour inadvertently inflates memory use.

To improve this, let’s take a look at the refined function below.

function refinedOuterFunction() {
  let largeArray = new Array(1000000).fill('data');
  let firstItem = largeArray[0];

  return function() {
    return firstItem;
  }
}

let refinedInnerFunction = refinedOuterFunction();

Instead of retaining a direct reference to largeArray within the returned function, the necessary data , firstItem, is isolated beforehand (line 3). Now the closure references solely firstItem, bypassing the entirety of largeArray.

After refinedOuterFunction finishes, the inner function retains a reference only to firstItem, not the entire largeArray. Since no other part of the code is holding onto or referencing largeArray, the garbage collector in the JavaScript engine recognises it as unreferenced and can clear out the memory it used, helping in efficient memory management.

What's in Part 2?

In the Part 1, we talked about the essentials of JavaScript, jumping into its synchronous and single-threaded nature, along with a brief introduction to asynchronous programming. We also took a detailed look at the Memory Heap.

Moving forward, we'll turn our focus to another critical aspect of the JavaScript engine: the Call Stack. In Part 2, we'll dive deep into understanding everything related to the call stack and execution context.