Why let vs var JavaScript Still Trips Up Experienced Developers

You're debugging a loop. Everything looks fine. The logic is sound, the syntax is clean, yet your console keeps spitting out the same value—the last one in the array—over and over again. Honestly, it’s a rite of passage. If you've been around the block, you know exactly what happened. You used var.

The let vs var JavaScript debate isn't just some academic exercise for people who like arguing about specifications. It's about how memory works. It’s about why your code behaves like a ghost in the machine when you least expect it.

Back in the day, before ES6 dropped in 2015, var was the only game in town. We didn't have a choice. We just dealt with its quirks, like "hoisting" and its weird refusal to respect block scopes. Then Brendan Eich and the TC39 committee gave us let and const. Suddenly, JavaScript started acting like a "normal" language. But even now, in 2026, I still see legacy codebases—and some fresh ones—mixing these up in ways that cause massive headaches.

💡 You might also like: Google Data and Privacy Settings: What Most People Get Wrong

The Scope Scandal: Why var is a Loose Cannon

Think of scope as the "neighborhood" where your variable lives. Before ES6, JavaScript only had two types of neighborhoods: Global and Function.

When you declare something with var, it doesn't care about your if statements. It doesn't care about your for loops. If it's inside a function, it belongs to the whole function. If it’s outside, it belongs to everyone. This is "function scoping."

Look at this:

if (true) {
  var user = "Alice";
}
console.log(user); // Alice

Try that in Java, C#, or basically any other C-style language. It would blow up. But JavaScript? It just shrugs. var leaks. It climbs out of the curly braces like a vine growing over a fence.

Now, compare that to let.

if (true) {
  let guest = "Bob";
}
console.log(guest); // ReferenceError: guest is not defined

let is polite. It stays where you put it. This is "block scoping." It’s predictable. When you use let inside a loop or an if block, it dies the moment that block finishes. This prevents the "variable pollution" that makes large-scale applications a nightmare to maintain.

Hoisting is the Weirdest Part of JavaScript

Hoisting. It sounds like something you do to a flag. In JavaScript, it’s the engine’s habit of moving declarations to the top of their scope before the code actually runs.

But here is the kicker: var and let both hoist, but they do it differently.

When you use var, the declaration is hoisted and initialized as undefined. You can actually use the variable before you even write the line that defines it. It won’t crash; it’ll just be "empty."

console.log(pizzas); // undefined
var pizzas = 10;

With let, the variable is hoisted, but it isn't initialized. It enters what developers call the Temporal Dead Zone (TDZ). If you try to touch it before the declaration line, the engine throws a fit.

console.log(burgers); // ReferenceError! 
let burgers = 5;

It’s a safety net. The TDZ exists because accessing uninitialized variables is almost always a mistake. It’s the language telling you, "Hey, stop being messy."

The For-Loop Trap That Every Junior Hits

This is the classic interview question. It’s also a real-world bug that has cost companies thousands in man-hours.

Imagine you want to print numbers 1 through 3, but with a slight delay.

for (var i = 1; i <= 3; i++) {
  setTimeout(() => {
    console.log(i);
  }, 100);
}

You'd expect 1, 2, 3. Instead, you get 4, 4, 4.

Why? Because var doesn’t have block scope. There is only one i variable for the whole loop. By the time the setTimeout actually runs (100ms later), the loop has already finished, and i has been incremented to 4. All three functions are pointing to the exact same memory address.

Switch that var to let and the problem vanishes.

Why? Because let creates a new binding for every single iteration of the loop. Each pass gets its own little "snapshot" of i. It’s cleaner. It’s intuitive. It’s why you should basically never use var in a loop again.

Global Objects and Window Pollution

In a browser environment, var has another annoying habit. If you declare a var at the top level of a script, it attaches itself to the window object.

var secretValue = "12345";
console.log(window.secretValue); // "12345"

This is bad. It’s really bad. You’re essentially cluttering the global namespace, which can lead to name collisions with other scripts or libraries you’ve loaded. If two scripts both use var status, they’re going to overwrite each other.

let, however, does not do this. Even if declared at the top level, it stays out of the window object. It’s global in the sense that your script can see it, but it’s not leaking into the environment’s global state.

When Should You Actually Use var?

Honestly? Almost never.

I’ve heard people argue that var is useful when you want a variable to be available throughout a whole function regardless of blocks. But that’s usually just a sign of poor function design. If a function is so long and complex that you need a variable to leak out of an if statement, your function is probably doing too much. Refactor it.

Some developers use var in legacy environments where they can't use a compiler like Babel. But it’s 2026. Even the "old" browsers handle ES6 now. If you’re writing modern JavaScript, let and const should be your defaults.

In fact, the modern "Best Practice" hierarchy is:

1. Use const by default. If the value doesn't need to change, don't let it.
2. Use let if you know you need to reassign the value (like in a counter).
3. Use var only if you are maintaining code written in 2014 or if you’re trying to win a "weirdest code" contest.

Redeclaration: The Silent Bug Creator

Another weird quirk: var lets you redeclare the same variable in the same scope.

var price = 10;
var price = 20; // No error.

If you accidentally do this in a 500-line file, you’ve just overwritten your data without any warning from the system. let won’t allow it. It will scream "Identifier 'price' has already been declared" the second you try. That's the kind of annoyance you actually want from a programming language. It's the language having your back.

The Real-World Performance Myth

You might hear some "performance gurus" claim that var is faster because let requires more book-keeping by the engine to track block scopes.

Technically, in some hyper-specific micro-benchmarks, there might be a nanosecond difference. But in a real application? The bottleneck is your DOM manipulation, your API calls, or your unoptimized images. Using var for "speed" is like taking the passenger seat out of your car to save weight while you're stuck in a 10-mile traffic jam. It doesn't matter. Code readability and bug prevention win every time.

Moving Forward With Modern JavaScript

The transition from var to let was about more than just adding a new keyword. It was about making JavaScript a more mature, robust language. By enforcing block scope and preventing accidental global pollution, let helps you write code that is easier to reason about.

When you look at let vs var JavaScript issues, you're really looking at the history of the web. var represents the "Wild West" era of JS—flexible but dangerous. let represents the modern era—structured and safe.

Actionable Steps for Your Codebase

Check your current projects. If you’re still seeing var in the wild, here is how you handle it:

• Audit your loops: Immediately replace var with let in for loops to avoid closure-related bugs.
• Default to const: Try changing every var to const. If the console throws an error because you’re reassigning it, then change only those to let.
• Clean the Global Scope: If you have top-level variables, make sure they aren't accidentally attaching to the window object by using let.
• Use Linters: Set up ESLint with the no-var rule. It will highlight every instance of var in your editor so you can kill them off one by one.
• Understand Hoisting: Don't rely on it. Regardless of whether you use var or let, always declare your variables at the top of their respective scopes. It makes the code much more readable for the next person (who might be you in six months).

JavaScript is quirky. It’s weird. It’s beautiful. But it’s also a lot easier to manage when you use the right tools. Stick to let and const, and leave var in the history books where it belongs.