JavaScript Variables: let, const and var Explained

A variable is a labelled box you put a value in so you can use it by name later. JavaScript gives you three ways to make one (let, const, and var), and the short version is: use const by default, reach for let when the value needs to change, and pretend var doesn't exist. The rest of this lesson is why, because the reasons are what stop you writing bugs.

Your first variable

Here's the whole idea in three lines. Run it and watch the console.

let score = 0 does two things: it declares a variable named score and gives it an initial value of 0. The next line, score = 10, reassigns it (same box, new value). Then console.log(score) prints what's in the box right now, which is 10. No let on the second line, because the variable already exists. You only declare it once.

That word "reassigns" is the hinge the rest of this lesson turns on. Some values change over the life of your program. Plenty don't. JavaScript lets you say which is which, and saying so out loud catches mistakes.

const: the default you reach for first

const declares a variable you don't intend to reassign. Try to change it and the program stops with an error instead of quietly doing the wrong thing.

Uncomment that last line and you get TypeError: Assignment to constant variable. That's a feature. If a value is meant to stay put (a tax rate, a config setting, an element you grabbed once), const makes "I changed it by accident" impossible. The error shows up the instant you break the rule, not three functions later when the number is mysteriously wrong.

So the habit worth building from day one: declare everything with const until you have a concrete reason it must change. Most variables in real code never get reassigned, and it's calmer to read code where const tells you "this won't move."

One thing that trips people up: const stops you from reassigning the variable, not from changing what's inside an object or array it points to.

const user means user will always point at that one object. Editing a field inside it is allowed. Pointing user at a brand-new object (user = {}) is not. Same with arrays: push mutates the array you already have, so const is happy. The MDN reference on const spells this out: it's the binding that's constant, not the value.

let: for values that genuinely change

When a variable really does need to take on different values over time (a loop counter, a running total, a score), that's what let is for.

total starts at 0 and grows on every pass through the loop, so it has to be let. The loop counter i is also let because it counts up each time. But prices never gets reassigned (we only read from it), so it's const. That mix is exactly what good JavaScript looks like: const for the things that hold still, let for the few that move.

Block scope: where a variable lives

A variable declared with let or const only exists inside the { } block it's declared in, whether an if, a loop, or a function body. Step outside the braces and it's gone. That boundary is called block scope, and it's why these two keywords are easy to reason about.

message is born inside the if block and dies at its closing brace. The second console.log is outside, so JavaScript has never heard of message there. This keeps variables from leaking into the rest of your program and stepping on each other. A total inside one block can't collide with a total somewhere else.

Why var is legacy

var is the original keyword, from JavaScript's 1995 design. It still works, but it has two behaviours that cause real bugs, and let/const (added in ES2015) exist specifically to fix them.

Problem one: var ignores block scope. It's scoped to the whole enclosing function, not the block. So a var declared inside an if leaks out:

With const or let, that last line throws a ReferenceError, which is what you want, because referencing a thing outside its block is almost always a mistake. var happily hands it to you, and that's how stale values sneak across a function.

Problem two: hoisting. var declarations are silently "hoisted" to the top of their function, so you can reference a var before you write it, and instead of an error, you get undefined:

A variable that exists-but-is-undefined before its own declaration line is a great way to ship a bug that doesn't crash, it just misbehaves. let and const close this off: use one before its declaration and you get a clean ReferenceError telling you exactly where you went wrong.

That's the case against var in one breath: it leaks out of blocks and it lets you use variables before they're defined. You'll still see var in old code and tutorials, so it's worth recognising, but in anything you write today, const and let cover every case, more safely. MDN flags var as the legacy option for the same reasons in its variable basics guide.

Naming variables well

The keyword is half the decision. The name is the other half. A few conventions that the whole JavaScript world follows:

• camelCase for variable names: firstName, totalPrice, isLoggedIn. Lowercase first word, capital on each word after.
• Names say what's inside. userCount beats n, and isReady beats flag. Booleans usually read like a yes/no question, such as isActive or hasPermission.
• Start with a letter, $, or _, never a digit. total2 is fine, but 2total is a syntax error.
• Case matters. score and Score are two different variables. Pick one style and stick to it.
• Reserved words are off limits. You can't name a variable let, const, return, class, and so on.

Good names are the cheapest documentation you'll ever write. Six months from now, const remainingAttempts = 3 tells you everything, while const x = 3 tells you nothing.

Recap and what's next

Three keywords, one simple rule: reach for const first, switch to let only when a value genuinely needs to be reassigned, and leave var in the past, because its function scoping and hoisting cause bugs that block-scoped const/let simply don't. Both let and const live inside the { } block where you declare them, which keeps your variables tidy and your bugs local. Name things in camelCase, and name them after what they hold.

If you're wondering how JavaScript got here and why it's worth learning at all, back up to Why Learn JavaScript. Coming from the other side of programming? The same ideas in Python live in Python functions and logic building. Next up: what kinds of values you can actually put in these boxes (numbers, strings, booleans and friends) in JavaScript data types.