Var, Let, and Const: Scoping, Hoisting, and TDZ

Hoisting: More Than Just "Moving to the Top"

You may have heard hoisting described as "JavaScript moving variable declarations to the top of the scope." While a useful mental shortcut, it's not what actually happens. Hoisting is a direct consequence of how the JavaScript engine's execution context works.

Recall that an execution context is created in two phases:

1. Creation Phase: The engine scans the code, allocates memory for variables and functions, but does not execute any code.
2. Execution Phase: The engine executes the code line by line.

The difference between var, let, and const begins in the creation phase.

As the video demonstrates, all three declaration types are "hoisted" in the sense that the engine is aware of them and allocates memory for them during the creation phase. The critical difference is their initial state:

• var: Hoisted and initialized with the value undefined.
• let & const: Hoisted but remain uninitialized.

This "uninitialized" state is the key to understanding our next concept.

The Temporal Dead Zone (TDZ)

The fact that let and const variables are hoisted but uninitialized creates a state known as the Temporal Dead Zone (TDZ).

The TDZ is the period of time from the beginning of a variable's enclosing scope until the point where its declaration is processed during execution. If you try to access a let or const variable within its TDZ, you will get a ReferenceError.

Now, let's connect this behavior directly to the mechanics of the execution context to understand why this happens.

The TDZ isn't a bug; it's a feature designed to help you write better code. It prevents you from accidentally using a variable before it has been properly declared and initialized, a common source of bugs with var.

This image provides a great visual model for this concept.

Scope: Function vs. Block

The second major difference is their scope—the region of code where they are accessible.

• var is function-scoped: It is accessible anywhere within the function it's declared in, regardless of blocks ({...}). If declared outside any function, it has global scope.
• let and const are block-scoped: They are only accessible within the block ({...}) in which they are defined. This includes if statements, for loops, or even just a standalone pair of curly braces.

This difference has profound implications. Consider the classic for loop problem with setTimeout:

// Using var
for (var i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i); // What will this log?
  }, 100);
}

Because var is function-scoped, there is only one i variable that is shared across all loop iterations. By the time the setTimeout callbacks execute (long after the loop has finished), the value of i is 3. The output will be 3, 3, 3.

Now, let's see the same code with let:

// Using let
for (let i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i); // And what about this?
  }, 100);
}

Because let is block-scoped, a new i variable is created for each iteration of the loop. Each setTimeout callback captures a different i with the value it had during that specific iteration. The output is, as you'd intuitively expect, 0, 1, 2. This behavior is almost always what is desired and is a primary reason to prefer let over var in loops.

Mutability and Re-declaration

The final differences relate to changing a variable's value and declaring it again.

• Re-assignment:

  • const: Cannot be re-assigned. Once a value is assigned, the variable name cannot be pointed to a new value.

    const a = 10;
    a = 20; // Throws TypeError: Assignment to constant variable.
    

    It's crucial to remember the concept of mutability from our earlier lesson. For objects and arrays declared with const, the variable cannot be reassigned, but the contents of the object or array can be changed.

    const user = { name: "Alex" };
    user.name = "Bob"; // This is perfectly fine.
    // user = { name: "Charlie" }; // This would throw a TypeError.
    

  • let: Can be re-assigned.
  • var: Can be re-assigned.

• Re-declaration:

  • var: Allows re-declaration within the same scope without error.

    var x = 1;
    var x = 2; // No error, x is now 2.
    

  • let and const: Do not allow re-declaration in the same scope. This prevents you from accidentally overwriting a variable and is another key safety feature.

    let y = 1;
    let y = 2; // Throws SyntaxError: Identifier 'y' has already been declared.
    

Summary and Best Practices

Here's a summary table of the key differences:

Given these differences, modern JavaScript development follows a clear set of best practices.

The community consensus is:

1. Prefer const by default. This makes your code more predictable by signaling that a variable's assignment should not change.
2. Use let only when you know a variable needs to be re-assigned, such as a loop counter or a value that changes based on application state.
3. Avoid var completely in modern (ES6+) codebases. The function-scoping and loose hoisting behavior are common sources of bugs that let and const were designed to solve.

Conclusion

You now have a deep, conceptual understanding of how var, let, and const operate within the JavaScript engine.

Key Takeaways:

• All three are "hoisted," but their initial states differ: var is initialized to undefined, while let and const remain uninitialized.
• The Temporal Dead Zone (TDZ) for let and const prevents access to them before their declaration, resulting in a ReferenceError and promoting safer code.
• var is function-scoped, while let and const are block-scoped, which has a significant impact on behavior in loops and conditional blocks.
• const enforces assignment immutability (the variable cannot be re-assigned), while let and var allow it.
• The modern best practice is to favor const, use let when necessary, and avoid var.

What's Next?

We've seen that the Execution Context is central to understanding hoisting. In our next lesson, we will formalize this concept completely. You will learn to describe how the JavaScript engine creates execution contexts and manages the scope chain during code execution. This will connect many of the dots we've discussed so far and lay the groundwork for understanding even more advanced concepts like closures.