Consider the code bellow:

console.log('My age is', age)
console.log('My name is', name)
console.log('My country is', country)

var age = 24
let name = 'Shejan'
const country = 'Bangladesh'
sayHi()
function sayHi() {
  console.log('Hi!')
}

What do you think the output of this code will be?

The first line will probably print undefined, right? But what about the second line with name? This will throw a “ReferenceError: Cannot access name before initialization.” Why? Because let variables are hoisted but remain uninitialized in the temporal dead zone (TDZ) until their declaration line is reached.

The third line with country will never execute because the code stops at line 2 due to the ReferenceError. But if line 2 wasn’t there, line 3 would throw the same error for the same reason – const also stays in the TDZ.

And what about the sayHi() function call? If we could reach it, it would work perfectly and print "Hi!" because function declarations are fully hoisted with their complete body.

The main question: why and how is all this happening? Let's dive in and find answers to these questions.

Here’s What We’ll Cover:

• How Does the Global Execution Context Work?

• Memory Creation Phase

• Understanding the Flowchart

• What Exactly is Hoisting?

• Does Only var Get Hoisted?

• Temporal Dead Zone (TDZ) – What is it Really?

• Function Hoisting – The Most Interesting Part!

• What Happens in the Memory Phase:

How Does the Global Execution Context Work?

When we run any JavaScript code, the very first thing that happens is the creation of a Global Execution Context (GEC). This is the fundamental concept behind JavaScript execution! This global execution context has two important phases:

1. Memory creation phase (memory phase)

2. Code execution phase (thread phase)

Let's look at what happens in each phase, one by one.

Memory Creation Phase

This is the preparation time. During this phase, the JavaScript engine scans through the entire code once (without executing it) and allocates memory for all variables and functions.

But here's where it gets interesting:

• Variables (var, let, const) are given space in memory.

  • var is assigned the value undefined.

  • let and const are placed in memory but remain uninitialized.

  • Functions (function declarations) are stored in memory with their complete code body.

So what happens in the memory phase for our example code?

age: undefined
name: <uninitialized>
country: <uninitialized>
sayHi: function() { console.log("Hi!"); }

As you can see, even before a single line of code is executed, everything is already in memory! This entire process of lifting variables and functions into memory during the memory creation phase is called Hoisting – and this is what makes JavaScript execution seem "magical."

Code Execution Phase

Now the real action begins! The JavaScript engine starts executing the code line by line.

Line 1: console.log("My age is", age);

• Looks for age in memory

• Finds undefined

• Output: My age is undefined

Line 2: console.log("My name is", name);

• Looks for name in memory Finds that it exists in memory but hasn't been initialized yet (it's in the temporal dead zone, or TDZ – we'll explore this concept in detail later).

• Output: ReferenceError: Cannot access name before initialization.

The code execution stops right here! The remaining lines won't be executed.

But what would happen if Lines 2 and 3 weren't there?

Line 4: var age = 24;

• The value of age in memory gets updated from undefined to 24

Line 5: let name = "Shejan";

• name is now initialized with the value "Shejan"

• From this point forward, name can be accessed

Line 6: const country = "Bangladesh";

• country is initialized with the value "Bangladesh"

Lines 7-9: Function call

• The sayHi() function was already loaded with its complete body during the memory phase.

• When sayHi() is called, the JavaScript engine creates a new execution context specifically for this function.

• This new context is known as a Function Execution Context (FEC) – it works as a child of the global execution context.

This function execution context also has two phases, just like the global execution context:

1. Memory Creation Phase:

   • All variables, parameters, and nested functions inside the function are allocated in memory.

   • Function arguments are assigned.

   • A function scope is created and a reference link is established with the outer lexical environment (where the function was defined) – this link is called the scope chain. The scope chain is JavaScript's way of resolving variable names. It's like a chain of connected scopes. When JavaScript looks for a variable inside a function, it first checks the function's own scope. If it doesn't find the variable there, it moves up the chain to check the parent scope (where the function was defined), then the grandparent scope, and so on, until it reaches the global scope. This chain ensures that functions can access variables from their outer environments.

2. Code Execution (Thread) Phase:

   • Now the function body is executed line by line.

   • console.log("Hi!"); executes and prints "Hi!"

Once the function execution is complete:

• That function execution context is popped off the call stack.

• And control returns to the global execution context.

Note: When all code execution is complete, the global execution context is also popped off the call stack.

The flowchart diagram above illustrates the JavaScript global execution context workflow, showing the two phases. In the memory creation phase, variables and functions are allocated, and in the code execution phase, the code runs line by line. It also shows how the function execution context is created when functions are called.

Understanding the Flowchart

The diagram above visualizes the complete journey of JavaScript code execution from start to finish.

The flow begins when JavaScript execution starts and immediately creates a global execution context (GEC). This context then splits into two distinct phases, shown as a diamond in the diagram.

On the left side - Memory Creation Phase: You can see three parallel branches showing how different types of declarations are handled:

• var variables are allocated with the value undefined

• let and const variables are allocated but remain uninitialized (in the temporal dead zone)

• Function declarations are fully hoisted with their complete body

On the right side - Code Execution Phase: JavaScript now executes the code line by line. During execution:

• It accesses variable values from memory

• If you try to access let or const before initialization, you get a ReferenceError (temporal dead zone)

• If you access var before assignment, you get undefined

• When a function is called, a new Function Execution Context (FEC) is created

The Function Execution Context (FEC) (shown in the right branch) works as a child of the GEC and has its own Memory and Execution phases. After the function executes completely, the FEC is popped off the call stack and control returns to the GEC.

Finally, when all code execution is complete, the GEC itself is popped from the call stack, and the program ends.

This visual representation helps you understand that JavaScript doesn't just read and run your code - it prepares everything first (Memory Phase) and then executes it systematically (Execution Phase).

What Exactly is Hoisting?

Hoisting is JavaScript's default behavior of moving variable and function declarations to memory before code execution begins.

Think of it this way – it appears as if all declarations automatically move to the very top of the code. Although the code doesn't physically move, the memory allocation happens first.

Does Only var Get Hoisted?

This surprises many people, but the answer is no. It's not just var that gets hoisted! This is a huge misconception among many developers.

The truth is that—let, const, and functions—everything gets hoisted! But their behavior is completely different. Let's dive into the details.

What Happens with var?

console.log(name) // undefined
var name = 'Rahim'
console.log(name) // "Rahim"

Variables declared with var:

• Get hoisted

• Are initialized with undefined

• Exist in global scope or function scope

• Can be accessed before declaration (doesn't throw an error)

What Happens with let?

console.log(name) // ReferenceError: Cannot access 'name' before initialization
let name = 'Rahim'
console.log(name) // "Rahim"

Is this magic? No! Actually, let does get hoisted, but it's stuck in a special state called the temporal dead zone!

Space is allocated in memory, but it's not initialized. So if you try to access it before declaration, JavaScript says – "Hey, the variable exists, but you can't use it yet!"

What Happens with const?

console.log(age) // ReferenceError: Cannot access 'age' before initialization
const age = 24
console.log(age) // 24

The behavior of const is exactly the same as let:

• Gets hoisted

• Stays in the TDZ until declaration

• Exists in block scope

• Plus, once assigned, it cannot be reassigned

Temporal Dead Zone (TDZ) – What is it Really?

The Temporal Dead Zone is the time period or zone when a variable exists in memory (due to hoisting) but hasn't been initialized yet. During this time, the variable is essentially "dead" – meaning that you cannot access it.

// ← TDZ starts for x and y
console.log(x) // ReferenceError - still in TDZ
console.log(y) // ReferenceError - still in TDZ

// TDZ continues...
let x = 10 // ← x's TDZ ends at this line
const y = 20 // ← y's TDZ ends at this line

console.log(x) // 10 - can access now
console.log(y) // 20 - can access now

The entire concept of TDZ is to force us to write better code. Using variables before declaring them is a bad practice, and TDZ prevents us from doing that.

Function Hoisting – The Most Interesting Part!

Hoisting with functions is even more interesting and powerful:

greet() // "Hello World!" - Perfect! It works!

function greet() {
  console.log('Hello World!')
}

How is this possible? Because function declarations are completely hoisted! This means not just the name, but the entire function body is lifted into memory. That's why it can be called even before the declaration.

But wait! Not all functions work this way.

With Function Expressions:

greet() // TypeError: greet is not a function

var greet = function () {
  console.log('Hello World!')
}

What happened here? greet was hoisted as a variable and received the value undefined. It wasn't hoisted as a function! So when you try to call it, you get an error. In other words, it's hoisted as a variable (assigned undefined), but the function body isn't loaded into memory.

With Arrow Functions:

sayHello() // ReferenceError (if let/const is used)

const sayHello = () => {
  console.log('Hello!')
}

Arrow functions behave just like function expressions. They follow variable rules.

Let's clear everything up with a complete example:

console.log(a) // undefined (var hoisting)
console.log(b) // ReferenceError (TDZ)
console.log(c) // ReferenceError (TDZ)
multiply(2, 3) // 6 (function hoisting)
add(2, 3) // TypeError (function expression)

var a = 10
let b = 20
const c = 30

function multiply(x, y) {
  return x * y
}

var add = function (x, y) {
  return x + y
}

What Happens in the Memory Phase:

a: undefined
b: <uninitialized>
c: <uninitialized>
multiply: function(x, y) { return x * y; }
add: undefined

This snapshot represents the state of memory before any code is executed. Here's what each line means:

a: undefined - Since a is declared with var, it gets hoisted and immediately assigned the value undefined. This is why you get undefined instead of an error when you try to access a before its declaration line.

b: <uninitialized> - The variable b is declared with let, so it's hoisted and memory is allocated for it, but it remains uninitialized. It's in the Temporal Dead Zone (TDZ). Attempting to access it before the declaration line will throw a ReferenceError.

c: <uninitialized> - Similarly, c is declared with const and follows the same behavior as let. It's hoisted but stays uninitialized in the TDZ until the declaration line is reached.

multiply: function(x, y) { return x * y; } - This is a function declaration, so it's fully hoisted with its complete body. The entire function is stored in memory and ready to be called even before the JavaScript engine reaches its declaration in the code. This is why multiply(2, 3) works perfectly and returns 6.

add: undefined - Here's the crucial difference! Even though add will eventually store a function, it's declared using var add = function() {...} (a function expression). During the memory phase, only the variable add is hoisted and initialized with undefined. The actual function body isn't assigned until the execution phase reaches line 11. This is why calling add(2, 3) before the assignment throws a TypeError: add is not a function - you're essentially trying to execute undefined().

Conclusion

Understanding JavaScript's execution mechanism is fundamental to becoming a proficient developer. Let's recap the essential concepts we've explored:

The Global Execution Context (GEC) is the foundation of JavaScript execution. Every time you run JavaScript code, the GEC is created first. It works in two critical phases:

• Memory Creation Phase: JavaScript prepares by scanning the code and allocating memory for variables and functions.

• Code Execution Phase: JavaScript runs your code line by line.

Hoisting is universal - not just limited to var. Here's how different declarations are hoisted:

• var variables are hoisted and initialized with undefined.

• let and const are hoisted but remain uninitialized in the TDZ.

• Function declarations are fully hoisted with their entire body.

• Function expressions and arrow functions follow variable hoisting rules

The Temporal Dead Zone (TDZ) is JavaScript's built-in safety mechanism. It exists from the start of the scope until the variable declaration line is reached. The TDZ prevents us from accessing let and const variables before they're declared, encouraging better coding practices and helping us avoid bugs.

Function hoisting behavior varies:

• Function declarations can be called before they appear in code.

• Function expressions behave like variables and cannot be called before assignment.

• Arrow functions follow the same rules as function expressions.

Why does this matter? Understanding these concepts helps you:

• Predict how your code will behave before running it.

• Avoid common errors like ReferenceError and TypeError.

• Write cleaner, more maintainable code.

• Debug issues faster when they arise.

• Make informed decisions about when to use var, let, or const.

The key takeaway: JavaScript doesn't just execute your code - it prepares first, then executes. The memory phase sets up the stage, and the execution phase performs the show. Master this two-phase process, and you'll have a solid understanding of how JavaScript works under the hood.

Now you're equipped with the knowledge to write better JavaScript code and understand exactly what's happening behind the scenes. Keep practicing these concepts, and they'll become second nature!

Happy Coding!

If these questions have crossed your mind, you're not alone. These are some of the most fundamental concepts in JavaScript, yet they often confuse developers.

In this tutorial, we'll demystify prototypes, prototype chains, and inheritance in JavaScript. By the end, you'll understand the "what," "why," and "how" of JavaScript's prototype system.

Here’s what I’ll cover:

• The String Method Mystery

• How Objects Work Internally

• Understanding the Prototype Chain

• Why Everything in JavaScript is an Object

• The Difference Between proto and prototype

• How Prototypes Work with Functions

• How Prototypes Work with Classes

• Conclusion

Prerequisites

To get the most out of this tutorial, you should have:

• Basic understanding of JavaScript fundamentals

• Familiarity with objects, functions, and classes in JavaScript

• Knowledge of how to declare and use variables

• Experience working with the new keyword (helpful but not required)

The String Method Mystery

Let's start with a simple example that demonstrates something interesting about JavaScript:

let name = "Shejan Mahamud";

After declaring this variable, we can use String methods like:

name.toLowerCase(); // "shejan mahamud"
name.toUpperCase(); // "SHEJAN MAHAMUD"

This seems normal at first glance, but wait – something unusual is happening. Notice anything odd here? We're using dot notation on a string primitive.

Here's the puzzling part: we know that strings are primitive types in JavaScript, not objects. So how can we use dot notation to access methods? After all, dot notation typically only works with objects.

The answer to this mystery lies in understanding how JavaScript handles primitives and prototypes. But before we get there, let's first look at how objects work internally.

How Objects Work Internally

When you create an object in JavaScript like this:

const info1 = {
  fName: "Shejan",
  lName: "Mahamud"
};

JavaScript does something interesting behind the scenes. It automatically adds a hidden property called __proto__ to your object. This property points to Object.prototype, which is the prototype of the built-in Object class.

You might wonder: does Object.prototype also have a __proto__? Yes, it does, but its value is null. This is because Object.prototype is at the top of the prototype chain and doesn't inherit from anything else.

Let's look at a more complex example to understand this better:

const info1 = {
  fName1: "Shejan",
  lName1: "Mahamud"
};

const info2 = {
  fName2: "Boltu",
  lName2: "Mia",
  __proto__: info1
};

const info3 = {
  fName3: "Habu",
  lName3: "Mia",
  __proto__: info2
};

In this example, we've intentionally set the __proto__ property for info2 and info3. Now here's an interesting question: can we access fName1 from info3?

console.log(info3.fName1); // "Shejan"

Yes, we can! Let's understand how this works.

Understanding the Prototype Chain

When you try to access a property on an object, JavaScript follows a specific lookup process:

1. First, it searches for the property in the object itself (the base object)

2. If it doesn't find it there, it looks in the object's __proto__

3. If it still doesn't find it, it continues up the chain, checking each __proto__ until it either finds the property or reaches null

In our example with info3.fName1:

• JavaScript first looks in info3 – and it doesn't find fName1

• Then it checks info3.__proto__, which points to info2 – it doesn't find fName1 there, either

• Next it checks info2.__proto__, which points to info1 – and it finds fName1 here!

This is called the prototype chain, and this is how inheritance works in JavaScript. Here's a visual representation:

┌────────────┐
│  info3     │
│ fName3     │
│ lName3     │
└────┬───────┘
     │ __proto__
     ▼
┌────────────┐
│  info2     │
│ fName2     │
│ lName2     │
└────┬───────┘
     │ __proto__
     ▼
┌────────────┐
│  info1     │
│ fName1     │
│ lName1     │
└────┬───────┘
     │ __proto__
     ▼
┌─────────────────┐
│ Object.prototype│
└────┬────────────┘
     ▼
    null

Each object points to the next object in the chain through its __proto__ property. This chain continues until it reaches null.

Why Everything in JavaScript is an Object

Now let's solve the mystery we started with: how can primitive types use object methods?

In JavaScript, almost everything behaves like an object, even though primitive types (like strings, numbers, and booleans) technically aren't objects. This works through a process called auto-boxing or wrapper objects.

Let's see this in action:

let yourName = "Boltu";

When you try to use a method on this string:

yourName.toLowerCase();

Here's what JavaScript does behind the scenes:

1. It temporarily wraps the primitive value in a wrapper object: new String("Boltu")

2. This temporary object's __proto__ automatically points to String.prototype

3. The method is found in String.prototype and executed

4. After the operation completes, the wrapper object is discarded

5. yourName returns to being a simple primitive value

This is why you can use methods on primitives even though they're not objects. JavaScript creates a temporary object, uses it to access the method, then throws it away.

The same process happens with other primitive types:

• Numbers use Number.prototype

• Booleans use Boolean.prototype

And so on. This elegant system is why developers often say "everything in JavaScript is an object" – even when it's not technically true, it behaves that way when needed.

The Difference Between __proto__ and prototype

This is one of the most confusing aspects of JavaScript for many developers. Let's break it down clearly.

What is prototype?

When you create a function or class in JavaScript, the language automatically creates a blueprint object called prototype. This happens behind the scenes.

Here's an example:

function Person(name) {
  this.name = name;
}

When JavaScript sees this function, it internally does this:

Person.prototype = { 
  constructor: Person 
};

The Person function now has a hidden property called prototype, which is an object containing a constructor property.

You can add methods to this prototype object:

Person.prototype.sayHi = function() {
  console.log("Hi, I'm " + this.name);
};

What is __proto__?

__proto__ is a property that exists on every object instance (arrays, functions, objects – everything). It's an internal reference or pointer that indicates which prototype the object inherits from.

By default, when you create an object, its __proto__ points to Object.prototype.

How They Work Together

When you use the new keyword:

const p1 = new Person("Shejan");

JavaScript performs these steps internally:

1. Creates a new empty object: p1 = {}

2. Sets the object's __proto__: p1.__proto__ = Person.prototype

3. Calls the constructor function with the new object: Person.call(p1, "Shejan")

4. Returns the object: return p1

Now when you try to access a method:

p1.sayHi(); // "Hi, I'm Shejan"

JavaScript looks for sayHi in p1 first. When it doesn't find it, it checks p1.__proto__, which points to Person.prototype, where the method is defined.

The relationship can be expressed as:

p1.__proto__ === Person.prototype; // true
Person.prototype.constructor === Person; // true

In summary:

• prototype is a property of functions/classes that serves as a blueprint for instances

• __proto__ is a property of object instances that points to the prototype they inherit from

How Prototypes Work with Functions

Let's see a complete example with functions:

function Person(name, age) {
  this.name = name;
  this.age = age;
}

// Adding a method to the prototype
Person.prototype.introduce = function() {
  console.log(`Hi, I'm ${this.name} and I'm ${this.age} years old.`);
};

// Creating instances
const person1 = new Person("Alice", 25);
const person2 = new Person("Bob", 30);

person1.introduce(); // "Hi, I'm Alice and I'm 25 years old."
person2.introduce(); // "Hi, I'm Bob and I'm 30 years old."

// Both instances share the same prototype
console.log(person1.__proto__ === Person.prototype); // true
console.log(person2.__proto__ === Person.prototype); // true
console.log(person1.__proto__ === person2.__proto__); // true

The key benefit here is memory efficiency: the introduce method exists only once in Person.prototype, but all instances can access it through the prototype chain.

How Prototypes Work with Classes

ES6 introduced the class syntax, which looks different but works the same way under the hood:

class User {
  constructor(name) {
    this.name = name;
  }

  sayHi() {
    console.log(`Hi, I'm ${this.name}`);
  }
}

const user1 = new User("Charlie");
user1.sayHi(); // "Hi, I'm Charlie"

// Let's check what's really happening
console.log(typeof User); // "function"
console.log(User.prototype); // { sayHi: f, constructor: f User() }
console.log(user1.__proto__ === User.prototype); // true

Classes are essentially syntactic sugar over JavaScript's prototype-based inheritance. Internally:

• A class is still a constructor function

• Methods defined in the class are added to ClassName.prototype

• Instances created with new have their __proto__ set to the class's prototype

This means everything we learned about function prototypes applies to classes as well.

Conclusion

Understanding prototypes and the prototype chain is fundamental to mastering JavaScript. These concepts form the foundation of how JavaScript implements inheritance and object-oriented programming.

Key Takeaways

Let's recap what we've learned:

1. Every object has __proto__: This property points to the prototype the object inherits from, enabling the prototype chain lookup mechanism.

2. Functions and classes have prototype: This property serves as a blueprint for instances created with the new keyword.

3. The prototype chain enables inheritance: When JavaScript can't find a property on an object, it walks up the prototype chain until it finds the property or reaches null.

4. Primitives use wrapper objects: Even though primitives aren't objects, JavaScript temporarily wraps them in objects to provide access to methods.

5. Classes are syntactic sugar: The modern class syntax is cleaner, but it still uses prototypes under the hood.

JavaScript might seem quirky at first, but once you understand how it works under the hood, you'll appreciate its elegant and flexible design.

Happy coding!