DEV Community: Ananya Mohanta

Undefined vs Not Defined

Ananya Mohanta — Tue, 24 Feb 2026 15:30:00 +0000

This is one of the most underrated JavaScript concepts.
When I was learning JavaScript, I used to treat errors as noise.
Red text → fix somehow → move on.

But one error kept showing up again and again:

They sound very similar, but they are not.

Understanding this one distinction completely changed how I think about JavaScript execution and memory.

What undefined actually means

undefined is a special keyword in JavaScript.
When a variable is created in a JavaScript program, before the code execution a memory is allocated for that variable with undefined.
It literally means:

“JavaScript knows this variable exists, but no value has been assigned yet.”

Example :

Output :

Why?

Because during the creation phase of execution context, JavaScript does this:

Sees var x

Allocates memory for x

Assigns a default value → undefined So when the code runs, x already exists in memory. That’s why undefined is logged in console.

undefined is not empty. It has its own memory space. It's a placeholder which is kept for the time being until the variable is assigned some other value.

Why not defined throws an error

Not defined is something which is not allocated in memory space.
For Example :

Here before the code execution, there is no memory allocated to y. So it throws an error as shown below :

This error doesn’t mean “value missing”. It means something much stronger:

“JavaScript has no idea what y is.”

During the creation phase, JavaScript is searching for declarations(var, functions) and allocates memory only for what it finds. Since y was never declared, JS never created space for it.
So when in code execution, JavaScript tries to access it → It throws error upfront.

The key difference

undefined → memory exists, value doesn’t

not defined → memory itself doesn’t exist

This is not a runtime guess. It’s decided before execution even starts.

How JavaScript decides this internally

Let’s slow this down. Consider this code:

What happens internally?

In the creation phase, JavaScript stores the value of x as undefined ** in the memory. **y is ignored because it’s not declared anywhere.

In the execution phase, since x exists in memory so instead of throwing error it prints undefined. y does not exist in memory so JavaScript throws error.

Why JavaScript behaves this way

JavaScript is not a line-by-line interpreter.
It works in two phases:

Memory allocation

Execution

Errors like not defined are not about timing. They are about whether memory was ever allocated.

This exact concept becomes stricter with let and const. They do get memory, but JavaScript intentionally blocks access until initialization.

Warning

Never do this :

Why?
undefined is a placeholder which is kept inside the variable and it states that the variable is not assigned anything throughout the code. It meant for a specific purpose.

undefined and not defined are not small differences. They reveal how JavaScript thinks before it runs code.

Two similar words. Two completely different memory states.

That’s JavaScript.

If you liked this post, I’d love to hear your thoughts. Share your feedback in the comments and connect with me on LinkedIn.

Hoisting in let and const : Understanding the Temporal Dead Zone

Ananya Mohanta — Tue, 17 Feb 2026 15:35:00 +0000

When I moved from var to let & const, I honestly thought I had finally understood JavaScript. Until this happened :

Boom. Reference error.

My first reaction was confusion. How did this just happen?

At that moment, Temporal Dead Zone felt like magic - something I was supposed to accept, not understand.
But once again, the answer wasn't in memorizing rules. It was hidden in the same place where hoisting, scope, and closure made sense earlier.

Execution Context.

let and const are Hoisted

One of the biggest misconceptions is:

“let and const are not hoisted.”
That’s not true.

If they were not hoisted, JavaScript would behave like this:

The error we would have gotten here:

But instead, we get here:

The error message itself is a hint.
JavaScript knows that "x" exists. It just refuses to let us touch it.
So, the real question become:

Why does JavaScript block access if the variable already exists?

What actually happens before code runs?

Before even a single line of code executes, JavaScript prepares everything behind the scenes.
It decides:

What variables exist.
Where they belong.
how memory should be set up. Now here is the difference in var and let. Before the code execution, y is assigned a value "undefined" in memory. So when it runs it does not crash. That's why we can access y even before declaring it. But, for x, if I do the same as above, then it throws a reference error. Because behind the scene:

x -> uninitialised

This is not undefined.
In the case of var, it is in the global scope but in case of let and const it is in script scope.

Even before a single line code execution, let and const are allocated memory but they are stored in a different memory space than global. They are not on the global object.

This memory space can't be accessed before putting some value in them. This is called Hoisting for let & const. And that's where Temporal Dead Zone begins.

Temporal Dead Zone(TDZ) :

Temporal dead zone is the time since when this let variable is hoisted and until it is initialized with some value. The time between that is called Temporal Dead Zone.

So, the phase from hoisting until it is assigned some value is known as Temporal Dead Zone. So, whenever I try to access x variable in the temporal dead zone, it gives reference error.
Example:

From the start of the scope until

count lives in Temporal dead zone. It exists, but accessing it is not allowed.
The moment this line executes:

The Temporal Dead zone ends. From there on, everything works finally.
This works perfectly.

Why accessing before initializing falis

This is the part that clicked me.
JavaScript does not fail because it's confused. It fails on purpose. If JavaScript allows this:

Then let could quickly behave like var. That would bring back:

accidental bugs
unpredictable behavior
hard-to-trace issues in large codebases So instead of returning undefined, JavaScript throws an error early and loudly. It’s saying:

“You’re using something before you’ve clearly defined it.”

And that’s a good thing.

Why TDZ exists at all

TDZ exists to enforce discipline in code order.
Consider this:

Logically, this makes no sense.
TDZ ensures:

code reads top-to-bottom the way humans expect
dependencies are declared before usage
mistakes don’t silently pass

TDZ is not a limitation. It’s a guardrail.

const and TDZ

const behaves the same as let in terms of TDZ, but with one extra rule.

This fails:

Why?
Because const demands initialization at declaration.
TDZ ensures:

constants are never half-defined
immutability is respected from the first moment

This one line removed all confusion:

Hoisting decides existence.
Initialization decides accessibility.

var → exists + initialized → usable
let / const → exists + uninitialized → TDZ

Once I saw it this way, Temporal Dead Zone stopped being magical. It became inevitable.
If Execution Context was the foundation, Temporal Dead Zone is the proof that JavaScript actually cares about correctness.

If you liked this post, I’d love to hear your thoughts. Share your feedback in the comments and connect with me onLinkedIn.

Hoisting in JavaScript

Ananya Mohanta — Tue, 10 Feb 2026 15:30:00 +0000

Why JavaScript Doesn’t Execute Code Top-to-Bottom ?
When I started learning JavaScript, hoisting felt like a bug pretending to be a feature.

Why didn’t this throw an error?
Why does let behave differently? (We'll study this later in another blog)
And why do functions work even before they’re defined?

The answer to all of this lives in Execution Context.

Once I understood how JavaScript prepares code before running it, hoisting stopped being confusing and started making sense.

Let's break it down.
Hoisting happens in the creation phase, not during the execution.

What is Hoisting?

Hoisting is JavaScript’s behavior of moving declarations to the top of their scope during the creation phase.

Not physically moving code — but allocating memory before execution starts.
Let's understand hoisting for var and functions with an example:

At first glance, this code looks wrong.

We are calling printMessage() before defining it.
We are logging x before assigning it.
We are even logging the function itself. Yet… this code works.

Why and How?

Now let's start with var.

What You Expect

Error, because x is declared later.

What Actually Happens

JavaScript stores the variable with a special keyword undefined.

Why?

During the creation phase, JavaScript does this:

Then during execution:

Key Rules for var

var is hoisted
Memory is allocated
Initialized with undefined
Scoped to function, not block

This is why var feels “weird” — but it’s actually consistent once you understand execution context.

Why Functions Are Fully Hoisted

This is where things get interesting.
During the creation phase:

JavaScript allocates memory
Stores the entire function definition So in memory:

JavaScript already knows what printMessage() is before execution begins. This is why function declarations are fully hoisted.

Now JavaScript starts executing the code from top to bottom.

Line 1

JavaScript finds the full printMessage() function in memory.
Output:

Line 2

JavaScript looks for x in memory.

x exists
Its value is undefined Output: > Important > This is not an error because x was already created during the creation phase.

Line 3

Since printMessage points to the entire function, JavaScript prints the function itself.
Output:

Line 5

Now, during execution, x gets its actual value.
Memory update:

x → 10
Final Output

Now hoisting works little different for function expression.

TypeError: printMessage is not a function

Why?
Because only the variable is hoisted, not the function.
Creation phase:

This is why it throws an error.

For arrow functions it works in the same way how function expression behaves.
Finally, Hoisting is not magic.
It’s a side effect of how JavaScript creates execution contexts.
Once you understand:

Creation phase
Memory allocation
TDZ
Scope rules

Hoisting becomes predictable, logical, and honestly… kind of elegant.

If You like my content and want to connect with me, connect me on LinkedIn.

JavaScript Execution Context and Call Stack Explained

Ananya Mohanta — Sat, 07 Feb 2026 13:55:48 +0000

Why Execution Context is important in JavaScript ?

When I first learnt JavaScript, I tried to memorize syntax but struggled to understand why the code behaved the way it did.

What are all these jargons like : Hoisting, Scope, Closure, async behavior ?

All became easy once I understood Execution Context & Call stack.

So, this is where my JavaScript learning journey begins, and from today onwards, I will be sharing my learning so that it can be easy for you all to learn these concepts.

Let’s start with the very first question.

What is Execution Context?

An Execution context is the environment where JavaScript code is evaluated and executed.

What does it mean by this line? Let me explain.

Think of it as a big container created by JS to run your code. Everything in JS runs inside an execution context. Every time JS runs code, it creates an execution context.

What is inside an execution context?

The execution context is created in two phases.

Memory Creation Phase
Code Execution Phase

Phase 1 - Memory Creation Phase :

Before executing the code, JS stores variables and functions in the memory.

During this phase :

In the memory component everything is stored in key-value pairs.
Variables are stored with a special keyword “undefined“ (I will talk about it in another blog).
Functions are stored as it is.

Phase 2 - Code Execution Phase :

In this phase :

Code will be executed one line at a time.
Variable values are updated with the values written in the code.
Functions are invoked/executed in this phase.
Function calls are pushed onto the Call Stack.

This is also known as Thread of Execution. This is why JavaScript is called Synchronous Single Threaded language.

What does it mean by Synchronous Single Threaded ?

It means the code will execute one line at a time in a particular order that is, after finishing the execution of one line, the next line will executes.

Types of Execution Context

Global Execution Context :

It is created when JS file first runs.
Only one global context exists.

Function Execution Context :

It is created every time a function is called.
Can be as many as functions are invoked in the code.
When a function is created, a new execution context is created.

Example to Visualize Execution Context

Let’s understand the flow of execution context with an example

In the memory creation phase, variable n will be stored with undefined. and function will be stored as it is and everything is stored in key-value pairs. We can see this in developer console.

In code execution phase a global execution is created and variables will assigned with its value written in the code. The code will execute one line by line at a time in a particular order.

So, n is assigned with value 5.

Now when the 6th line is executed, the multiplyByTwo() function is invoked with an argument n and a new execution context is created and pushed into the Call Stack.

This is known as Function Execution Context. Once the code execution is completed and the value is assigned into output1, the execution context is popped from the call stack.

Similarly for output2, the same process happens.

What Is the Call Stack?

The Call Stack is a data structure that keeps track of execution contexts. It follows LIFO - Last In, First Out principle.

JavaScript has it own call stack. Call stack maintains the order of the execution of execution context. It is also known as Execution Context Stack / Program Stack / Central Stack / Runtime Stack / Machine Stack.

How Call Stack Works

The order of the call stack is as below :

Global - First, the code executes and global execution context is created.
first() - After this, first() function is invoked and and execution context pushed onto call stack.
second() - Then second function is invoked inside first() and and execution context pushed onto call stack.
third()- Then third function is invoked inside second() and and execution context pushed onto call stack.

Once the third() finishes, it popped from call stack. Then second() and first() finish execution and popped from the call stack as well.

Importance

Understanding execution context helps you:

Predict hoisting behavior
Debug scope issues
Understand closures
Avoid call stack overflow
Write better async code

Finally, Execution Context & Call Stack are the foundation of JavaScript. Once you understand this:

Closures feel logical
Async behavior makes sense
Debugging becomes easier.

If You like my content and want to connect with me, follow me on LinkedIn(https://www.linkedin.com/in/amohanta).