12/01/2026
Episode 2: Var, Let, and Const — The Memory & Scope
Back in the day, we only had “var”. It was like a wild horse; useful, but it ran wherever it wanted, and sometimes it showed up in places you definitely didn't invite it to.
Picture this: you declare a variable inside a for-loop, and somehow it's still hanging around outside the loop, messing with your code like an uninvited guest at a party. That's “var” for you.
In modern JavaScript, we've moved to a more disciplined approach with "let" and "const". ✅
👉🏼The difference between them comes down
to these three concepts:
🔶1. Scope (where the variable is visible).
🔶2. Hoisting (how JavaScript treats them before they're declared).
🔶3. Reassignment (whether you can change your mind later).
👉🏼The Scope Problem:
The problem that “var” created is that it is "function-scoped," meaning if you create it inside a function, the whole function sees it.
Sounds reasonable, right? Except when you put it inside an if statement or a for-loop, then it leaks out of those blocks like water through a cracked bucket. (See Image: // 1)
On the other hand, "let" and "const" are "block-scoped". They live strictly within their curly braces {} (where they were born).
This prevents those annoying bugs where you accidentally change a variable you didn't mean to touch.
👉🏼Hoisting:
JavaScript by default hoists (lifts) all "var" declarations to the top of their function, but not their values.
With "let" and "const", JavaScript still hoists them, but puts them in the TDZ (Temporal Dead Zone) – a fancy way of saying "don't touch this until I've actually declared it."
If you try to access them early, you'll get a clear error. (See Image: // 2)
👉🏼When To Use let vs const?
Use "const" by default. It tells the JavaScript engine (and your fellow developers), "This value is staying put."✅
When I see "const" in a code, I know I don't need to track that variable's journey through the file because it's locked in.
I use "let" only when I'm absolutely sure the value must change, like incrementing a value for instance. (See image: //4)
Also, know that "const" doesn't mean immutable. If you have a "const" object or array, you can still change what's inside it. You just can't reassign the variable to something completely different.
Think of it like a house: "const" means you can't move to a new address, but you're more than welcome to paint the front door, rearrange the furniture, or even add some new rooms. The address stays the same but the contents can change. (See image: //3)
👉🏼Why does this matter in real code?
If you ever had a variable mysteriously change halfway through your code, and you had no idea where it happened? That's probably "var" leaking out of a block and getting reassigned somewhere you didn't expect.
With "let" and "const", if you see an error, you know exactly where the variable lives and what's allowed to touch it.
Using "const" by default makes your code predictable, and predictable code is a senior-level code. It's easier to debug, easier to read, and it saves you from the scope confusion that "var" used to cause.
✅My golden rule? Use "const" until you realize you literally can't, then use "let". And "var"? Avoid it completely in new code – it's basically a museum piece at this point.
You might still see it in legacy codebase, but there's no reason to write it yourself in 2026.
Drop an emoji in the comments if this finally cleared up the var/let/const confusion for you.
In the next episode, we're diving into Data Types, and trust me, there's more drama there than you'd expect!
Umar Tambari
12/01/2026
