Understanding JavaScript Scope and Closures: A Deep Dive into Lexical Environments

So you've been writing JavaScript for a while now, and you keep hearing about "closures" and "lexical scope." Maybe you've even used them without realizing it. Let's break down what's really happening under the hood when you create functions in JavaScript.

The Setup: How JavaScript Handles Variables

JavaScript is incredibly flexible when it comes to functions. You can create them anywhere, pass them around like hot potatoes, and call them from completely different parts of your code. But this flexibility raises some interesting questions:

• What happens when a function accesses variables from outside its own scope?
• If those outer variables change after the function is created, which values does the function see?
• When you pass a function somewhere else and call it, can it still access those outer variables?

Before we dig into the answers, a quick note: I'll be using let and const in my examples. They behave the same way for our purposes here, and they're what you should be using in modern JavaScript anyway.

Block Scope: The Basics

Variables declared with let or const inside curly braces {} are only visible within that block:

{
  let message = "Hello";
  alert(message); // Works fine
}
alert(message); // Error: message is not defined

This applies to if statements, loops, and any code block:

for (let i = 0; i < 3; i++) {
  alert(i); // 0, 1, 2
}
alert(i); // Error: no such variable

Pretty straightforward, right? Now let's get to the interesting stuff.

Nested Functions and the Plot Thickens

Here's where JavaScript starts to show its true colors. Check out this simple counter function:

function makeCounter() {
  let count = 0;

  return function() {
    return count++;
  };
}

let counter = makeCounter();
alert(counter()); // 0
alert(counter()); // 1
alert(counter()); // 2

Wait, what just happened? The count variable was declared inside makeCounter(), but the returned function can still access and modify it even after makeCounter() has finished executing. How is that possible?

Enter the Lexical Environment

Here's where we need to peek under the hood. Every function, code block, and script in JavaScript has something called a Lexical Environment. Think of it as an invisible object with two key parts:

1. Environment Record: Stores all local variables as properties
2. Outer Reference: Points to the outer lexical environment

When JavaScript needs to find a variable, it searches the current Lexical Environment first, then follows the chain of outer references until it either finds the variable or hits the global scope.

How Functions Remember Their Home

Here's the secret sauce: all functions remember where they were created. Every function has a hidden [[Environment]] property that keeps a reference to the Lexical Environment where it was born.

Going back to our counter example:

function makeCounter() {
  let count = 0;
  return function() {
    return count++;
  };
}

When the inner function is created, it gets a [[Environment]] reference pointing to the Lexical Environment of makeCounter(). That environment contains count: 0. Even after makeCounter() returns, that Lexical Environment stays alive because the inner function is still holding a reference to it.

Later, when you call counter(), it creates a new Lexical Environment for that specific call. But when the code inside needs the count variable, it doesn't find it locally, so it follows the outer reference (stored in [[Environment]]) and finds it in the makeCounter environment. That's where it reads and updates the value.

What Exactly is a Closure?

A closure is simply a function that remembers its outer variables and can access them.

In JavaScript, all functions are naturally closures (with one rare exception we won't get into here). They automatically remember where they were created using that hidden [[Environment]] property, allowing their code to access outer variables no matter where the function is eventually called.

So when someone asks you "what's a closure?" in an interview, you can confidently say: "It's a function that has access to variables from its outer scope, even after the outer function has returned. In JavaScript, all functions are closures because they maintain a reference to their lexical environment."

Function Declarations vs Expressions

One interesting quirk: Function Declarations are hoisted and immediately available:

sayHi("John"); // Works!

function sayHi(name) {
  alert("Hello, " + name);
}

But Function Expressions aren't:

sayHi("John"); // Error!

let sayHi = function(name) {
  alert("Hello, " + name);
};

This happens because when a Lexical Environment is created, Function Declarations become ready-to-use immediately, while let variables start in an "uninitialized" state until the code reaches their declaration.

Memory and Garbage Collection

You might wonder: "If functions keep references to their outer environments, doesn't that create memory leaks?"

Good question! Normally, a Lexical Environment gets cleaned up after a function finishes executing. But if there's a nested function that's still reachable, its [[Environment]] property keeps the outer Lexical Environment alive.

function f() {
  let value = 123;
  return function() {
    alert(value);
  }
}

let g = f(); // Lexical Environment with 'value' stays in memory
g = null; // Now it can be garbage collected

JavaScript engines are smart about this. If they can prove an outer variable is never used by a nested function, they'll optimize it away to save memory.

A Debugging Gotcha

Speaking of optimizations, here's something that might trip you up in Chrome DevTools. Try this:

function f() {
  let value = Math.random();

  function g() {
    debugger; // Pause here and try: alert(value)
  }

  return g;
}

let g = f();
g();

If you pause at the debugger statement and try to access value in the console, Chrome will tell you it doesn't exist! The V8 engine optimized it away because g() doesn't actually use it. This isn't a bug—it's an optimization. But it can be confusing when debugging.

Wrapping Up

Closures aren't magic—they're just functions doing what they naturally do in JavaScript. Every function remembers where it came from and maintains access to its parent scope. This makes powerful patterns possible:

• Private variables and methods
• Factory functions
• Callback functions that need context
• Event handlers with access to outer state

The key takeaway? When you create a function in JavaScript, it carries its environment with it wherever it goes. That's the beauty (and sometimes the complexity) of lexical scoping.

Now go forth and close over some variables with confidence!

---

Have you run into any interesting closure scenarios in your code? Drop a comment below—I'd love to hear about them!