
JavaScript has three variable declaration keywords: `var`, `let`, and `const`. They differ in scope, hoisting, and reassignability. Modern code uses `const` and `let` exclusively.

<ExamplePair>
<ExampleProse>

`const` declares a block-scoped binding that cannot be reassigned. It is the right choice for most declarations - it signals that the value won't change, which makes code easier to reason about.

</ExampleProse>
<ExampleCode>

```js
const name = "Ada";
name = "Grace"; // TypeError: Assignment to constant variable.
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`let` is block-scoped and allows reassignment. Use it only when a variable genuinely needs to change - a loop counter, an accumulator, a flag that flips once.

</ExampleProse>
<ExampleCode>

```js
let count = 0;
count = count + 1;
console.log(count); // 1

for (let i = 0; i < 3; i++) {
  console.log(i); // 0, 1, 2
}
// i is not accessible here
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`var` is function-scoped and hoisted to the top of its function. A `var` declared inside an `if` block leaks into the surrounding function - a frequent source of bugs in older code.

</ExampleProse>
<ExampleCode>

```js
function demo() {
  if (true) {
    var x = 1; // hoisted to function scope
  }
  console.log(x); // 1 - leaks out of the if block

  let y = 2;
  // y stays block-scoped - won't leak
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
The modern convention is `const` by default, `let` only when reassignment is genuinely required, and `var` never. ESLint's `prefer-const` and `no-var` rules enforce this automatically. Teams that skip these rules accumulate subtle bugs in async code: a `var` in a loop body captured by a closure resolves to the final loop value, not the value at the iteration where the closure was created - a class of bug that `let` eliminates entirely.
</InProduction>


Three ways to declare variables in JavaScript - var, let, and const - each with different scoping and hoisting rules.

Variables


`const` locks a variable's _binding_ - you cannot reassign the name. It does not make the value immutable.

<ExamplePair>
<ExampleProse>

Attempting to reassign a `const` binding throws a `TypeError` at runtime and is caught at parse time by TypeScript and most linters.

</ExampleProse>
<ExampleCode>

```js
const x = 1;
x = 2; // TypeError: Assignment to constant variable.
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

An object bound by `const` is still mutable. Its properties can be changed freely because the binding (the pointer) is fixed, not the data it points to.

</ExampleProse>
<ExampleCode>

```js
const config = { retries: 3 };
config.retries = 5; // fine - mutating the object, not the binding
console.log(config.retries); // 5
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`Object.freeze` prevents property mutation. Writes fail silently in sloppy mode and throw a `TypeError` in strict mode. Note that `freeze` is shallow - nested objects remain mutable.

</ExampleProse>
<ExampleCode>

```js
"use strict";

const settings = Object.freeze({ timeout: 5000 });
settings.timeout = 1000; // TypeError: Cannot assign to read only property
```

</ExampleCode>
</ExamplePair>

<InProduction>
Teams that read `const` as "immutable" and treat a shared config object as safe to pass around are in for a surprise when two call sites mutate it concurrently. Deep immutability is a library concern - [Immer](https://immerjs.github.io/immer/) for update workflows, `structuredClone` for a quick deep copy - or a TypeScript type concern (`as const`, `Readonly<T>`). The language keyword alone doesn't buy it.
</InProduction>


const locks the binding, not the value - objects and arrays declared with const are still mutable.

Constants


JavaScript has eight value types: seven primitives (`string`, `number`, `bigint`, `boolean`, `undefined`, `symbol`, and `null`) and `object`. The `typeof` operator reveals a value's type - with one infamous exception.

<ExamplePair>
<ExampleProse>

Numbers, strings, and booleans are the most common primitives. `typeof` returns their type as a lowercase string.

</ExampleProse>
<ExampleCode>

```js
typeof 42;         // "number"
typeof "hello";    // "string"
typeof true;       // "boolean"
typeof undefined;  // "undefined"
typeof Symbol();   // "symbol"
typeof 9007199254740993n; // "bigint"
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`null` is technically a primitive, but `typeof null` returns `"object"` - a legacy bug in the language that [can never be fixed without breaking existing code](https://www.wirfs-brock.com/allen/jshopl.pdf). Check for null explicitly.

</ExampleProse>
<ExampleCode>

```js
typeof null;        // "object" - legacy quirk, not a real object
null === null;      // true  - use this instead
null !== undefined; // true  - null and undefined are distinct
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Always use strict equality (`===`) for comparisons. The loose equality operator (`==`) coerces types before comparing, producing results that are rarely what you want.

</ExampleProse>
<ExampleCode>

```js
0 == false;         // true  (type coercion)
0 === false;        // false (strict - different types)

"" == false;        // true  (coercion)
"" === false;       // false

null == undefined;  // true  (special case)
null === undefined; // false
```

</ExampleCode>
</ExamplePair>

<InProduction>
The `typeof null === "object"` quirk bites null checks written as `if (typeof x === "object")` - that check passes for `null`. Always combine it with an explicit `x !== null` guard, or just check `x === null` directly. Prefer strict equality (`===`) everywhere; the loose `==` operator has over a dozen coercion rules that produce surprises in feature-flag defaults, counter comparisons, and conditional rendering.
</InProduction>


JavaScript has seven primitive types plus the object type - and one infamous typeof quirk.