DEV Community: Della Dominic

How JavaScript code runs behind the scenes | Execution Context

Della Dominic — Wed, 18 Feb 2026 17:07:14 +0000

Understanding how JavaScript code is executed is crucial whether you are learning the language or working with it regularly. To truly understand how hoisting works, why a ReferenceError is thrown, or in what order your code executes — these are just a few reasons why this concept is important.

First things first, always remember that JavaScript is a single-threaded, synchronous language. Now what does that mean? In simple terms, single-threaded means JavaScript has only one call stack and can execute one task at a time. This execution happens synchronously i.e. code is executed one ‘after’ the other. The thread of execution executes a line at a time, ‘waits’ for it to complete and then executes the next line.

Note: JavaScript executes code synchronously by default, but can handle asynchronous operations using the event loop, Web APIs, callbacks, promises, and async/await.

Note: The call stack follows the Last In, First Out (LIFO) principle.

What is an Execution Context ?

JavaScript code is executed in an environment called Execution Context. So, whenever a JavaScript program or script runs, an execution context is created to execute the JS code.

Note: An execution context is also created within the main context when a JavaScript function is called or invoked.

There are two parts in an execution context:

Memory part (variable environment): This is where all variables, constants and functions are stored as key-value pairs (we will see how exactly in some time :)
Thread of execution: This is where code is executed one line at a time, one after the other.

There are two types of execution context:

Global Execution Context (GEC): This is the main execution context created for the program, as soon as it starts executing. It contains a global memory and a thread of execution. All top-level code runs inside the Global Execution Context. Remember there is only one global execution context per program. This context is deleted after the program is fully executed.

Function Execution Context (FEC): Whenever a function is called or invoked (recognised by the parenthesis next to the function name eg. sum(2,3) or showSum(), a new execution context for that function specifically is created inside the global execution context. This function execution context has its own memory space known as local memory and its own thread of execution where every line of code in the ‘function definition’ (till return) is executed. This context is deleted once the return statement in the function is executed or after execution of the last line in the function body (in case there is no return statement) whereupon JavaScript will implicitly return undefined.

Note: A function execution context has access to its local memory and also the global memory! But the Global execution cannot access a local memory. The global context does not have access to variables declared inside a function, because they are scoped to that function.

An Execution context is created in two phases:

Phase 1- Memory creation phase: This is the phase before the code is actually executed. Initially, each line in the script is parsed and memory is allocated for every defined variable, constant and function. During the memory creation phase, var variables are initialised with undefined. Let and const declarations are hoisted but remain uninitialised in the Temporal Dead Zone until their declaration is executed. Function declarations are fully hoisted with their function definition. During parsing (before execution), syntax errors are detected.

Phase 2-Code execution phase: Once the memory is allocated in the global space or memory of global execution context, the code is executed in this phase line by line from first line to last, one line after another, one line at a time. This is where thread of execution is created and actual code execution takes place i.e., all calculations are made and resulting values are assigned to existing labels in memory and function calls are executed (leading to creation of function execution context which again follows these two phases).

Note: Why did I emphasise above that the values are assigned to existing labels ? What happens if there are no labels i.e. no allocated memory?

'use strict';
var num = 5;
numSquare = num * num; // ReferenceError at runtime

Consider above example, to understand what I meant when I said ‘values are assigned to existing labels in memory’ . What will be the output of the above code? Yes, it will throw a ReferenceError: numSquare is not defined. Well, most of you already know what this means — we are trying to refer to a variable named ‘numSquare’ that is not even defined, hence the error. But now think about how this error is caught in terms of what happens in the execution context. This was caught during run time i.e. during the code execution phase when we were executing line numSquare = num * num;. What we do here is that we calculate num * num i.e. 5 * 5 which results in 25 and now try to assign it to the memory location labelled as numSquare i.e. we try to assign the calculated value, 25 to the existing label, numSquare. Remember that memory is allocated during the memory creation phase for variables declared using var, let, or const. Since numSquare was never declared, no memory was allocated for it. Therefore, when JavaScript tries to assign a value to it during execution (in strict mode), it throws a ReferenceError.

How is JavaScript code executed ?

We have learned that JavaScript code is executed in an execution context. Understanding how JavaScript is executed behind the scenes is essentially same as understanding how the execution context is created through the 2 phases in detail. Let’s dive deep with an example.

var a = 4;                  //line 1
function multiply(x, y) {     //line 2
    var result = x * y;       //line 3
    return result;            //line 4
}                             //line 5
var b = 5;                    //line 6
var output = multiply(a, b);  //line 7

Let’s see what happens when the above code is run step by step.

1. Firstly a global execution context (GEC) is created and pushed into a stack (known as call stack) to keep track of the thread of execution i.e. to keep track of the line of control in the entire program.

Call stack

--->| GEC               |
    ---------------------

2. Next, memory is created for the GEC, (phase 1 of GEC creation). What happens here is that the entire program is ‘parsed’ line by line to allocate space for all defined variables and function. At the end of this phase this is how the global memory would look like:

a: undefined
multiply: function multiply(x, y) {     
    var result = x * y;       
    return result;            
}
b: undefined
output: undefined

Note: As mentioned earlier, undefined will be assigned initially to all variables and constants — a, b, output. Whereas the entire function code is assigned to the function — multiply.

3. Now, we enter the second phase of GEC creation — thread of execution or code execution phase. This is where the code starts executing starting from line 1.

4. Firstly, line 1 is executed. Here, 4 is assigned to the constant ‘a’. So, in the memory space we lookup allocated memory labelled as ‘a’ and assign 4 to it.

a: 4
multiply: f // the function's entire code is stored here
b: undefined
output: undefined

5. Now moving to line 2, which is a function definition (from line 2 to 5). Nothing to execute here (as it is not a function call but just a definition)

6. We have the function definition till line 5. So the next statement to be executed is in line 6, wherein we assign 5 to variable ‘b’. So, in the memory space we lookup allocated memory labelled as ‘b’ and assign 5 to it.

a: 4
multiply: f
b: 5
output: undefined

7. On line 7, we are calling the multiply function with the arguments a , b and then assign the result returned to the variable output. Here, the function call is first executed. So as we know, here a Function Execution Context (FEC) is created for the function ‘multiply’ and this is also pushed into call stack, with the point of control now pointing to line 2.

Call stack

--->| multiply(4,5)//FEC |
    ---------------------
    |  GEC               |
    ---------------------

8. Local Memory for the FEC is created by parsing lines 2 to 5 (where function multiply is defined). At the end of this step, the memory of FEC looks like below:

x: undefined
y: undefined
result: undefined

Note here that, the parameters x and y are also allocated memory.

9. Now begins the thread of execution phase of the FEC i.e. the function’s code execution starting with assigning the arguments a and b that evaluates to 4 and 5 (from the global memory) to the parameters x and y respectively.

x: 4
y: 5
result: undefined

10. Next line 3 is executed where values of x and y are multiplied and assigned to result. So here, 4 * 5 is calculated and the product 20 is assigned to local variable result in the local space.

x: 4
y: 5
result: 20

11. Now point of control moves to the next line i.e. line 4 where the result is returned. JavaScript looks up result in the function’s local memory and returns it to the Global Execution Context. Two main things happen next. As soon as the return statement is executed the Function execution context is deleted. It is popped out from the call stack and now the control moves back to the GEC to the line where the function was originally invoked.

Call stack

    |                    | ----------> multiply(4,5)//FEC is popped out

--->|  GEC               |
    ---------------------

12. The control is now back at line 7 where the function has returned the result 20 and this is now assigned to the global variable ‘output’.

a: 4
multiply: function multiply(x, y) {     
    var result = x * y;       
    return result;            
}
b: 5
output: 20

13. Now the program is fully executed. Therefore the GEC is deleted i.e. it pops out from the call stack and the JavaScript code execution is complete. (Finally…)

Call stack

    |                    | ----------> GEC is popped out
    ----------------------

Understanding execution context is the foundation for mastering hoisting, closures, scope, and asynchronous JavaScript. Once this mental model clicks, everything else becomes easier.

Happy coding. Cheers!

4 Practical Applications of Closures in JavaScript

Della Dominic — Tue, 17 Feb 2026 18:01:36 +0000

When I first learned about closures, I thought they were rarely used and that I probably wouldn’t come across them often. What I didn’t realise then was that every time a function is created, a closure is formed automatically, because a function maintains a reference to its lexical environment.

Closures are not just a theoretical concept. They are everywhere in our codebase, and they have powerful real-world use cases. Understanding these use cases, I believe, is crucial to truly understanding closures.

Let’s look at four powerful applications of closures.

1. Data Privacy & Encapsulation

Closures help you create private variables in JavaScript, preventing accidental modifications and protecting internal state.

2. Function Factories

Closures make it possible to build tailored functions on demand. This pattern works especially well with the Fetch API, where you can create reusable and pre-configured API clients.

3. Preserving State in Callbacks & Event Handlers

Closures are crucial for managing state in asynchronous operations. When you use addEventListener() to register an event handler, the callback retains access to variables from its outer scope.

4. Memoization (Caching Results)

Closures can be used to memoize expensive operations by caching previous results. This improves performance by avoiding repeated calculations.

What once felt like an abstract concept turned out to be one of the most practical tools in JavaScript. The real power of closures isn’t in their definition — it’s in how often and how effectively we use them.

Happy Learning!✨

The split personality of the + operator

Della Dominic — Mon, 16 Feb 2026 09:29:49 +0000

Type coercion can be confusing if not well understood. Let's see how JavaScript converts (or coerces) around the + operator.

The split personality

Why do we get string the first time and a number the second time when in both case we are trying to do mathematical operations?

Well, JavaScript does not just do math, it looks at its operands and decides what needs to be done. So if we have just numbers like 5 + 3 // 8 then it's pretty straightforward, however if at least one operand is a string along with the + operator, then the number is converted to string and string concatenation is what JavaScript will do. It will convert the number 2 in the above example to string"2" and then performs "5" + "2" to give "52".

What about the second operation? here, JavaScript converts the string to number and performs a mathematical operation and returns 2. When we use mathematical operators, JavaScript performs arithmetic. However, if the + operator has at least one string operand, it performs string concatenation. Otherwise, it performs arithmetic.

Order matters!

JavaScript evaluates your operation from left to right. Hence if you do 1 + 2 + '3' first 1 + 2 is calculated resulting in 3. Then it evaluates 3 + '3', where we are adding the number 3 to the string '3'. Therefore the numbers get implicitly converted to string and gets concatenated with the other string to give '33'.

Notice in the second scenario we have the string first. '1' + 2 + 3 becomes '12' + 3 which returns '123'.

BaNaNa?!

Let's see another interesting example.

Why does "Ba" + + "test" +"a" evaluate to 'BaNaNa'? Let's break this down. Here we are trying to concatenate "Ba" with +"test". Adding the unary plus operator to string (+"a string") is one way you can explicitly convert a string to a number (the unary plus trick). So +"test" becomes NaN, resulting in "Ba" + "NaN" + "a" giving you "BaNaNa"🍌!

To recap, the + operator in JavaScript is overloaded — its behavior depends entirely on the types of its operands.

Understand the types, and you understand the result.

Happy learning! ✨

Call by sharing: Understanding why JavaScript does NOT pass objects By Reference

Della Dominic — Sun, 15 Feb 2026 12:21:59 +0000

For a long time I thought primitive types are shared by value and objects are shared by reference in javascript. Today I learned however that javascript always pass by value (According to the ECMAScript specification), both primitive types and objects. However when passing objects the value that is being passed is the reference.This behaviour is known as 'call by sharing' and NOT pass by reference. let's see why...

Call by Sharing: How JavaScript Passes Objects

Let's first see how primitive values are passed.

Consider the below code:

function setName(copyOfName){
    copyOfName = "John";
}

let name ="Della";
setName(name);
console.log(name);// "Della"

It's pretty straightforward and easy to understand why primitive types are passed by value. Here we are passing the argument, 'name' that is assigned to the parameter, 'copyOfName'. That is, copyOfName now contains a copy of the variable, name, which has the value "Della". and reassigning copyOfName to "John" only affect this copy not the original name variable.

Now what if we were passing an object?

consider the below code:

function setPerson(copyOfPerson){
    copyOfPerson.name = "John"; // here we are MUTATING
}

let person = {
    name: "Della",
}
setPerson(person);
console.log(person); // { name: "John" }

Here we have an object person with name as "Della" which we are passing to the function's parameter, copyOfPerson by pass by value. But the value passed here is a copy of the reference. Hence both copyOfPerson and name point to the same object. Therefore, any modification or mutation (NOTE, I am mutating the object NOT re-assigning! - Big Difference) to the copy affects the original object since both point to the same object. That is why person becomes { name: "John" } when copyOfPerson is modified.

Now you might ask - isn't this what is known as 'Pass by Reference' ?!

Well...not really. The above code works the way it works fundamentally because an object variable contains a reference value.That reference value is itself the value stored in the variable. So technically, the reference is the value! And that's why we say javascript passes reference by value.

To prove programmatically, let's consider the below code, where we try to 're-assign' the copy.

function setPerson(copyOfPerson){
    copyOfPerson = {
        name: "John",
    }// here we are RE-ASSIGNING
}

let person = {
    name: "Della",
}
setPerson(person);
console.log(person); // { name: "Della" }

If the object was truly passed by reference, even reassigning would change the original object. However that is not the case. Here, local rebinding happens. a new object is created and it's reference is assigned to copyOfPerson. Therefore it no longer points to person and that is why person remains same ,{ name: "Della" }. This is called 'call by sharing' also known as 'call by object sharing'

To recap, JavaScript is a pass-by-value language. However, when passing objects, the value being passed is the reference to the object. This behaviour is known as call-by-sharing. In call-by-sharing, when an object is passed to a function, a copy of the reference is created and thus objects are shared. However, variable binding is not shared. So mutating the parameter modifies the original object but reassigning the parameter does not affect the original object.

Happy learning! cheers ✨

Why does 0.1 + 0.2 === 0.3 return false?

Della Dominic — Fri, 13 Feb 2026 14:07:05 +0000

Javascript uses IEEE 754 floating point representation for storing numbers. This means that some decimal fractions (like 0.1) cannot be represented exactly in binary floating-point format.

So how DO we work with decimals?

1. Compare with tolerance for equality checks

Taking into consideration the small error difference, Instead of comparing 2 decimals with equality operator we will check if the difference between them is less than the tolerance value.

Javascript provides a static property, Number.EPSILON that represents the smallest difference. Using this we can compare the equality of decimals as shown below:

Note: Number.EPSILON works well when numbers are around magnitude 1, but for larger numbers we might scale EPSILON accordingly.

2. Working with Money?

Avoid floating-point arithmetic for financial calculations. Use integers (cents/paise) or dedicated decimal libraries. Always convert to cents, not dollars. This is Recommended in terms of working with billing or payment logic in Fintech Apps.

3. Use Intl.NumberFormat for display

4. Use toFixed() for simple rounding

Note: Can you think what would be the output of below code?

console.log((0.1 + 0.2).toFixed(2) === 0.30);

This will return false since toFixed() returns a string not a number and hence the strict equality check fails!

Happy learning! cheers✨