Language Fundamentals

JavaScript is dynamically typed: a variable is not bound to a type, only its current value is. The type lives on the value, and the engine checks it at the moment an operation runs — not when the code is written. Statically typed languages (Java, Kotlin, TypeScript at compile time) reject a mismatched assignment before the program starts; JavaScript happily runs it and only fails, if at all, when an operation can't be performed on the value it actually finds.

A useful mental model: a variable is a label on a slot, and the slot can hold any kind of value. Asking "what type is x?" really means "what type is the value in x's slot right now?" — which is exactly what typeof answers.

let x = 10;    // number
x = "Hello";   // now a string — perfectly legal
console.log(typeof x); // "string"

let a = 1;
let b = a;   // copy of the value
b++;
console.log(a); // 1

const o1 = { n: 1 };
const o2 = o1;  // copy of the reference
o2.n++;
console.log(o1.n); // 2 — same object

function reassign(obj) {
  obj = { n: 99 };   // points the local parameter somewhere else
}
function mutate(obj) {
  obj.n = 99;        // changes the shared object
}

const box = { n: 1 };
reassign(box);
console.log(box.n); // 1
mutate(box);
console.log(box.n); // 99

All three declare variables; they differ in where the variable is visible (scope), what happens before the declaration line runs (hoisting) and whether you can assign it again. var is the original from 1995. let and const arrived in ES2015 to fix its two biggest problems: it ignores block boundaries, and it can be used — silently as undefined — before it's declared.

A few rows deserve a sentence each:

• Re-declare is a SyntaxError, which means the engine rejects the whole script while parsing it — not one line of it runs. var x; var x; is fine and quietly reuses the same variable, which is how accidental clashes went unnoticed in big files.
• Re-assigning a const is a TypeError at runtime: Assignment to constant variable. The code up to that line has already run.
• The window property row applies to classic <script> files only. A top-level var foo there becomes window.foo, visible to every other script on the page. Top-level let/const go into a shared script scope instead, and inside ES modules nothing is global at all.

function scopes() {
  if (true) {
    var a = 1;
    let b = 2;
    const c = 3;
  }
  console.log(a); // 1  — var ignores the block
  console.log(b); // ReferenceError: b is not defined
}

Hoisting: before any code runs, the engine registers every declaration in a scope. Declarations are "moved to the top"; initialisations are not.

Nothing actually moves. What really happens is that the engine processes a scope in two passes. In the creation phase it scans the scope and creates a binding for every declaration it finds: var bindings start as undefined, function declarations are bound to the whole function, and let/const/class bindings are created but left uninitialised. Then the execution phase runs the code top to bottom, and assignments happen when their line is reached. "Hoisting" is just the visible effect of that first pass.

console.log(x); // undefined — declaration hoisted, value not
var x = 5;

hoisted(); // works: function declarations are hoisted with their body
function hoisted() {
  console.log("I am hoisted");
}

notHoisted(); // TypeError: notHoisted is not a function
var notHoisted = function () {};

console.log(y); // ReferenceError: Cannot access 'y' before initialization
let y = 5;

let x = 10;
function test() {
  console.log(x);
  let x = 20;
}
test();

An inner scope can declare a variable with the same name as an outer one; the inner one shadows the outer one inside its block. They are two separate variables that happen to share a name. Name lookup always starts in the innermost scope and walks outwards, stopping at the first match — so inside the block, the outer variable is simply unreachable by that name.

let x = 10;
{
  let x = 20;     // a different variable
  console.log(x); // 20
}
console.log(x);   // 10 — block scope keeps them apart

let a = 1;
{
  var a = 2; // SyntaxError: Identifier 'a' has already been declared
}

• === strict equality — no type conversion. Same type and same value.
• == loose equality — converts the operands to a common type first, then compares.

Loose equality follows a fixed algorithm, and knowing its order lets you predict any result. If the types already match, it behaves exactly like ===. Otherwise: null and undefined equal each other and nothing else; a boolean is converted to a number (true → 1, false → 0); a string compared with a number is converted to a number; and an object compared with a primitive is converted to a primitive (via valueOf, then toString). It repeats until both sides have the same type. For objects on both sides, both operators just compare references — two different objects are never equal, however similar.

1 == "1";            // true  ("1" → 1)
0 == false;          // true  (false → 0)
"" == 0;             // true  ("" → 0)
null == undefined;   // true  (special rule)
null == 0;           // false (null only == undefined)

1 === "1";           // false — different types
0 === false;         // false
null === undefined;  // false

NaN === NaN;               // false — NaN is not equal to anything
Number.isNaN(NaN);         // true
Object.is(NaN, NaN);       // true
Object.is(0, -0);          // false (=== says true)
[] == ![];                 // true 🙃  ![] → false → 0, [] → "" → 0

In a boolean context every value becomes true or false. A "boolean context" is anywhere JavaScript needs a yes/no answer: if, while, the ternary ? :, !, and the left side of && and ||. The engine converts the value with the same rules as Boolean(value). There are exactly 8 falsy values; everything else is truthy.

false, 0, -0, 0n, "", null, undefined, NaN

const items = [];
if (items) console.log("runs — [] is truthy");
if (items.length) console.log("never runs");

const qty = "0";            // e.g. from an <input>
if (qty) console.log("runs — non-empty string");
if (Number(qty)) console.log("never runs");

Both operators (ES2020) exist for the same reason: in real data, values are often missing, and JavaScript represents "missing" with null or undefined. Before ES2020 you guarded against that with && chains and || defaults, and both of those treat every falsy value as missing — which is wrong for 0, "" and false. The new operators look only at null and undefined, which together are called nullish.

Optional chaining reads deeply nested properties safely: if anything before ?. is null or undefined, the whole expression short-circuits to undefined instead of throwing.

const user = { name: "Alice", address: { city: "Wonderland" } };

// Old way
const city1 = user && user.address && user.address.city;

// With optional chaining
const city2 = user?.address?.city;      // "Wonderland"
const zip = user?.address?.zip?.code;   // undefined, no error

const key = "city";
user.address?.[key];        // dynamic property
user.greet?.();             // call only if greet exists
callbacks.onDone?.(result); // common for optional callbacks

const count = 0;
count || 10;  // 10  — 0 is falsy, oops
count ?? 10;  // 0   — 0 is a real value, keep it

const input = null;
const finalInput = input ?? "Default Value"; // "Default Value"

config.retries ??= 3;    // assign only if null/undefined
user.name ||= "Guest";   // assign if falsy
cache.hits &&= cache.hits + 1; // assign only if truthy

Assigning to a name that was never declared with var, let or const silently creates a global variable in sloppy mode. In strict mode it throws.

"Sloppy mode" is the informal name for JavaScript's original, forgiving behaviour. Strict mode (ES5, 2009) is an opt-in variant that turns a set of silent mistakes into errors. It couldn't simply change the default, because that would have broken existing websites — so it's opt-in, and newer syntax (modules, classes) opts in automatically.

function foo() {
  x = 1; // sloppy mode: creates global x. Strict mode: ReferenceError
}
foo();
console.log(x); // 1

JavaScript has one number type for both integers and decimals: every number is a 64-bit IEEE 754 floating-point value (a "double"). There's no separate int, so "is this an integer?" really means "does this number have no fractional part?". That single representation also explains the famous rounding errors and the limit on safe integers below.

My notes said to check x % 1 === 0. That works, but there's a built-in that also handles the edge cases:

Number.isInteger(5);      // true
Number.isInteger(5.0);    // true — 5.0 is the same number as 5
Number.isInteger(5.5);    // false
Number.isInteger("5");    // false — no coercion
Number.isInteger(Infinity); // false (but Infinity % 1 is NaN, so the % trick is also fine)

const isFloat = (n) => Number.isFinite(n) && !Number.isInteger(n);

0.1 + 0.2 === 0.3;                 // false (0.30000000000000004)
Math.abs(0.1 + 0.2 - 0.3) < Number.EPSILON; // true — compare with a tolerance
Number.MAX_SAFE_INTEGER;           // 9007199254740991 (2^53 - 1)
2 ** 53 === 2 ** 53 + 1;           // true! use BigInt beyond this
9007199254740993n + 1n;            // 9007199254740994n
parseInt("08px");                  // 8 — parses until it can't
Number("08px");                    // NaN — all or nothing

Coercion is JavaScript converting a value to another type automatically because an operator needs it. It's driven by the operator, not the value: + might want strings or numbers, - always wants numbers, if wants a boolean. When an operator needs a primitive and gets an object, it calls the object's valueOf() first and, if that doesn't return a primitive (for plain objects and arrays it returns the object itself), falls back to toString(). Knowing that one rule decodes every line below.

"5" + 3;        // "53"   + with a string concatenates
"5" - 3;        // 2      other maths operators convert to number
"5" * "2";      // 10
true + 1;       // 2
[] + [];        // ""
[] + {};        // "[object Object]"
+"";            // 0
+"  42  ";      // 42
+"4 2";         // NaN
String(null);   // "null"
Number(null);   // 0
Number(undefined); // NaN