Variables: let, const & the var of Old

Every program you'll ever write does one thing constantly: it remembers. A score, a username, a running total — programs hold onto values and give them names. Those names are variables, and JavaScript gives you two modern keywords to create them — plus one old one you'll meet in every codebase written before 2015. Getting the three straight now pays off for the rest of your JavaScript life.

Declaring with let and const

A variable is born with a declaration — a keyword, a name, and (usually) a first value:

let score = 0;
const playerName = "Ada";

Read = as "now refers to", not "equals": the name score now refers to the value 0. The difference between the keywords is one promise:

• let — this name may point at different values over time.
• const — this name is bound once, forever. Try to change it and the engine stops you.

The order of operations matters: the right side runs first. JavaScript evaluates whatever is right of =, gets a value, then binds the name on the left. That's why this line — nonsense as algebra — is perfectly ordinary code:

score = score + 10; // right side first: compute score + 10 → new value → rebind the name
console.log(score);

→ 10 — the old value went in on the right, the new value came out, and the name moved to it.

Declaration vs. assignment vs. reassignment

Three different moments in a variable's life, three different words:

let mood = "curious";   // DECLARATION — the name is born (with a first assignment)
console.log(mood);
 
mood = "confident";     // REASSIGNMENT — the name moves to a new value (no keyword!)
console.log(mood);

→ curious, then confident — the old value is simply forgotten.

Notice reassignment has no keyword — you only say let when the variable is born. Saying it twice (let mood again in the same scope) is an error: SyntaxError: Identifier 'mood' has already been declared.

And const keeps its promise. This produces TypeError: Assignment to constant variable.:

const gravity = 9.81;
gravity = 3.7; // trying to reassign a const

So which do you reach for? Professionals default to const and use let only when reassignment is genuinely needed. It's not about constants being common — it's about communication: a const tells every future reader "this name means one thing for its whole life; stop tracking it." Your code grows a little easier to read with every let you didn't need.

Try it — watch names move

Predict what each console.log shows before you run this. The last two lines are the ones that surprise people. Then keep going at the › prompt: try score — and try reassigning bonus.

Naming: rules and conventions

The rules (the engine enforces these):

• Names use letters, digits, _ and $ — but can't start with a digit.
• Names are case-sensitive: score, Score, and SCORE are three different variables.
• Reserved words (let, if, class, …) can't be names.

The conventions (the engine won't stop you — professionals will):

• Use camelCase: first word lowercase, each new word capitalized. totalPrice, not total_price or TotalPrice.
• Make names say what the value means: secondsRemaining, not s or data2.
• Truly-fixed configuration values are often written ALL_CAPS (const MAX_ATTEMPTS = 3;) — a convention that shouts "settings, not state."

Dynamic typing: values have types, variables don't

A JavaScript variable is just a label — it can point at any kind of value, and even switch kinds over its life:

let answer = 42;         // a number...
answer = "forty-two";    // ...now a string. JavaScript doesn't mind.
console.log(answer);

→ forty-two — the type lives with the value, not the name. This is called dynamic typing.

Just because you can doesn't mean you should — a name that means one kind of thing throughout its life is a kindness to readers. The full cast of types (numbers, strings, booleans, and stranger things) is exactly where we go next.