
`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


Every JavaScript number is a 64-bit IEEE 754 floating-point value. There is no separate integer type - which means integers above 2⁵³ lose precision, and decimal arithmetic has well-known rounding quirks.

<ExamplePair>
<ExampleProse>

The classic float trap: `0.1 + 0.2` does not equal `0.3`. Compare floating-point numbers using a tolerance instead of strict equality.

</ExampleProse>
<ExampleCode>

```js
console.log(0.1 + 0.2 === 0.3); // false
console.log(0.1 + 0.2); // 0.30000000000000004

// Safe float comparison
const a = 0.1 + 0.2;
const b = 0.3;
console.log(Math.abs(a - b) < Number.EPSILON); // true
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`Number.MAX_SAFE_INTEGER` is the largest integer that can be represented exactly. Beyond it, incrementing no longer works reliably.

</ExampleProse>
<ExampleCode>

```js
console.log(Number.MAX_SAFE_INTEGER); // 9007199254740991

const n = Number.MAX_SAFE_INTEGER;
console.log(n + 1 === n + 2); // true - precision lost
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`BigInt` handles arbitrarily large integers exactly. Use the `n` suffix for literals. BigInt and Number cannot be mixed in arithmetic - you must convert explicitly.

</ExampleProse>
<ExampleCode>

```js
const big = 9007199254740991n + 1n;
console.log(big); // 9007199254740992n

console.log(10n * 2n); // 20n
// console.log(10n + 1); // TypeError: Cannot mix BigInt and other types
```

</ExampleCode>
</ExamplePair>

<InProduction>
Never store monetary values as `Number`. Representing $19.99 as `19.99` and doing arithmetic on it will produce rounding errors that compound across transactions. Store money as integer cents (`1999`) or use a decimal library like [decimal.js](https://mikemcl.github.io/decimal.js/). Payment systems that let floats drift ship silent bugs that accounting finds months later.
</InProduction>


Every non-BigInt number in JavaScript is a 64-bit float - understanding the precision limits prevents hard-to-debug arithmetic bugs.

Numbers


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.