DEV Community: Surya Kanth

JavaScript Callbacks & Array.prototype.filter(): From First Principles to a Custom Polyfill

Surya Kanth — Tue, 06 Oct 2026 06:59:02 +0000

You've written this line a hundred times:

const adults = users.filter(user => user.age >= 18);

But do you know why it works, what happens inside filter, and where it silently betrays you (hello, async predicates)?

In this guide we'll build the mental model from the ground up:

Why functions being "first-class" makes callbacks possible
Sync vs async callbacks and the event loop
How filter() actually works, including a hand-written polyfill
Real-world patterns and the traps that bite even senior devs

🧠 The Core Intuition: Functions Are Just Values

In JavaScript, functions are first-class citizens. That means a function can be:

// 1. Stored in a variable
const greet = name => `Hello, ${name}!`;

// 2. Stored in a data structure
const handlers = { greet, shout: name => name.toUpperCase() };

// 3. Passed as an argument to another function
function run(fn, value) {
  return fn(value); // we don't care WHAT fn does, only that it's callable
}

// 4. Returned from another function
function multiplier(factor) {
  return n => n * factor; // a closure remembering `factor`
}

console.log(run(greet, "Surya"));   // "Hello, Surya!"
console.log(multiplier(3)(5));      // 15

A callback is simply a function you hand to another function so it can call it later.

"Later" is the interesting part. It might be immediately (inside filter) or eventually (after a network request). That distinction is Part 1.

Part 1: Callback Functions

The Anatomy

//        higher-order function
//               ↓
function doWork(data, callback) {
  const result = data * 2;
  callback(result); // "calling back" into code the caller supplied
}

doWork(21, result => console.log(result)); // 42
//          ↑ the callback

A function that accepts (or returns) another function is a higher-order function. The function you pass in is the callback.

Synchronous Callbacks

Synchronous callbacks run to completion before the calling function returns. filter, map, forEach, and sort all work this way.

console.log("1: before");

[1, 2, 3].forEach(n => console.log(`2: callback ${n}`));

console.log("3: after");

// Output order:
// 1: before
// 2: callback 1
// 2: callback 2
// 2: callback 3
// 3: after

Asynchronous Callbacks

Asynchronous callbacks are scheduled and run after the current code finishes.

console.log("1: before");

setTimeout(() => console.log("2: timeout callback"), 0);

console.log("3: after");

// Output order:
// 1: before
// 3: after
// 2: timeout callback   ← even with a 0ms delay!

Why does a 0ms timer still run last? The event loop.

flowchart LR
    A[Sync vs Async callback] --> B{When does it run?}
    B -->|Sync| C["Runs immediately,<br/>inside the caller<br/>(filter, map, forEach)"]
    B -->|Async| D["Queued, runs later<br/>(setTimeout, fetch, events)"]
    C --> E[Caller waits for it]
    D --> F[Caller returns right away]

The Event Loop's Role

JavaScript runs on a single thread with one call stack. Async work (timers, network, DOM events) is handled by the host environment (browser or Node.js). When it finishes, the callback is placed in a queue. The event loop moves it onto the stack only when the stack is empty.

flowchart TD
    subgraph JS Engine
        CS[Call Stack]
    end
    subgraph Host Environment
        API["Web APIs / Node APIs<br/>(timers, fetch, DOM)"]
    end
    MQ["Microtask Queue<br/>(Promise .then, queueMicrotask)"]
    TQ["Task / Callback Queue<br/>(setTimeout, events)"]
    EL((Event Loop))

    CS -->|"registers async work"| API
    API -->|"timer done / response arrived"| TQ
    EL -->|"1. stack empty? drain microtasks first"| MQ
    EL -->|"2. then take one task"| TQ
    MQ --> CS
    TQ --> CS

Key rule: microtasks (Promises) run before the next task (timers).

setTimeout(() => console.log("timeout"), 0);          // task queue
Promise.resolve().then(() => console.log("promise")); // microtask queue
console.log("sync");

// sync → promise → timeout

Error Handling in Callbacks

Trap #1: try/catch cannot catch errors thrown inside an async callback, because by the time it runs, the try block has long since exited.

try {
  setTimeout(() => {
    throw new Error("Boom!"); // ❌ NOT caught below
  }, 0);
} catch (err) {
  console.log("Never runs");
}

Convention: error-first callbacks (the classic Node.js style). The first argument is always the error (or null).

import { readFile } from "node:fs";

readFile("config.json", "utf8", (err, data) => {
  if (err) {
    // Handle the failure FIRST and return early
    console.error("Failed to read file:", err.message);
    return;
  }
  console.log("File contents:", data);
});

Callback hell appears when async steps depend on each other:

getUser(id, (err, user) => {
  if (err) return handle(err);
  getPosts(user.id, (err, posts) => {
    if (err) return handle(err);
    getComments(posts[0].id, (err, comments) => {
      if (err) return handle(err);
      // 🔥 the pyramid of doom
    });
  });
});

The modern escape hatch is Promises and async/await. You can wrap legacy callback APIs with util.promisify:

import { promisify } from "node:util";
import { readFile } from "node:fs";

const readFileAsync = promisify(readFile);

async function main() {
  try {
    const data = await readFileAsync("config.json", "utf8");
    console.log(data);
  } catch (err) {
    console.error(err.message); // try/catch works again!
  }
}

Part 2: `Array.prototype.filter()` Deep-Dive

What It Does

filter() creates a new array containing only the elements for which your callback (the predicate) returns a truthy value.

const numbers = [1, 2, 3, 4, 5, 6];

const evens = numbers.filter(n => n % 2 === 0);

console.log(evens);   // [2, 4, 6]
console.log(numbers); // [1, 2, 3, 4, 5, 6] ← original untouched

Parameter Signature

const result = array.filter(callbackFn, thisArg);
//                          ↑            ↑
//                   required        optional: value of `this`
//                                   inside callbackFn
//                                   (ignored by arrow functions)

// callbackFn receives THREE arguments:
array.filter((element, index, array) => {
  // element → current item
  // index   → its position
  // array   → the array filter was called on
  return /* truthy to keep, falsy to drop */;
});

A handy use of index: de-duplicating.

const tags = ["js", "css", "js", "html", "css"];

// Keep an item only if this is its FIRST occurrence
const unique = tags.filter((tag, index, arr) => arr.indexOf(tag) === index);

console.log(unique); // ["js", "css", "html"]

Under the Hood: Predicate Execution

For each element, filter calls your predicate, coerces the return value to a boolean, and pushes the element into a fresh result array if it's truthy.

flowchart TD
    S([Start: filter called]) --> N[Create empty result array]
    N --> L{More elements?}
    L -->|No| R([Return result])
    L -->|Yes| P["Call predicate(element, index, array)"]
    P --> T{Truthy?}
    T -->|Yes| K[Push element into result]
    T -->|No| D[Skip element]
    K --> L
    D --> L

Here is the same thing as a sequence for [1, 2, 3, 4].filter(n => n > 2):

sequenceDiagram
    participant F as filter()
    participant P as predicate(n => n > 2)
    participant R as result []
    F->>P: call(1, 0, arr)
    P-->>F: false
    F->>P: call(2, 1, arr)
    P-->>F: false
    F->>P: call(3, 2, arr)
    P-->>F: true
    F->>R: push(3)
    F->>P: call(4, 3, arr)
    P-->>F: true
    F->>R: push(4)
    F-->>F: return [3, 4]

Immutability (and Its Limits)

filter() does not modify the original array, which makes it perfect for React state, Redux reducers, and functional pipelines.

But the new array is a shallow copy. Objects inside are shared by reference:

const users = [
  { id: 1, name: "Asha", active: true },
  { id: 2, name: "Ravi", active: false },
];

const activeUsers = users.filter(u => u.active);

activeUsers[0].name = "Changed!";   // mutating the OBJECT

console.log(users[0].name); // "Changed!" 😱 same object in both arrays

A Few Spec Behaviours Worth Knowing

Sparse arrays: empty slots are skipped, and the callback is never called for them.
The range is fixed up front: elements appended during iteration are not visited.
Elements removed before being visited are skipped, and elements modified before being visited are seen with their new values.
It's a generic method: it works on any array-like object (Array.prototype.filter.call(arrayLike, fn)).

📊 `filter()` vs `map()` vs `find()` vs `reduce()`

Method	Purpose	Callback returns	Output	Output length	Short-circuits?
`filter()`	Keep a subset	Truthy / falsy	New array of original elements	0 to n	No
`map()`	Transform each item	Any new value	New array of transformed values	Exactly n	No
`find()`	Locate the first match	Truthy / falsy	Single element or `undefined`	0 or 1 item	✅ Yes
`reduce()`	Fold into one value	New accumulator	Anything (number, object, array...)	Depends	No

const nums = [1, 2, 3, 4, 5];

nums.filter(n => n > 2);          // [3, 4, 5]    → subset
nums.map(n => n * 2);             // [2,4,6,8,10] → transformed
nums.find(n => n > 2);            // 3            → first match only
nums.reduce((sum, n) => sum + n, 0); // 15        → single value

Rule of thumb: need one item? Use find. Need a subset? Use filter. Need the same count but changed? Use map. Need to collapse? Use reduce.

🛠 Real-World Use Cases

1. Clean Data Sanitization

const rawInput = ["  Alice ", "", null, "Bob", undefined, "   ", "Alice"];

const cleaned = rawInput
  .filter(Boolean)                          // drop null / undefined / ""
  .map(str => str.trim())                   // normalize whitespace
  .filter(str => str.length > 0)            // drop whitespace-only strings
  .filter((str, i, arr) => arr.indexOf(str) === i); // de-duplicate

console.log(cleaned); // ["Alice", "Bob"]

2. Search Filters

const products = [
  { name: "Mechanical Keyboard", category: "peripherals", price: 89 },
  { name: "USB-C Cable",         category: "cables",      price: 12 },
  { name: "Wireless Mouse",      category: "peripherals", price: 35 },
];

/**
 * Compose several optional filters.
 * A filter that is not provided simply doesn't apply.
 */
function searchProducts(items, { query = "", category, maxPrice = Infinity }) {
  const q = query.trim().toLowerCase();

  return items.filter(item =>
    item.name.toLowerCase().includes(q) &&           // text search
    (!category || item.category === category) &&     // optional category
    item.price <= maxPrice                           // price ceiling
  );
}

console.log(searchProducts(products, { category: "peripherals", maxPrice: 50 }));
// [{ name: "Wireless Mouse", ... }]

💡 In a live search box, wrap the handler in a debounce so you don't filter on every single keystroke.

3. Async Edge Cases

filter() does not await anything. An async predicate returns a Promise, and a Promise is always truthy.

const ids = [1, 2, 3];

// ❌ BROKEN: every Promise is truthy, so nothing is filtered out
const broken = ids.filter(async id => {
  const user = await fetchUser(id);
  return user.isActive;
});
console.log(broken); // [1, 2, 3] 😱

Fix A, in parallel: resolve all the checks first, then filter by the results.

async function filterAsync(array, asyncPredicate) {
  // 1. Run every predicate concurrently → array of booleans
  const results = await Promise.all(array.map(asyncPredicate));
  // 2. Use the booleans to filter synchronously
  return array.filter((_, index) => results[index]);
}

const activeIds = await filterAsync(ids, async id => {
  const user = await fetchUser(id);
  return user.isActive;
});

Fix B, sequentially: when you must avoid hammering an API or need ordering.

async function filterSequential(array, asyncPredicate) {
  const result = [];
  for (const [index, item] of array.entries()) {
    // await each check before starting the next
    if (await asyncPredicate(item, index, array)) {
      result.push(item);
    }
  }
  return result;
}

flowchart LR
    A["ids.filter(async fn)"] --> B["Predicate returns<br/>Promise (truthy!)"]
    B --> C["❌ Nothing filtered"]
    D["Promise.all(ids.map(asyncFn))"] --> E["Array of booleans"]
    E --> F["ids.filter((_, i) => results[i])"]
    F --> G["✅ Correct result"]

🚀 Advanced: Writing a `filter()` Polyfill

Building it yourself is the best way to cement your understanding, and it's a classic interview question. We'll follow the spec's behaviour closely.

// We name it `myFilter` so we don't overwrite the native method.
// To polyfill for real, you'd guard with: if (!Array.prototype.filter) { ... }
Object.defineProperty(Array.prototype, "myFilter", {
  value: function myFilter(callbackFn, thisArg) {
    // 1. `this` must not be null/undefined
    if (this == null) {
      throw new TypeError("Array.prototype.myFilter called on null or undefined");
    }

    // 2. The callback must actually be callable
    if (typeof callbackFn !== "function") {
      throw new TypeError(`${String(callbackFn)} is not a function`);
    }

    // 3. Convert `this` to an object and fix the length UP FRONT.
    //    (This is why elements appended during iteration are never visited.)
    const O = Object(this);
    const len = O.length >>> 0; // coerce to an unsigned 32-bit integer

    const result = []; // 4. The brand-new output array

    for (let i = 0; i < len; i++) {
      // 5. `i in O` skips holes in sparse arrays, just like the native method
      if (i in O) {
        const element = O[i];

        // 6. Call the predicate with (element, index, array),
        //    binding `this` to thisArg
        if (callbackFn.call(thisArg, element, i, O)) {
          result.push(element); // 7. Truthy → keep it
        }
      }
    }

    return result; // 8. Original array is never touched
  },
  writable: true,       // match the attributes of built-in methods
  configurable: true,
  enumerable: false,    // IMPORTANT: keeps it out of for...in loops
});

// ✅ Test it
console.log([1, 2, 3, 4].myFilter(n => n % 2 === 0)); // [2, 4]
console.log([1, , 3].myFilter(() => true));            // [1, 3] (hole skipped)
console.log([1, 2, 3].myFilter(function () { return this.keep; }, { keep: true })); // [1, 2, 3]

What each decision teaches you:

Line	Why it matters
`Object(this)` + `>>> 0`	Makes it work on array-likes and guarantees a valid length
`len` captured once	Explains why `push` inside a callback doesn't cause an infinite loop
`i in O`	Sparse array behaviour
`callbackFn.call(thisArg, ...)`	How `thisArg` works (and why arrow functions ignore it)
`enumerable: false`	Avoids polluting `for...in` loops across your whole app

⚠️ Common Pitfalls

1. Truthy / Falsy Traps

filter(Boolean) is a popular shortcut, but it removes every falsy value, including legitimate ones.

const scores = [100, 0, 85, NaN, 42, ""];

console.log(scores.filter(Boolean)); // [100, 85, 42]
//                                     ↑ the valid score 0 was deleted too!

// ✅ Be explicit about what you actually want to remove
const validScores = scores.filter(s => typeof s === "number" && !Number.isNaN(s));
console.log(validScores); // [100, 0, 85, 42]

Falsy values to remember: false, 0, -0, 0n, "", null, undefined, NaN.
Watch out for the opposite too: "0", "false", [] and {} are all truthy.

2. Forgetting `return` with Braces

// ❌ Block body with no return → predicate returns undefined → everything dropped
[1, 2, 3].filter(n => { n > 1 });  // []

// ✅ Implicit return (no braces)
[1, 2, 3].filter(n => n > 1);      // [2, 3]

// ✅ Explicit return (with braces)
[1, 2, 3].filter(n => { return n > 1; }); // [2, 3]

3. Mutating Inside Callbacks

A predicate should be a pure function: same input, same output, no side effects.

const items = [{ id: 1, seen: false }, { id: 2, seen: false }];

// ❌ Side effect hidden in a filter, which is confusing and breaks immutability
const visible = items.filter(item => {
  item.seen = true;   // mutates the original objects!
  return item.id > 1;
});

// ✅ Filter first, then transform into new objects
const visibleFixed = items
  .filter(item => item.id > 1)
  .map(item => ({ ...item, seen: true }));

Also avoid mutating the array itself (arr.splice, arr.push) inside its own filter. The results are hard to reason about because of the spec behaviours above.

4. Async Callbacks

Covered above. Never pass an async function directly to filter. Use Promise.all + map, or a for...of loop.

5. Using `filter` When You Need `find`

// ❌ Scans the whole array, then throws away all but one result
const user = users.filter(u => u.id === 42)[0];

// ✅ Stops at the first match and says what you mean
const user2 = users.find(u => u.id === 42);

6. Chaining Many `filter`s on Huge Arrays

Each .filter() allocates a new array. For small data it doesn't matter, but on large data sets combine conditions into one pass, or use a single reduce/loop.

// Three passes, three intermediate arrays
data.filter(a).filter(b).filter(c);

// One pass
data.filter(x => a(x) && b(x) && c(x));

🎯 Key Takeaways

Functions are values, which is why callbacks exist.
Sync callbacks run inside the caller. Async callbacks are queued and run by the event loop when the stack is empty.
try/catch doesn't cross async boundaries. Use error-first callbacks or Promises.
filter() returns a new, shallow-copied array and never mutates the original.
The predicate's return value is coerced to boolean. Be deliberate about truthy/falsy.
Never pass an async predicate straight into filter().
Writing the polyfill reveals the real behaviour: fixed length, hole skipping, thisArg binding.

🧪 Try It Yourself

Write filterAsync with a concurrency limit (e.g., max 3 requests at once).
Extend the polyfill to also work on Map iterators.
Rewrite Array.prototype.map as a polyfill using the same structure.

Found this useful? Drop a ❤️, and tell me in the comments which JavaScript concept you'd like unpacked next!

JavaScript Functions & Object CRUD: The Complete Guide from Declarations to Object.freeze()

Surya Kanth — Wed, 30 Sep 2026 06:40:28 +0000

If you've ever asked yourself "Why is this undefined here?" or "Should I mutate this object or copy it?", this guide is for you.

Functions and objects are the two pillars of JavaScript. Almost everything you build, from a React component to an Express route, is a function operating on an object. In this article we'll go step by step through:

The four kinds of functions and how they differ
What happens when functions live inside objects
Complete CRUD (Create, Read, Update, Delete) on objects, including immutable patterns

All examples are ES6+ and can be pasted into Node or your browser console. Let's go. 🚀

Section 1: Demystifying JavaScript Functions

1.1 Named Function Declarations

A function declaration is the classic way to define a function. It starts with the function keyword, followed by a required name.

// Syntax: function name(parameters) { body }
function calculateCartTotal(prices) {
  // reduce sums every price, starting from 0
  return prices.reduce((sum, price) => sum + price, 0);
}

console.log(calculateCartTotal([19.99, 5.5, 3.25]));
// Output: 28.74

Use cases: reusable utilities, top-level helpers, and any function you want available across the whole file.

Hoisting: why you can call it before it's defined

Before JavaScript runs your code, the engine creates an execution context in two phases:

Creation phase: the engine scans the scope, registers variables and function declarations, and stores the entire function in memory.
Execution phase: code runs line by line.

Because declarations are fully stored during the creation phase, this works:

// ✅ AFTER-style call: works even though the definition is below
console.log(greetUser("Asha"));
// Output: Hello, Asha!

function greetUser(name) {
  return `Hello, ${name}!`;
}

// The engine effectively sees it like this:
// [creation phase] greetUser -> function (fully available)
// [execution phase] console.log(greetUser("Asha"))

Now compare with a function expression (more in the next section):

// ❌ BEFORE the definition: the variable exists but is not initialized
try {
  console.log(sayHi("Asha"));
} catch (error) {
  console.log(`${error.name}: ${error.message}`);
}
// Output: ReferenceError: Cannot access 'sayHi' before initialization

const sayHi = function (name) {
  return `Hi, ${name}!`;
};

💡 Tip: const and let are hoisted too, but they sit in the Temporal Dead Zone (TDZ) until their line runs. With old-school var, you'd get TypeError: sayHi is not a function instead, because var is hoisted as undefined.

1.2 Function Expressions

A function expression creates a function as part of an expression and typically assigns it to a variable.

// Assigned to a const: the standard modern choice
const formatPrice = function (amount) {
  return `$${amount.toFixed(2)}`;
};

console.log(formatPrice(9.5));
// Output: $9.50

💡 Tip: Prefer const for function expressions so you can't accidentally reassign the function later.

Anonymous vs. Named Function Expressions (NFE)

// Anonymous function expression: no name after `function`
const double = function (n) {
  return n * 2;
};

// Named function expression (NFE): the name "fact" is *internal*
const factorial = function fact(n) {
  // The internal name lets the function call itself reliably
  return n <= 1 ? 1 : n * fact(n - 1);
};

console.log(factorial(5));
// Output: 120

console.log(typeof fact);
// Output: undefined  (the NFE name is only visible INSIDE the function)

Why NFEs are useful:

Benefit	Explanation
Better stack traces	Errors show `at fact (file.js:3)` instead of `at <anonymous>`
Safe recursion	`fact` always points to this function, even if the outer variable is reassigned
Self-documenting	The name describes what the function does

💡 Tip: Modern engines infer a name when you write const double = function () {}. The real win for NFEs is on inline functions (like callbacks) that have no variable to infer from.

1.3 Anonymous Functions

A function is anonymous when it has no name of its own. You'll mostly see them where a function is passed as a value.

As callbacks

// With setTimeout
setTimeout(function () {
  console.log("Session expired!");
}, 1000);
// Output (after 1 second): Session expired!

// With array iterator methods
const products = [
  { name: "Keyboard", price: 49 },
  { name: "Mouse", price: 25 },
  { name: "Monitor", price: 199 },
];

const affordable = products.filter(function (product) {
  return product.price < 100;
});

console.log(affordable.map((p) => p.name));
// Output: [ 'Keyboard', 'Mouse' ]

IIFEs (Immediately Invoked Function Expressions)

An IIFE defines a function and runs it right away.

(function () {
  const secret = "only visible in here";
  console.log("IIFE executed!");
})();
// Output: IIFE executed!

// console.log(secret); // ❌ ReferenceError: secret is not defined

Historical usage: before ES6, var was function-scoped only, and there were no modules. IIFEs were the go-to trick to avoid polluting the global scope and to create "private" variables (the module pattern).

// Classic module pattern with a private counter
const counter = (function () {
  let count = 0; // private: can't be touched from outside
  return {
    increment: () => ++count,
    getCount: () => count,
  };
})();

counter.increment();
counter.increment();
console.log(counter.getCount());
// Output: 2

Modern usage: let/const give block scope and ES modules give file scope, so IIFEs are much rarer. They're still handy for top-level await alternatives and one-off setup code:

(async () => {
  const response = await fetch("https://api.example.com/user");
  console.log(response.status);
})();

1.4 Arrow Functions (ES6+)

Arrow functions give you shorter syntax and different this behavior.

Syntax variations

// 1. Standard arrow function with a block body (explicit return needed)
const add = (a, b) => {
  return a + b;
};

// 2. Implicit return: drop the braces and `return`
const addShort = (a, b) => a + b;

// 3. Single argument: parentheses are optional
const square = (n) => n * n;
const squareNoParens = n => n * n;

// 4. No arguments: parentheses are required
const getTimestampLabel = () => "Now";

// 5. Returning an object literal: wrap it in parentheses!
const createUser = (name) => ({ name, active: true });

console.log(add(2, 3));           // Output: 5
console.log(square(4));           // Output: 16
console.log(createUser("Riya"));  // Output: { name: 'Riya', active: true }

⚠️ Warning: Without the parentheses, () => { name: "Riya" } is parsed as a block with a label, not an object, and it returns undefined.

const broken = (name) => { name, active: true }; // ❌ SyntaxError
const alsoBroken = (name) => { return; };        // returns undefined

Lexical `this`: the big difference

A regular function creates its own this, decided by how it's called.
An arrow function has no this of its own. It inherits this from the surrounding scope (lexical scoping).

const player = {
  name: "Kai",
  hobbies: ["chess", "cycling"],

  // Regular function inside map: gets its OWN `this`
  listWithFunction() {
    return this.hobbies.map(function (hobby) {
      return `${this.name} likes ${hobby}`;
    });
  },

  // Arrow function inside map: inherits `this` from listWithArrow()
  listWithArrow() {
    return this.hobbies.map((hobby) => `${this.name} likes ${hobby}`);
  },
};

console.log(player.listWithArrow());
// Output: [ 'Kai likes chess', 'Kai likes cycling' ]

console.log(player.listWithFunction());
// Output (non-strict mode): [ 'undefined likes chess', 'undefined likes cycling' ]
// In strict mode or ES modules this throws:
// TypeError: Cannot read properties of undefined (reading 'name')

Arrow functions also have no arguments object and can't be used with new:

const Person = (name) => { this.name = name; };
// new Person("Asha"); // ❌ TypeError: Person is not a constructor

Section 2: Objects Meet Functions (Object Methods)

When a function is stored as a property of an object, we call it a method.

2.1 Shorthand Method Syntax

const userProfile = {
  name: "Meera",

  // Old way (ES5): property assigned a function expression
  greetOld: function () {
    return `Hi, I'm ${this.name}`;
  },

  // ES6 shorthand: cleaner, same behavior
  greet() {
    return `Hi, I'm ${this.name}`;
  },
};

console.log(userProfile.greet());
// Output: Hi, I'm Meera

💡 Tip: Shorthand methods can use super and are the idiomatic choice in modern code. They also can't be used as constructors, which is usually what you want for a method.

2.2 Dynamic Binding of `this`

In a standard method, this is determined at call time. The rule of thumb is that it points to the object to the left of the dot.

const account = {
  holder: "Arjun",
  balance: 1500,
  describe() {
    return `${this.holder} has ₹${this.balance}`;
  },
};

console.log(account.describe());
// Output: Arjun has ₹1500   (this === account)

// The SAME function, called with a different object on the left:
const otherAccount = { holder: "Sana", balance: 800, describe: account.describe };
console.log(otherAccount.describe());
// Output: Sana has ₹800     (this === otherAccount)

// Detach the method and `this` is lost:
const detached = account.describe;
// detached(); // ❌ strict mode: TypeError. Sloppy mode: "undefined has ₹undefined"

// ✅ Fix with bind (creates a new function with a permanently fixed `this`)
const bound = account.describe.bind(account);
console.log(bound());
// Output: Arjun has ₹1500

⚠️ Warning: This is exactly why passing obj.method as a callback (e.g., button.addEventListener("click", obj.method)) often breaks. Use .bind() or wrap it in an arrow function.

2.3 Why You Should (Almost) Never Use Arrow Functions as Object Methods

Arrow functions don't get their own this, and an object literal is not a scope. So this inside an arrow "method" points to whatever this is outside the object (the module, or window in a classic browser script).

// ❌ BROKEN
const brokenUser = {
  username: "dev_ninja",
  sayHello: () => `Hi, ${this.username}!`,
};

console.log(brokenUser.sayHello());
// Output: Hi, undefined!
// (in a classic script or CommonJS; in an ES module `this` is undefined,
//  so it throws a TypeError instead)

// ✅ FIX: use shorthand method syntax
const fixedUser = {
  username: "dev_ninja",
  sayHello() {
    return `Hi, ${this.username}!`;
  },
};

console.log(fixedUser.sayHello());
// Output: Hi, dev_ninja!

The winning pattern is to use a regular method on the object, and arrow functions inside it for callbacks (as we saw with listWithArrow).

💡 Tip: The exception is when you deliberately don't want dynamic this, such as a method that never touches this. Even then, shorthand syntax keeps things consistent.

Section 3: Complete CRUD Operations on Objects

Let's build up a realistic example: a user profile and a shopping cart.

3.1 Create (Add Properties)

Dot vs. bracket notation

const user = {};

// Dot notation: clean, but the key must be a valid identifier
user.name = "Priya";
user.age = 27;

// Bracket notation: needed for spaces, dashes, or dynamic keys
user["favorite-color"] = "teal";
user["full name"] = "Priya Sharma";

const field = "email";
user[field] = "priya@example.com"; // key comes from a variable

console.log(user);
// Output: {
//   name: 'Priya',
//   age: 27,
//   'favorite-color': 'teal',
//   'full name': 'Priya Sharma',
//   email: 'priya@example.com'
// }

Computed property names

Build dynamic keys right inside the object literal:

const settingKey = "theme";

const settings = {
  [settingKey]: "dark",            // key becomes "theme"
  [`${settingKey}Version`]: 2,     // key becomes "themeVersion"
  language: "en",
};

console.log(settings);
// Output: { theme: 'dark', themeVersion: 2, language: 'en' }

Creating copies: `Object.assign()` and spread

const defaults = { theme: "light", notifications: true };
const overrides = { theme: "dark" };

// Object.assign(target, ...sources): copies into the FIRST argument
const merged1 = Object.assign({}, defaults, overrides);

// Spread: the modern, more readable equivalent
const merged2 = { ...defaults, ...overrides };

console.log(merged1);
// Output: { theme: 'dark', notifications: true }
console.log(merged2);
// Output: { theme: 'dark', notifications: true }

⚠️ Warning: Object.assign(defaults, overrides) (without the empty {} first) mutates defaults. Always pass {} as the target when you want a fresh copy.

⚠️ Warning: Both approaches are shallow copies. Nested objects are still shared by reference:

const original = { name: "Leo", address: { city: "Chennai" } };
const copy = { ...original };

copy.address.city = "Mumbai";
console.log(original.address.city);
// Output: Mumbai   😱 (the nested object is shared!)

3.2 Read (Access & Inspect)

Safe access with `?.` and `??`

const customer = {
  name: "Dev",
  address: { city: "Pune" },
  loyaltyPoints: 0,
};

// ❌ Without optional chaining, missing parents throw
// customer.billing.zip; // TypeError: Cannot read properties of undefined

// ✅ Optional chaining: returns undefined instead of throwing
console.log(customer.billing?.zip);
// Output: undefined

// Nullish coalescing (??): fallback ONLY for null/undefined
console.log(customer.billing?.zip ?? "No ZIP on file");
// Output: No ZIP on file

// Why ?? beats ||: it respects valid falsy values like 0
console.log(customer.loyaltyPoints ?? 100); // Output: 0
console.log(customer.loyaltyPoints || 100); // Output: 100  ← wrong!

// Optional chaining also works on methods and arrays
console.log(customer.getDiscount?.());  // Output: undefined
console.log(customer.orders?.[0]);      // Output: undefined

Inspecting objects

const cart = { laptop: 1, mouse: 2, keyboard: 1 };

console.log(Object.keys(cart));
// Output: [ 'laptop', 'mouse', 'keyboard' ]

console.log(Object.values(cart));
// Output: [ 1, 2, 1 ]

console.log(Object.entries(cart));
// Output: [ [ 'laptop', 1 ], [ 'mouse', 2 ], [ 'keyboard', 1 ] ]

// Iterating entries with for...of and destructuring
for (const [item, quantity] of Object.entries(cart)) {
  console.log(`${item} x${quantity}`);
}
// Output:
// laptop x1
// mouse x2
// keyboard x1

Checking property existence

const profile = { name: "Zara", nickname: undefined };

// `in` checks the object AND its prototype chain
console.log("name" in profile);      // Output: true
console.log("toString" in profile);  // Output: true  (inherited from Object.prototype!)

// Object.hasOwn() checks ONLY the object's own properties (ES2022)
console.log(Object.hasOwn(profile, "name"));      // Output: true
console.log(Object.hasOwn(profile, "toString"));  // Output: false
console.log(Object.hasOwn(profile, "nickname"));  // Output: true (exists, value is undefined)

// Older equivalent (works everywhere)
console.log(profile.hasOwnProperty("name"));      // Output: true

💡 Tip: Prefer Object.hasOwn(obj, key) over obj.hasOwnProperty(key). It also works on objects created with Object.create(null), which have no hasOwnProperty method.

3.3 Update (Modify Properties)

Mutable in-place updates

const settings = { theme: "light", fontSize: 14 };

settings.theme = "dark";   // change an existing property
settings.fontSize += 2;    // compute from the old value

console.log(settings);
// Output: { theme: 'dark', fontSize: 16 }

Simple and fast, but it changes the original object. Anything else holding a reference to it sees the change.

Immutable updates with spread

const oldSettings = { theme: "light", fontSize: 14 };

// Copy everything, then override what changed
const newSettings = { ...oldSettings, theme: "dark" };

console.log(oldSettings);
// Output: { theme: 'light', fontSize: 14 }   ← untouched
console.log(newSettings);
// Output: { theme: 'dark', fontSize: 14 }
console.log(oldSettings === newSettings);
// Output: false   (a brand-new reference)

💡 Tip: Immutable updates are crucial for React, Vue (reactive refs), and Redux. These tools detect changes by comparing references. If you mutate in place, the reference stays the same and your UI may not re-render.

// React-style state update
// setUser(prev => ({ ...prev, name: "New Name" }));

Deep nested updates

const state = {
  user: {
    name: "Nikhil",
    preferences: { theme: "light", language: "en" },
  },
  isLoggedIn: true,
};

// 1️⃣ Mutable: simple, but modifies the original
state.user.preferences.theme = "dark";

// 2️⃣ Immutable: spread at EVERY level along the path you're changing
const nextState = {
  ...state,
  user: {
    ...state.user,
    preferences: {
      ...state.user.preferences,
      theme: "dark",
    },
  },
};

console.log(nextState.user.preferences);
// Output: { theme: 'dark', language: 'en' }

💡 Tip: Deeply nested spreads get ugly fast. Options: flatten your state shape, use a helper like Immer, or use structuredClone() (built-in) for a true deep copy before mutating:

const deepCopy = structuredClone(state);
deepCopy.user.preferences.language = "ta";
console.log(state.user.preferences.language);
// Output: en   (the original is safe)

3.4 Delete (Remove Properties)

Mutable deletion with `delete`

const account = { id: 101, email: "a@b.com", tempToken: "xyz123" };

const wasDeleted = delete account.tempToken;

console.log(wasDeleted); // Output: true
console.log(account);    // Output: { id: 101, email: 'a@b.com' }

⚠️ Warning (performance): JavaScript engines like V8 optimize objects with predictable shapes ("hidden classes"). Deleting properties can push an object into slower dictionary mode. In hot code paths, consider setting the value to undefined/null, or use the immutable approach below. For everyday code, it's perfectly fine.

Immutable removal with rest destructuring

const userWithPassword = {
  id: 7,
  name: "Isha",
  password: "super-secret",
  role: "admin",
};

// Pull out the key you want to drop; collect everything else in `safeUser`
const { password, ...safeUser } = userWithPassword;

console.log(safeUser);
// Output: { id: 7, name: 'Isha', role: 'admin' }
console.log(userWithPassword.password);
// Output: super-secret   (original is intact)

💡 Tip: If your linter complains about the unused password variable, rename it with an underscore (_password) or configure ignoreRestSiblings.

Object Immutability Levels

JavaScript gives you three built-in levels of protection:

Method	Add props	Delete props	Modify values	Check with
`Object.preventExtensions()`	❌	✅	✅	`Object.isExtensible()`
`Object.seal()`	❌	❌	✅	`Object.isSealed()`
`Object.freeze()`	❌	❌	❌	`Object.isFrozen()`

"use strict"; // strict mode makes violations throw instead of failing silently

// 1️⃣ preventExtensions: no NEW properties
const a = { x: 1 };
Object.preventExtensions(a);
try { a.y = 2; } catch (e) { console.log(e.message); }
// Output: Cannot add property y, object is not extensible
delete a.x;  // still allowed
console.log(a);
// Output: {}

// 2️⃣ seal: no add, no delete, but values can change
const b = { x: 1 };
Object.seal(b);
b.x = 99;    // ✅ allowed
try { delete b.x; } catch (e) { console.log(e.message); }
// Output: Cannot delete property 'x' of #<Object>
console.log(b);
// Output: { x: 99 }

// 3️⃣ freeze: completely read-only
const config = { apiUrl: "https://api.example.com", retries: 3 };
Object.freeze(config);
try { config.retries = 5; } catch (e) { console.log(e.message); }
// Output: Cannot assign to read only property 'retries' of object '#<Object>'
console.log(Object.isFrozen(config));
// Output: true

⚠️ Warning: Without "use strict", these violations fail silently. Your code keeps running, but nothing changes. ES modules and classes are strict by default.

Shallow freeze vs. deep freeze

Object.freeze() is shallow. Nested objects stay mutable:

const appConfig = Object.freeze({
  name: "MyApp",
  database: { host: "localhost", port: 5432 },
});

appConfig.name = "Hacked";          // ❌ ignored (top level is frozen)
appConfig.database.port = 9999;     // ✅ works! nested object isn't frozen

console.log(appConfig);
// Output: { name: 'MyApp', database: { host: 'localhost', port: 9999 } }

To freeze everything, write a recursive deep freeze:

function deepFreeze(obj) {
  // Freeze nested objects first (children before parent)
  Object.values(obj).forEach((value) => {
    if (typeof value === "object" && value !== null && !Object.isFrozen(value)) {
      deepFreeze(value);
    }
  });
  return Object.freeze(obj);
}

const safeConfig = deepFreeze({
  name: "MyApp",
  database: { host: "localhost", port: 5432 },
});

safeConfig.database.port = 9999; // ❌ blocked (throws in strict mode)
console.log(safeConfig.database.port);
// Output: 5432

Quick Comparison: The 4 Function Types

Feature	Function Declaration	Function Expression	Anonymous Function	Arrow Function
Syntax	`function name() {}`	`const f = function() {}`	`function() {}` (no name, used inline)	`const f = () => {}`
Hoisting	✅ Fully hoisted (callable before definition)	❌ Not usable before definition (TDZ with `const`/`let`)	❌ N/A (depends on where it's assigned or passed)	❌ Not usable before definition (TDZ)
`this` binding	Dynamic (set by call site)	Dynamic (set by call site)	Dynamic (set by call site)	Lexical (inherited from enclosing scope)
Best use case	Top-level reusable utilities	Conditional definitions, NFEs for recursion	Short callbacks, IIFEs	Callbacks, array methods, keeping outer `this`

Key Takeaways

Declarations are hoisted, so they're great for top-level helpers.
Expressions aren't hoisted, and named ones give better stack traces and safer recursion.
Arrow functions are perfect for callbacks because they inherit this, but avoid them as object methods.
CRUD on objects: prefer spread for immutable creates/updates, rest destructuring for immutable deletes, and reach for freeze when you need guarantees.
Remember that spread and Object.freeze are both shallow. Use structuredClone() and deepFreeze() when depth matters.

Conclusion

Once functions and object CRUD click, a huge chunk of JavaScript (React state, API payloads, config handling) starts to feel a lot less mysterious. 🎉

Now I'd love to hear from you:

Do you default to arrow functions everywhere, or do you still reach for function declarations?
Spread, structuredClone, or Immer for nested updates?
Have you ever been bitten by a this bug or a shallow-copy surprise? Share your story!

Drop your preferred patterns in the comments below. 👇 And if this guide helped, a ❤️ or 🦄 goes a long way!

Happy coding! 💻

Under the Hood of JavaScript: Demystifying Hoisting, Objects, 'this', and the 'new' Keyword

Surya Kanth — Tue, 29 Sep 2026 07:01:09 +0000

You know that moment when JavaScript does something so weird you start suspecting your laptop is haunted?

console.log(name); // undefined... not an error?!
var name = "Ada";

Or when this is your object in one line and undefined in the next, and you didn't change anything?

JavaScript isn't random. It follows a small set of rules, and nobody explains them well on day one. Once these four ideas click, a huge chunk of "JS magic" turns into "oh, that makes sense":

Hoisting
Objects & references
this
The new keyword

Grab a coffee. Let's pop the hood. ☕

1. Hoisting: JavaScript Reads Your Code Twice

Here's the mental model that fixes most confusion:

Before JavaScript runs your code, it does a quick prep pass called the creation phase. During it, JS scans the scope and registers your declarations in memory. Then the execution phase runs your code line by line.

Hoisting is just a side effect of that prep pass. Your code isn't physically moved anywhere. Declarations are registered before execution begins.

┌─────────────────────────────────────────────┐
│  Execution Context                          │
│                                             │
│  PHASE 1: CREATION      PHASE 2: EXECUTION  │
│  ─────────────────      ─────────────────   │
│  • find declarations    • run line by line  │
│  • set aside memory     • assign values     │
│  • set initial state    • call functions    │
└─────────────────────────────────────────────┘

What each declaration gets during the creation phase depends on how you declared it.

Functions, `var`, and `let`/`const` side by side

Declaration	Hoisted?	Initial value during creation	Usable before its line?
`function foo() {}`	✅	The whole function	✅ Yes
`var x`	✅	`undefined`	⚠️ Yes, but it's `undefined`
`let` / `const`	✅	Uninitialized (in the TDZ)	❌ `ReferenceError`
`class Foo {}`	✅	Uninitialized (in the TDZ)	❌ `ReferenceError`

Function declarations: fully hoisted

sayHi(); // "Hi there!" ✅ works before the declaration

function sayHi() {
  console.log("Hi there!");
}

The entire function, body included, is stored during the creation phase. That's why it's callable from anywhere in its scope.

`var`: hoisted, but only the name

console.log(coffee); // undefined (not an error!)
var coffee = "espresso";
console.log(coffee); // "espresso"

JS sees var coffee, creates the variable, and sets it to undefined. The = "espresso" part only happens during execution. Behind the scenes it's like this:

var coffee;            // creation phase: declared, value is undefined
console.log(coffee);   // undefined
coffee = "espresso";   // execution phase: assignment

`let` and `const`: hoisted, but locked (the Temporal Dead Zone)

Plain-English version of the Temporal Dead Zone (TDZ):

Imagine a restaurant reserves a table with your name on it. The table exists, but you can't sit down until your party arrives. Touch it early and the staff yells at you.

For let and const, the variable is registered in the creation phase, but it stays off-limits until execution reaches its declaration line. The stretch between the start of the scope and that line is the Temporal Dead Zone.

console.log(tea); // ❌ ReferenceError: Cannot access 'tea' before initialization
let tea = "green";
console.log(tea); // "green" ✅

The error message says "cannot access before initialization", not "tea is not defined". That's proof tea was hoisted. JS knows about it but refuses to let you touch it yet.

scope starts
   │   ← TDZ: `tea` exists but is untouchable
   │
let tea = "green";   ← TDZ ends here
   │   ← safe to use

Gotchas that show up in interviews 🎯

Gotcha #1: Function expressions are NOT hoisted like declarations

greet(); // ❌ TypeError: greet is not a function

var greet = function () {
  console.log("Hello!");
};

Only the variable greet is hoisted (as undefined). Calling undefined() gives you a TypeError. With let/const you'd get a ReferenceError instead.

Gotcha #2: The classic var in a loop

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// Prints: 3, 3, 3 😱

var is function-scoped, so there's one shared i. By the time the timeouts fire, the loop is finished and i is 3. Swap in let and each iteration gets its own i:

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// Prints: 0, 1, 2 ✅

Gotcha #3: Function declarations beat var on priority

console.log(typeof thing); // "function"

var thing = "I'm a string";
function thing() {}

Function declarations win during the creation phase, so thing starts as a function. The var assignment only overwrites it later, during execution.

💡 Rule of thumb: Use const by default, let when you need to reassign, and skip var. The TDZ is a feature. It turns silent bugs into loud errors.

2. Objects & References: Boxes vs. Address Labels

Object literal basics

An object is a bundle of key-value pairs. The literal syntax is the quickest way to make one:

const dev = {
  name: "Ada",                    // property
  skills: ["JS", "CSS"],          // properties can hold any type
  greet() {                       // method shorthand (ES6)
    return `Hi, I'm ${this.name}`;
  },
};

console.log(dev.name);        // "Ada" (dot notation)
console.log(dev["skills"]);   // ["JS", "CSS"] (bracket notation)

Primitives vs. references

JavaScript has two families of values:

Primitives: string, number, boolean, null, undefined, symbol, bigint
Objects (which include arrays and functions)

They behave very differently when copied.

Primitives are copied by value. You get an independent copy:

let a = 10;
let b = a;   // b gets its own copy of 10
b = 99;

console.log(a); // 10 ✅ untouched

Objects are copied by reference. You copy the address, not the object:

const original = { score: 10 };
const copy = original;   // copies the reference (address), NOT the object
copy.score = 99;

console.log(original.score); // 99 😱 same object!

Here's the picture:

PRIMITIVES                       OBJECTS

 a ─► [ 10 ]                     original ──┐
 b ─► [ 99 ]   (separate boxes)             ├──► { score: 99 }  (one object)
                                 copy ──────┘   (two labels, same address)

Think of it this way:

A primitive variable holds the value itself. An object variable holds a sticky note with an address. Copying the variable copies the sticky note, not the house.

Things this explains

const doesn't make objects immutable. It locks the variable's binding (the sticky note), not the object's contents:

const user = { name: "Ada" };
user.name = "Grace";   // ✅ allowed: we mutated the object
user = {};             // ❌ TypeError: can't reassign the binding

Objects compare by reference, not by content:

console.log({ a: 1 } === { a: 1 }); // false: two different objects
const x = { a: 1 };
const y = x;
console.log(x === y);               // true: same address

Want a real copy? Spread it (shallow) or use structuredClone (deep):

const clone = { ...original };                // new object, same top-level values
const deepClone = structuredClone(original);  // modern deep copy

3. Enter `this`: The Shapeshifter 🎭

Here's the sentence to tattoo on your brain:

this is NOT determined by where a function is written. It's determined by how the function is called, at the call-site.

Same function, different call, different this. There are four binding rules, plus one exception (arrow functions).

Rule 1: Default binding (the "nobody owns this call" rule)

A plain function call with no object in front of it:

"use strict";

function whoAmI() {
  console.log(this);
}

whoAmI(); // undefined (strict mode / modules)

In non-strict code, this falls back to the global object (window in browsers, globalThis elsewhere). That's how accidental globals happen. ES modules and classes are strict by default, so you'll usually get undefined, which fails loudly.

Rule 2: Implicit binding (the "dot rule")

If a function is called with an object in front of it, this is that object:

const dev = {
  name: "Ada",
  hi() {
    console.log(`Hi, I'm ${this.name}`);
  },
};

dev.hi(); // "Hi, I'm Ada"  ← `dev` is left of the dot, so this === dev

Quick trick: look left of the dot at the call-site. That's your this.

The classic trap: the lost this

const hi = dev.hi;   // we grabbed the function and detached it from `dev`
hi();                // ❌ "Hi, I'm undefined" (default binding kicks in!)

The function is identical, but the call-site changed from dev.hi() to a bare hi(). This is why passing methods as callbacks (setTimeout(dev.hi, 100)) breaks so often.

Rule 3: Explicit binding (`call`, `apply`, `bind`)

Don't like what this is? Tell JS what it should be.

function intro(role, company) {
  console.log(`${this.name}, ${role} @ ${company}`);
}

const ada = { name: "Ada" };

// call: invoke now, arguments listed one by one
intro.call(ada, "Engineer", "Analytical Inc.");

// apply: invoke now, arguments in an array
intro.apply(ada, ["Engineer", "Analytical Inc."]);

// bind: DON'T invoke, return a NEW function with `this` locked in
const adaIntro = intro.bind(ada, "Engineer");
adaIntro("Analytical Inc."); // "Ada, Engineer @ Analytical Inc."

Memory hook: Call = Comma-separated args. Apply = Array. Bind = Builds a new function for later.

Bind fixes the lost this problem from above:

const safeHi = dev.hi.bind(dev);
safeHi(); // "Hi, I'm Ada" ✅

Rule 4: `new` binding

Call a function with new and this becomes a brand-new object. We'll dig into that in the next section. 👇

Which rule wins when several apply?

1. new binding       ← strongest
2. explicit binding  (call / apply / bind)
3. implicit binding  (obj.method())
4. default binding   ← weakest fallback

The exception: arrow functions and lexical `this`

Arrow functions don't have their own this. They borrow it from the surrounding scope where they were written. That's what "lexical this" means.

const timer = {
  seconds: 0,
  start() {
    // `this` here is `timer` (implicit binding)
    setInterval(() => {
      this.seconds++;            // ✅ arrow inherits `this` from start()
      console.log(this.seconds);
    }, 1000);
  },
};

timer.start();

With a regular function () {} inside setInterval, this would be lost (default binding). The arrow function solves that.

But don't use arrows as object methods:

const broken = {
  name: "Ada",
  hi: () => console.log(this.name), // ❌ `this` is NOT `broken`; it's the outer scope's this
};

Arrow functions also ignore call, apply, and bind for this, and they can't be used with new.

🧠 Cheat sheet: Regular function? Look at the call-site. Arrow function? Look at where it was written.

4. Constructor Functions & the `new` Keyword 🏭

Why did we need constructor functions?

Before ES6 class, suppose you needed 100 similar objects. Copy-pasting object literals gets old fast:

const dev1 = { name: "Ada", role: "Engineer" };
const dev2 = { name: "Grace", role: "Admiral" };
// ...98 more. Nope.

The pre-ES6 answer was the constructor function: a regular function that acts as a blueprint, by convention capitalized, and called with new:

function Developer(name, role) {
  this.name = name;   // `this` will be the new object
  this.role = role;
}

const ada = new Developer("Ada", "Engineer");
console.log(ada); // Developer { name: 'Ada', role: 'Engineer' }

(ES6 class is mostly friendlier syntax on top of this same machinery, so understanding it here pays off.)

What `new` does: the 4 steps

When you write new Developer("Ada", "Engineer"), JavaScript does this:

   new Developer("Ada", "Engineer")
            │
            ▼
 ┌────────────────────────────────────────────────┐
 │ STEP 1  Create a brand-new empty object   {}   │
 ├────────────────────────────────────────────────┤
 │ STEP 2  Link its prototype:                    │
 │         obj.__proto__ = Developer.prototype    │
 ├────────────────────────────────────────────────┤
 │ STEP 3  Run Developer with `this` = that obj   │
 │         (the new binding rule!)                │
 ├────────────────────────────────────────────────┤
 │ STEP 4  Return the object (unless the function │
 │         explicitly returns a different object) │
 └────────────────────────────────────────────────┘

Don't take my word for it: build `new` yourself

function myNew(Constructor, ...args) {
  // STEP 1 + 2: create an empty object linked to the constructor's prototype
  const obj = Object.create(Constructor.prototype);

  // STEP 3: run the constructor with `this` bound to our new object
  const result = Constructor.apply(obj, args);

  // STEP 4: return the object (or an object the constructor returned explicitly)
  const returnedAnObject =
    (typeof result === "object" && result !== null) ||
    typeof result === "function";
  return returnedAnObject ? result : obj;
}

Now test it against the real thing:

function Developer(name, role) {
  this.name = name;
  this.role = role;
}

// Methods go on the prototype so ALL instances share ONE copy
Developer.prototype.intro = function () {
  return `${this.name} the ${this.role}`;
};

const real = new Developer("Ada", "Engineer");
const fake = myNew(Developer, "Grace", "Admiral");

console.log(real.intro());                        // "Ada the Engineer"
console.log(fake.intro());                        // "Grace the Admiral"
console.log(fake instanceof Developer);           // true
console.log(Object.getPrototypeOf(fake) === Developer.prototype); // true

Same behavior from about 8 lines of code. That's all new is doing.

Why put methods on the prototype?

function Bad(name) {
  this.name = name;
  this.hi = function () {};   // ❌ a NEW function copy for every instance
}

function Good(name) {
  this.name = name;
}
Good.prototype.hi = function () {}; // ✅ one shared function, all instances link to it

When you call ada.intro(), JS looks on ada first, doesn't find it, then follows the prototype link to Developer.prototype. That lookup chain is the prototype chain.

The #1 constructor bug: forgetting `new`

const oops = Developer("Ada", "Engineer"); // 😬 no `new`!

Without new, this is a plain function call, so default binding applies. In sloppy mode, this is the global object and you just polluted window.name. In strict mode you get a TypeError. That's one more reason to write strict code, or to use class, which throws if you forget new.

5. Putting It All Together: 10 Lines, 4 Concepts

"use strict";
console.log(typeof Dev);                   // "function" → hoisting: whole function registered early
function Dev(name) { this.name = name; }   // constructor: `this` = new object when called with `new`
Dev.prototype.hi = function () { return `Hi, ${this.name}`; }; // shared method via prototype
const ada = new Dev("Ada");                // new: create → link prototype → bind this → return
const team = { lead: ada };                // object literal holding a *reference* to ada
console.log(team.lead === ada);            // true → same address, not a copy
console.log(ada.hi());                     // "Hi, Ada" → implicit binding (left of the dot)
console.log(ada.hi.call({ name: "Grace" })); // "Hi, Grace" → explicit binding overrides `this`
const loose = ada.hi; try { loose(); } catch { console.log("this got lost 💥"); } // default binding

Count them: hoisting (line 2), new binding (line 5), references (lines 6–7), implicit (line 8), explicit (line 9), and default binding (line 10, where strict mode makes it fail loudly).

Wrap-Up 🎁

Here's the whole article in five bullets:

Hoisting is the creation phase registering declarations before execution. Functions are fully hoisted, var starts as undefined, and let/const sit in the TDZ until their line runs.
Objects are references. Copying an object variable copies the address, not the object. const locks the binding, not the contents.
this is decided at the call-site, in this order: new → explicit (call/apply/bind) → implicit (obj.method()) → default.
Arrow functions have no this of their own and use the surrounding one. Great for callbacks, bad for object methods.
new creates an object, links its prototype, binds this, and returns it. It's four steps, no magic.

💬 Your turn!

I'd love to hear from you in the comments:

What's the weirdest this or hoisting bug you've ever hit in production? Bonus points if it took you more than an hour to find. 😅

And if you're prepping for interviews, drop the JS concept that still trips you up, and we can tackle it together in a follow-up post.

Happy coding! 🚀

JavaScript & CS Execution Internals: A Deep Dive

Surya Kanth — Mon, 28 Sep 2026 11:44:58 +0000

Part 1 — Execution Architectures: Interpreters, Compilers, and JIT

JavaScript engines pick a point on a spectrum: interpret everything for fast startup, compile everything ahead of time for fast steady-state speed, or do both with a JIT that promotes hot code as it runs.

Three foundational models

Pure interpreter — parses source to an AST (or a simple bytecode) and walks it node by node at run time. No machine code is ever produced; every operation re-dispatches through the interpreter's switch loop.
Ahead-of-time (AOT) compiler — runs the full pipeline before execution: lexing → AST → semantic analysis → intermediate representation (IR) → optimization passes → target machine code. The binary that ships is already native code.
JIT (hybrid) — starts by interpreting (or running a fast baseline compile) so the program starts immediately, then profiles which functions run often ("warm"/"hot"), recompiles just those into optimized machine code, and can de-optimize (bail out) back to a slower tier if an assumption the optimizer made turns out to be wrong.

Model	How code runs	Startup latency	Peak throughput	Typical example
Pure interpreter	AST/bytecode walked live	Lowest	Lowest	Early Ruby MRI, shell scripts
AOT compiler	Native machine code from disk	Highest (compile first)	Highest, consistent	C, Rust, Go
JIT hybrid	Interpret → profile → compile hot paths	Low	High after warm-up	V8 (JS), JVM, .NET CLR

flowchart TD
 subgraph AOT["Pure AOT Compiler"]
 A1[Source] --> A2[Lex/Parse to AST] --> A3[Semantic Analysis] --> A4[IR + Optimization] --> A5[Native Machine Code] --> A6[Run at full speed]
 end
 subgraph INT["Pure Interpreter"]
 B1[Source] --> B2[Parse to AST] --> B3[Walk AST / dispatch loop] --> B4[Re-walked every call]
 end
 subgraph JIT["V8 Multi-Tier JIT"]
 C1[Source] --> C2[Parser: AST]
 C2 --> C3[Ignition: Bytecode Interpreter]
 C3 -- warm --> C4[Sparkplug: Baseline Compiler]
 C4 -- hotter --> C5[Maglev: Mid-tier Optimizer]
 C5 -- hottest --> C6[TurboFan: Optimizing Compiler]
 C6 -- assumption broken --> C3
 end

Reading it: AOT pays the compile cost once, before the user ever sees output. A pure interpreter pays a re-dispatch cost on every single execution. V8's JIT tries to get both — cheap startup from Ignition, native speed from TurboFan for code that's actually worth optimizing — and TurboFan can hand control back to Ignition (de-opt) if a hot function starts seeing shapes/types it didn't expect.

V8's multi-tier pipeline

Parser — produces an AST; a pre-parser skips function bodies not yet needed (lazy parsing) to keep startup fast.
Ignition — a register-based bytecode interpreter. Every function starts here. Cheap to enter, slow to run repeatedly.
Sparkplug — a non-optimizing baseline compiler. Once a function is called enough to be "warm," V8 compiles its bytecode almost 1:1 into machine code — no deep analysis, just removing interpreter dispatch overhead.
Maglev — a mid-tier optimizing compiler (shipped in recent V8) that does real optimization (type feedback, inlining) but compiles fast, sitting between Sparkplug's cheapness and TurboFan's aggressiveness.
TurboFan — the top-tier optimizing compiler for genuinely hot functions. Uses collected type feedback (inline caches) to speculate — e.g., "this property access always hits the same object shape" — and emits tightly optimized machine code. If a speculative assumption is violated (a new shape appears, a value's type changes), V8 de-optimizes: it throws away the optimized code and falls back to Ignition/Sparkplug, recollecting feedback before trying to re-optimize.

// Inline caching + deopt, illustrated
function getX(obj) {
  return obj.x; // TurboFan inlines this once it sees only one "shape" of obj
}

for (let i = 0; i < 100000; i++) {
  getX({ x: i, y: 0 }); // consistent shape -> monomorphic -> gets optimized
}

getX({ y: 0, x: 99 });
// property order differs -> different hidden class/shape
// -> inline cache goes "polymorphic", TurboFan may de-optimize getX
// back to Ignition until it re-learns the new shape's feedback

Takeaway: the same JS source can run through four different "engines" over its lifetime — which is why microbenchmarks that only run a loop a few times can be measuring Ignition, not TurboFan.

Part 2 — Type Systems: Static vs. Dynamic, Strong vs. Weak

Two independent questions get conflated constantly: when are types checked (static = compile time, dynamic = run time), and how strictly are mismatched types tolerated (strong = errors/refuses, weak = silently coerces).

The typing matrix

Language	Check timing	Coercion strictness	Cell
JavaScript	Dynamic	Weak	`"5" + 3 === "53"`, `"5" - 3 === 2`
Python	Dynamic	Strong	`"5" + 3` raises `TypeError`
C++	Static	Weak	implicit `int`→`float`, pointer arithmetic
Java	Static	Strong	no silent numeric-to-string coercion
TypeScript	Static (erased at runtime)	Strong at compile time, weak at runtime	compiler blocks `"5" + 3` mismatches; compiled JS still coerces

flowchart LR
 subgraph Timing
 direction TB
 ST[Static: checked at compile time]
 DY[Dynamic: checked at run time]
 end
 subgraph Strictness
 direction TB
 SW[Weak: silently coerces]
 SS[Strong: refuses mismatches]
 end
 ST --- SS --- Java[Java]
 ST --- SW --- Cpp[C++]
 DY --- SS --- Python[Python]
 DY --- SW --- JS[JavaScript]
 ST -.compiles to.-> DY
 TS[TypeScript] -. static + strong, erased .-> JS

TypeScript sits diagonally from JS: it adds static, strong checking on top, but the checks vanish at compile-out — the emitted JS is exactly as dynamic and weak as ever.

Memory & engine implications

Static typing lets the compiler commit to a memory layout before the program runs; dynamic typing forces the engine to keep re-discovering the "shape" of a value while it runs.

Static (e.g. a C struct) — fields sit at fixed, known byte offsets in contiguous memory. Primitives are unboxed (an int is 4 raw bytes, not a pointer to an object). The CPU can prefetch and cache this layout efficiently.
Dynamic (e.g. a JS object) — values are commonly boxed (wrapped in a heap object carrying a type tag) and accessed through tagged pointers; numbers may use NaN-boxing (packing a float or a pointer into the unused bit patterns of a 64-bit NaN) to avoid allocating a box for every number. V8 recovers some of static typing's speed with hidden classes / shapes: objects with the same property names, in the same insertion order, share one hidden class, so property lookup can become an offset lookup instead of a hash-map lookup — until a shape diverges.

STATIC: struct Point { int x; int y; };
┌──────────┬──────────┐
│ x: 4B    │ y: 4B    │  <- one contiguous stack/struct slot, fixed offsets
└──────────┴──────────┘

DYNAMIC: const p = { x: 1, y: 2 };
stack slot ──▶ [ tagged pointer ] ──▶ HEAP: [ hidden-class ptr | x slot | y slot ]
                                                     │
                                                     ▼
                                        HiddenClass{ x:offset0, y:offset1 }

Reading it: a static struct is data, in place. A dynamic object is a pointer to data, plus a separate description of what that data means — one extra hop, paid on every property access, that engines fight to eliminate with hidden classes and inline caches.

// Hidden-class divergence in practice
const a = { x: 1, y: 2 };
const b = { x: 1, y: 2 };      // same shape as a -> shares a hidden class

const c = { y: 2, x: 1 };      // different insertion order -> DIFFERENT hidden class

delete a.y;                    // mutating shape after creation -> a gets its own
                                // new (slower, dictionary-mode-prone) hidden class

Part 3 — Variable Declaration & Scope: `var` vs. `let` vs. `const`

Scope granularity

Scope	Created by	Example
Global	Top-level of a script	`var x = 1;` outside any function
Function	Any function body	`var` inside `function f(){}`
Block	`{ }`, `if`, `for`, `while`	`let`/`const` inside `{ }`
Module	ES module file	top-level `let` in a `.mjs`/`type="module"` file — not attached to `globalThis`

var only respects function/global scope; let/const respect block scope.

The variable lifecycle

The engine processes a scope in two conceptual passes: it first walks the code to register every declaration in the environment (LexicalEnvironment for let/const/classes, VariableEnvironment for var/function declarations), then executes statements top to bottom, initializing and later assigning values.

stateDiagram-v2
 [*] --> Unregistered
 state "var path" as VarPath {
 Unregistered --> Registered_Initialized_Undefined: creation phase\n(hoisted + auto-initialized to undefined)
 Registered_Initialized_Undefined --> Assigned: execution reaches `x = value`
 }
 state "let/const path" as LetPath {
 Unregistered --> TDZ: creation phase\n(hoisted, NOT initialized)
 TDZ --> Initialized: execution reaches the `let`/`const` line
 Initialized --> Assigned: `let` only — `const` is initialized+assigned together
 }
 Assigned --> [*]

Reading it: var is hoisted AND pre-filled with undefined, so reading it early gives undefined, not an error. let/const are hoisted but left in the **Temporal Dead Zone* — reading them before their own declaration line throws ReferenceError, because they exist but aren't initialized yet.*

console.log(a); // undefined — hoisted + auto-initialized (var)
var a = 1;

console.log(b); // ReferenceError: Cannot access 'b' before initialization
let b = 2;       // TDZ ends exactly here

Practical traps

Global object leakage — an un-declared assignment (x = 5 with no var/let/const, outside strict mode) creates a property on globalThis/window. var at the top level also adds a property to globalThis; top-level let/const do not.
The async for-loop trap — classic interview question:

// var: ONE shared binding across all iterations
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0); // logs 3, 3, 3
}

// let: a FRESH lexical binding created per iteration
for (let j = 0; j < 3; j++) {
  setTimeout(() => console.log(j), 0); // logs 0, 1, 2
}

// pre-ES6 fix: force a new scope per iteration with an IIFE
for (var k = 0; k < 3; k++) {
  (function (frozenK) {
    setTimeout(() => console.log(frozenK), 0); // logs 0, 1, 2
  })(k);
}

With var, every closure captures the same variable, whose final value (3) is what all three callbacks see after the loop finishes. let creates a new binding on each iteration, so each closure captures its own snapshot. The IIFE pattern manufactures that same per-iteration binding manually, by passing k as a function argument that gets its own scope on each call.

Part 4 — Runtime Type Inspection: `typeof` and Beyond

The spec return values

typeof returns exactly one of eight strings: "undefined", "boolean", "number", "string", "bigint", "symbol", "object", "function".

The null bug — typeof null === "object". This is a famous historical artifact: early JS engines tagged values with a type bitmask in the low bits of the value's representation, and the tag for "object" happened to be 000, the same bits as the null pointer. null was never actually an object; the tag check just couldn't tell the difference, and the behavior shipped and then had to stay for compatibility forever.
Undeclared vs. TDZ — typeof is specifically safe to call on a variable that was never declared at all (returns "undefined", no error) — but calling it on a let/const that's declared later in the same scope throws, because the TDZ check happens before typeof's usual "don't throw" special-casing gets a chance:

typeof neverDeclared;      // "undefined" — no ReferenceError

typeof inTDZ;               // ReferenceError: Cannot access 'inTDZ' before initialization
let inTDZ = 5;

Limitations of `typeof` / `instanceof`

typeof collapses every object type — arrays, dates, regexes, plain objects, null — into "object". It cannot distinguish them.
instanceof walks the prototype chain, so it breaks across realms: an array created in an <iframe> fails arr instanceof Array in the parent window, because each realm has its own Array.prototype.

Reliable alternatives

Need	Tool	Example
Precise built-in tag, cross-realm safe	`Object.prototype.toString.call(x)`	`Object.prototype.toString.call([]) === "[object Array]"`
Is it specifically an array?	`Array.isArray(x)`	Works across realms, unlike `instanceof Array`
Custom/branded shape check	User-defined type guard	`function isUser(x) { return x != null \&\& typeof x.id === "string"; }`

flowchart TD
 Start["What are you checking?"] --> Q1{"Primitive?\n(number/string/boolean/\nundefined/symbol/bigint)"}
 Q1 -- yes --> UseTypeof["Use typeof"]
 Q1 -- no, it's an object --> Q2{"Need to know if it's\nspecifically an Array?"}
 Q2 -- yes --> UseIsArray["Use Array.isArray(x)"]
 Q2 -- no --> Q3{"Need the exact built-in kind\n(Object/Date/RegExp/Map...)?"}
 Q3 -- yes --> UseToString["Use Object.prototype.toString.call(x)"]
 Q3 -- no --> Q4{"Checking your OWN class,\nsame realm guaranteed?"}
 Q4 -- yes --> UseInstanceof["instanceof is fine here"]
 Q4 -- no / cross-realm risk --> UseGuard["Write a custom type guard\n(duck-type on known shape)"]

Rule of thumb: reach for typeof on primitives, Array.isArray for arrays specifically, Object.prototype.toString.call when you need the precise built-in kind of any object, and a hand-written guard when checking your own data shapes across possible realm boundaries.

Part 5 — Functions: First-Class Citizens & Execution Context

First-class status

Functions are ordinary values in JS: they can be assigned to variables, passed as arguments (callbacks), returned from other functions, and stored in data structures. A higher-order function is simply one that takes or returns another function (Array.prototype.map, setTimeout).

Function forms & spec differences

Form	Hoisted with body?	Has own `this`	Has `arguments`	`[[Construct]]` (usable with `new`)
Declaration `function f(){}`	Yes	Yes (dynamic)	Yes	Yes
Expression `const f = function(){}`	No (var-hoisted as `undefined` if `var`)	Yes (dynamic)	Yes	Yes (if named/non-arrow)
Arrow `const f = () => {}`	No	No — inherits lexically from enclosing scope	No — must use rest params `...args`	No — throws `TypeError`

Every callable object internally has a [[Call]] slot (invoked as f()) and, for constructible functions, a [[Construct]] slot (invoked as new f()). Arrow functions are [[Call]]-only.
new.target is set to the constructor when a function is invoked via new, and undefined otherwise — the standard way to detect "was I called as a constructor?"
Arrow functions bind this lexically at definition time (from the enclosing scope) rather than dynamically at call time, which is precisely why they're preferred for callbacks that need to preserve an outer this.

function RegularCounter() {
  this.count = 0;
  setTimeout(function () {
    this.count++; // `this` here is NOT the RegularCounter instance
  }, 100);        // (it's undefined in strict mode, or the global object otherwise)
}

function ArrowCounter() {
  this.count = 0;
  setTimeout(() => {
    this.count++; // arrow inherits `this` from ArrowCounter's own scope — works
  }, 100);
}

Execution context & the scope chain

Every function call pushes a new execution context onto the call stack, holding an Environment Record (the modern name for what used to be called the Activation Object) — the live bindings for that call's parameters and local variables. Each context also keeps a reference to its outer environment, forming the scope chain used to resolve free variables.

flowchart TD
 subgraph Stack["Call Stack (LIFO)"]
 direction TB
 CS3["outer() context\n(Environment Record: count)"]
 CS4["inner() context — pushed on call,\npopped when inner() returns"]
 end
 subgraph Heap["Heap"]
 direction TB
 H1["outer's Environment Record\n(kept ALIVE by closure reference,\neven after outer()'s stack frame is popped)"]
 H2["inner (the returned function)\n[[Environment]] --> points to H1"]
 end
 CS3 -.captured by.-> H1
 H2 -- "[[Environment]] link" --> H1
 CS4 -."is a call to".-> H2

function outer() {
  let count = 0;               // lives in outer()'s Environment Record
  function inner() {
    count++;                   // resolved via the scope chain -> outer's record
    return count;
  }
  return inner;                 // inner "closes over" outer's environment
}

const counter = outer();        // outer()'s STACK frame is popped here...
console.log(counter());         // ...but its Environment Record survives on the
console.log(counter());         // HEAP, kept alive because inner still references it
// logs: 1, 2

Reading it: outer()'s stack frame is torn down the moment it returns — that's normal stack discipline. But its Environment Record isn't stack-allocated; it's a heap object. As long as something reachable (here, inner's hidden [[Environment]] slot) still points to it, the garbage collector can't reclaim it — which is exactly what makes a closure work, and exactly why closures over large objects can quietly leak memory if the closure outlives its usefulness. Modern engines mitigate this with **ephemeron-like GC semantics: an environment record is only kept alive by references that are themselves reachable, so a closure retaining an unreachable object doesn't artificially keep that object alive forever once nothing else can reach the closure either — but a *long-lived closure (e.g. stored in a global cache) will keep everything in its scope chain alive for as long as it exists.*

JavaScript Data Types

Surya Kanth — Fri, 25 Sep 2026 06:37:48 +0000

PART 1: ARCHITECTURAL OVERVIEW

1.1 Primitive vs Reference Types

Primitives are immutable, fixed-size (or engine-optimized) values stored directly where the variable binding lives — conceptually the stack (execution context's variable environment). Objects are mutable, variable-size structures stored on the heap; the variable binding holds a pointer to that heap location.

This is NOT pass-by-reference in the C++/Pascal sense. JS is strictly call-by-value, but for objects, the value being copied is the reference itself — this hybrid model is called call-by-sharing.

function mutate(obj) { obj.x = 99; }      // mutates shared heap object
function reassign(obj) { obj = { x: 0 }; } // rebinds LOCAL copy of pointer only

let o = { x: 1 };
mutate(o);    console.log(o.x); // 99 — heap object was mutated
reassign(o);  console.log(o.x); // still 99 — only the local pointer changed

STACK FRAME                    HEAP
┌─────────────┐
│ o  ──────────┼───────────►  ┌─────────┐
└─────────────┘               │ { x: 1 }│
                               └─────────┘
call mutate(o):
┌─────────────┐
│ obj ─────────┼───────────►  (SAME heap object — pointer copied by value)
└─────────────┘               obj.x = 99 mutates it directly

call reassign(o):
┌─────────────┐
│ obj ─────────┼───────────►  new { x: 0 }  (local pointer redirected,
└─────────────┘                              original o's pointer unchanged)

1.2 Dynamic & Weak Typing

JS resolves types at runtime, not compile time (dynamic typing), and permits implicit conversions between incompatible types (weak typing). Internally, V8 tags every value with a type identifier embedded in the low bits of the value's machine-word representation (see §Number internals below) — this tag is what typeof and internal abstract operations inspect to dispatch behavior.

1.3 Complete Type System — ASCII Architecture Diagram

                              ┌────────────────────┐
                              │   JavaScript Value  │
                              └──────────┬───────────┘
                    ┌──────────────────────┴──────────────────────┐
                    ▼                                               ▼
          ┌─────────────────┐                             ┌──────────────────┐
          │    PRIMITIVE     │                             │   OBJECT (ref)    │
          │ (stack, by value)│                             │ (heap, by pointer)│
          └────────┬─────────┘                             └─────────┬─────────┘
     ┌─────┬───────┼───────┬──────┬────────┬────────┐                │
     ▼     ▼       ▼       ▼      ▼        ▼         ▼        ┌───────┴────────┐
 undefined null  boolean number bigint   string    symbol     ▼                ▼
                                                          Plain Object    Exotic Object
                                                          {}, Object()   Array, Function,
                                                                         Date, RegExp,
                                                                         Map/Set/WeakMap,
                                                                         ArrayBuffer,
                                                                         TypedArrays, Error

PART 2: PRIMITIVE TYPES

2.1 `undefined`

Definition: The default value of any binding that has been declared but not assigned; also the implicit return value of functions with no return statement, and the value of missing object properties / array holes.

Memory: A single, unique, engine-internal sentinel value — no heap allocation. In V8 it's represented as a special tagged pointer (the "oddball" undefined).

Syntax & traps:

let x;
console.log(x);              // undefined

function f() {}
console.log(f());            // undefined

let obj = {};
console.log(obj.missing);    // undefined — property doesn't exist

let arr = [1, , 3];          // sparse array
console.log(arr[1]);         // undefined (a "hole", not literally stored)

Temporal Dead Zone (TDZ): let/const bindings exist in scope from the start of the block but are uninitialized until their declaration line executes. Accessing them before that throws — this is different from undefined.

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

Global undefined vs shadowing: undefined is a non-writable, non-configurable global property in strict mode (ES5+), but it is still just an identifier — it can theoretically be shadowed as a local variable name or function parameter in sloppy mode (not recommended, and disallowed for the global itself since ES5).

ASCII diagram — TDZ vs undefined:

Scope entry:  [ a: <uninitialized> ]  ← accessing throws ReferenceError
let a = 5;    [ a: 5 ]                ← now readable
              (contrast with var, which is [ a: undefined ] from scope entry)

Pitfalls: typeof undeclaredVar returns "undefined" (no error) — but accessing undeclaredVar directly throws ReferenceError. typeof is the one safe way to probe for existence without a prior declaration.

2.2 `null`

Definition: Represents an intentional, explicit absence of any object value — assigned by the developer, never implicitly by the engine (contrast with undefined).

The typeof null === "object" bug: This is a legacy artifact from the original 1995 JS implementation. Values were represented as a 32-bit word: a small type tag (1–3 bits) plus a payload. Objects were tagged 000. null was represented as the all-zero machine word (essentially a null pointer, 0x00) — which incidentally also carries the 000 object tag pattern. typeof inspects this tag, sees 000, and reports "object". It's a bitmask collision, not a design decision, and it's permanently frozen into the spec for backward compatibility.

null's internal word:     0x00000000
Object tag pattern:       000 (lowest bits)
                           └── null's all-zero bits ACCIDENTALLY match this tag

Equality quirks:

null == undefined;   // true  — special-cased loose equality rule
null === undefined;  // false — different types
null == 0;            // false — null does NOT coerce to 0 in ==
null >= 0;            // true  — relational operators DO convert null to 0 first

This asymmetry (== treats null specially but relational operators convert it numerically) is a frequently-tested interview edge case.

2.3 `Boolean`

Definition: Logical binary type, true/false, used for control flow and boolean logic.

Truthy/Falsy table (complete, no omissions):

FALSY (exactly 8 values in JS):
false, 0, -0, 0n (BigInt zero), "", null, undefined, NaN

TRUTHY: literally everything else, including:
"0", "false", [], {}, function(){}, new Boolean(false)

new Boolean(false) is truthy because it's an object, not a primitive — objects are always truthy regardless of their wrapped content.

Short-circuiting (returns operand values, not necessarily booleans):

console.log(0 || "default");      // "default"  (returns the value, not `true`)
console.log("" ?? "fallback");    // "fallback" — ?? only checks null/undefined, NOT falsy
console.log(0 ?? "fallback");     // 0 — 0 is not null/undefined, so ?? keeps it
console.log(user && user.name);   // guards against accessing .name on null/undefined

Bitwise tricks: ~~x (double bitwise NOT) truncates toward zero like Math.trunc for 32-bit-safe integers — a legacy micro-optimization, now discouraged in favor of Math.trunc.

2.4 `Number`

Definition: IEEE 754 double-precision (64-bit) floating point — the single numeric type for both integers and decimals prior to BigInt.

64-bit breakdown:

 63  62 ......... 52  51 ................................ 0
┌───┬──────────────┬──────────────────────────────────────┐
│ S │  Exponent(11) │           Mantissa (52 bits)          │
└───┴──────────────┴──────────────────────────────────────┘
  1 bit               11 bits                52 bits
Sign             Biased exponent          Fraction (significand)

value = (-1)^S × 1.Mantissa × 2^(Exponent - 1023)

The 52-bit mantissa is why Number.MAX_SAFE_INTEGER = 2^53 - 1 = 9007199254740991 — you get 53 bits of integer precision (52 stored + 1 implicit leading bit).

Number.MAX_SAFE_INTEGER      // 9007199254740991
9007199254740992 === 9007199254740993 // true! precision lost beyond this point
0.1 + 0.2                    // 0.30000000000000004 — classic float rounding error

+0 vs -0: Both compare equal with === but are distinguishable:

console.log(0 === -0);        // true
console.log(Object.is(0, -0)); // false — Object.is is the precise identity check
console.log(1 / 0);            // Infinity
console.log(1 / -0);           // -Infinity  ← reveals the sign bit difference

NaN mechanics: NaN is the IEEE 754 encoding where the exponent bits are all 1 and the mantissa is nonzero. Per spec, NaN !== NaN (it fails identity with itself by design, inherited from the IEEE standard so error-propagation is detectable).

NaN === NaN;          // false
Object.is(NaN, NaN);  // true — Object.is is the ONE correct way to test for NaN identity
Number.isNaN(NaN);    // true — reliable, unlike global isNaN() which coerces first
isNaN("hello");        // true — global isNaN coerces "hello" → NaN first (a trap)
Number.isNaN("hello"); // false — no coercion, so correctly says "not NaN, just not a number"

V8 internals — Smi vs HeapNumber: V8 doesn't box every number as a full 64-bit float. Small integers that fit in 31 bits (on 32-bit systems) or similar ranges are stored as Smi (Small Integer) — packed directly into the pointer-sized word with a tag bit, avoiding heap allocation entirely. Numbers exceeding that range, or requiring float precision, are boxed as a HeapNumber — an actual heap-allocated 64-bit double.

Smi (tagged, no heap alloc):     [ 31-bit integer value | tag=0 ]
HeapNumber (heap allocated):     pointer ──► [ 64-bit IEEE 754 double ]

This is a major reason integer-heavy V8 code is fast — most everyday loop counters never touch the heap.

2.5 `BigInt`

Definition: Arbitrary-precision integer type (ES2020) for values exceeding Number's safe integer range, represented internally as a sign plus a digit array (not IEEE 754 at all).

const big = 9007199254740993n;          // 'n' suffix required
const big2 = BigInt("9007199254740993"); // function form
console.log(big + 1n);                    // 9007199254740994n — exact, no precision loss

Why mixing throws: Number and BigInt have fundamentally incompatible internal representations (IEEE 754 float vs arbitrary-precision integer array); implicit coercion between them would silently lose precision in one direction, so the spec forbids it outright rather than guessing:

10n + 5;         // TypeError: Cannot mix BigInt and other types
10n + BigInt(5); // 15n — must explicitly convert
10n == 10;        // true — loose equality DOES allow comparison (not arithmetic)
10n === 10;       // false — different types

JSON quirk: JSON.stringify throws on BigInt values — there is no BigInt representation in the JSON spec:

JSON.stringify({ a: 10n }); // TypeError: Do not know how to serialize a BigInt
// Workaround: convert to string first, or supply a custom replacer function

Limitations: No support for decimals, no implicit conversion to/from Number in arithmetic, and Math object methods (Math.sqrt, etc.) don't accept BigInt.

2.6 `String`

Definition: Immutable sequence of UTF-16 code units representing text.

UTF-16 code units vs code points: JS strings are indexed by 16-bit code units, not by actual Unicode "characters" (code points). Characters outside the Basic Multilingual Plane (like many emoji) require a surrogate pair — two 16-bit units representing one code point.

const s = "😀";
console.log(s.length);          // 2 — two UTF-16 code units, not one character!
console.log([...s].length);     // 1 — spread iterates by code point (correct)
console.log(s[0]);              // an unpaired surrogate (broken glyph if rendered alone)

Immutability:

let s = "hello";
s[0] = "H";        // silently fails (no error in sloppy mode)
console.log(s);     // "hello" — unchanged
s = "H" + s.slice(1); // must create a NEW string

V8 internals — string representations:

┌─────────────────────────────────────────────────────┐
│ SeqString (flat)     — contiguous char buffer,        │
│                         used for short/simple strings │
│ ConsString (rope)    — a lazy concatenation:           │
│    ┌──────┐   ┌──────┐                                 │
│    │"foo" │ + │"bar" │   ← not merged until actually    │
│    └──────┘   └──────┘     read (e.g. indexed access)  │
│ SlicedString         — a view into a substring of      │
│                         another string (no copy)       │
└─────────────────────────────────────────────────────┘

Repeated += concatenation in a loop builds a deep ConsString tree; reading a character then forces "flattening" — a known performance trap in older engines (mitigated but still relevant for very hot loops).

String interning: String literals (and some computed strings) are deduplicated in a global string table — two identical literals often point to the exact same heap allocation, making === comparison on short strings effectively an O(1) pointer comparison rather than O(n) character comparison.

2.7 `Symbol`

Definition: A primitive representing a guaranteed-unique, immutable value, primarily used as non-colliding object property keys.

const s1 = Symbol("id");
const s2 = Symbol("id");
console.log(s1 === s2);   // false — always unique, description is just for debugging

Global registry via Symbol.for: Unlike Symbol(), Symbol.for(key) looks up (or creates) a symbol in a global, runtime-wide registry, so calls with the same key return the identical symbol:

const a = Symbol.for("app.id");
const b = Symbol.for("app.id");
console.log(a === b); // true — shared via the global symbol registry

Well-Known Symbols — engine hook points that let objects customize built-in language behavior:

class Range {
  constructor(a,b){ this.a=a; this.b=b; }
  [Symbol.iterator]() {           // powers for...of
    let cur = this.a, end = this.b;
    return { next: () => cur <= end ? {value: cur++, done:false} : {value:undefined, done:true} };
  }
  [Symbol.toPrimitive](hint) {    // powers +obj, `${obj}`, obj + ""
    if (hint === "number") return this.b - this.a;
    return `Range(${this.a}-${this.b})`;
  }
}
const r = new Range(1,3);
console.log([...r]);       // [1,2,3]
console.log(+r);            // 2 (uses "number" hint)
console.log(`${r}`);        // "Range(1-3)" (uses "string"/"default" hint)

Metadata / "private" property use case: Symbol keys are excluded from Object.keys, JSON.stringify, and for...in — making them useful for attaching metadata that shouldn't clutter normal enumeration (though true privacy is now handled better by #privateFields).

PART 3: STRUCTURAL / REFERENCE TYPES

3.1 `Object`

Definition: An unordered (well, insertion-ordered for string keys) collection of key-value pairs, the base structural type from which all other reference types derive.

Property descriptors — every property has a hidden descriptor, not just a value:

Object.defineProperty(obj, "x", {
  value: 1, writable: false, enumerable: false, configurable: false
});

Hidden classes / Shapes (V8 internals): V8 doesn't store objects as pure hash maps. Objects with the same property-addition order share a hidden class (Map/Shape), which records property-name-to-offset mappings. This lets V8 use fast, fixed in-memory slot offsets instead of hashing on every property access.

obj1 = {x:1, y:2}     obj2 = {x:3, y:4}
      │                       │
      └──────► SAME Hidden Class (Shape) ◄──────┘
               { x: offset 0, y: offset 1 }

obj3 = {y:1, x:2}   ← different insertion order
      │
      └──────► DIFFERENT Hidden Class (transition creates a NEW shape,
                                        de-optimizing polymorphic call sites)

Practical implication: always initialize object properties in the same order (ideally in the constructor) to keep V8 on the fast "monomorphic" path rather than falling into slower dictionary-mode lookups.

3.2 `Array`

Definition: An ordered, integer-indexed Object exotic subtype with a special length property that auto-updates.

Packed vs holey (V8 internals):

Packed (dense, fast):       [0]=1 [1]=2 [2]=3          ← contiguous, C-array-like storage
Holey (sparse, slow):       [0]=1        [2]=3          ← index 1 is a hole
                             internally falls back toward
                             dictionary-mode (hash map) storage

const arr = [1,2,3];      // PACKED_SMI_ELEMENTS — fastest
arr[10] = 99;               // creates a hole → HOLEY_ELEMENTS, slower iteration
delete arr[0];              // ALSO creates a hole — prefer arr.splice() instead

Mixing types also demotes the internal representation: [1,2,3] (all Smi) → push a float → PACKED_DOUBLE_ELEMENTS → push a string/object → PACKED_ELEMENTS (generic, boxed). Each demotion is one-directional and never upgrades back.

3.3 `Function`

Definition: A first-class, callable object — meaning functions are ordinary objects (can hold properties) that additionally carry two internal methods.

Internal slots:

[[Call]] — invoked when the function is called normally: f()
[[Construct]] — invoked when called with new: new F(). Only present on non-arrow "constructible" functions — arrow functions and methods lack [[Construct]], which is why new (() => {}) throws.

Closures & scope chain:

function makeCounter() {
  let count = 0;                 // captured in closure scope
  return function() { return ++count; };
}
const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2

Heap:
┌────────────────────┐
│ Closure Environment │  ← kept alive as long as returned function exists
│   count: 2           │     (garbage collector cannot reclaim it —
└──────────┬───────────┘      a common source of accidental memory retention)
           │
      returned function ──► references this environment record

3.4 `Date`, `RegExp`, `Error`

Date — internal state is a single 64-bit float: milliseconds since the Unix epoch (Jan 1, 1970 UTC). All getters (getFullYear(), etc.) derive from this one timestamp plus timezone offset calculation at read time.
RegExp — internal state includes the pattern string, flags, and (for global/sticky regexes) a lastIndex slot that persists mutable state across .exec() calls — a well-known gotcha when reusing a global regex object across iterations.
Error — internal slots for message, name, and (non-standard but universal) stack, captured synchronously at construction time via the engine's call-stack unwinding mechanism.

3.5 Keyed Collections: `Map`, `Set`, `WeakMap`, `WeakSet`

Map — key-value pairs where keys can be any value type (unlike plain objects, which coerce all keys to strings/symbols), with guaranteed insertion-order iteration and O(1) average lookup via internal hash table.

Set — same hash table mechanics as Map, storing unique values only.

WeakMap/WeakSet — keys must be objects (or, since ES2023, registered symbols) and are held with a weak reference — meaning the entry does not prevent garbage collection of the key. This is implemented via an ephemeron table: a special GC structure where an entry is only kept alive if the key is independently reachable elsewhere in the program.

Regular Map:  Map ──(strong ref)──► key object  ← key survives even if
                                                    nothing else references it
WeakMap:      WeakMap ··(weak ref)··► key object ← if all OTHER references
                                                     to key vanish, GC reclaims
                                                     it AND the WeakMap entry
                                                     disappears automatically

Why keys must be objects: primitives are interned/duplicated by value (see string interning above), so there's no unique heap identity to weakly track — garbage collection couldn't meaningfully determine "this specific primitive is no longer reachable" the way it can for a unique object pointer. This also means WeakMap/WeakSet are not iterable — their contents can vanish at any GC cycle, so exposing a stable iteration order is impossible by design.

Use case: attaching metadata to objects (e.g., DOM nodes) without creating a memory leak — when the DOM node is removed and has no other references, both it and its WeakMap entry become collectible together.

3.6 Structured Binary Data: `ArrayBuffer`, `SharedArrayBuffer`, TypedArrays, `DataView`

ArrayBuffer — a fixed-length, raw binary buffer (just bytes, no interpretation). Cannot be read/written directly; you need a "view."

TypedArrays (Uint8Array, Int32Array, Float64Array, etc.) — typed, fixed-format views over an ArrayBuffer's bytes, interpreting them as a specific numeric type.

const buffer = new ArrayBuffer(8);          // 8 raw bytes
const view32 = new Int32Array(buffer);        // interprets as two 32-bit ints
const view8  = new Uint8Array(buffer);        // interprets as eight 8-bit bytes — SAME memory
view32[0] = 1;
console.log(view8);  // Uint8Array [1, 0, 0, 0, 0, 0, 0, 0] on little-endian systems

ArrayBuffer (8 bytes, shared underlying memory):
┌────┬────┬────┬────┬────┬────┬────┬────┐
│ b0 │ b1 │ b2 │ b3 │ b4 │ b5 │ b6 │ b7 │
└────┴────┴────┴────┴────┴────┴────┴────┘
     ▲ Int32Array view[0] spans b0-b3   ▲ view[1] spans b4-b7
     ▲ Uint8Array view spans EACH byte individually — same underlying bytes

DataView — like a TypedArray but lets you read/write mixed types at arbitrary byte offsets, and lets you explicitly control endianness (byte order):

const dv = new DataView(buffer);
dv.setInt32(0, 42, true);   // true = little-endian
console.log(dv.getInt32(0, true)); // 42

SharedArrayBuffer + Atomics: Like ArrayBuffer but its memory can be shared across Web Workers (true shared memory, not message-passing copies). Because multiple threads can access it concurrently, race conditions are possible — the Atomics object provides indivisible read-modify-write operations (Atomics.add, Atomics.compareExchange, Atomics.wait/notify) to synchronize access safely without a full mutex library.

PART 4: TYPE CHECKING, COERCION & ENGINE MECHANICS

4.1 Determining Types Accurately

Method	Reliable for	Fails on
`typeof x`	primitives, functions	`null` → `"object"`; can't distinguish object subtypes
`x instanceof Ctor`	checking prototype chain membership	primitives; fails across JS realms/iframes (different global `Array`)
`Array.isArray(x)`	arrays specifically, cross-realm safe	nothing — this is the correct array check
`Object.prototype.toString.call(x)`	precise internal `[[Class]]` tag for any value	verbose; still the most reliable universal method
Custom type guards	domain-specific validation	only as good as the logic you write

Object.prototype.toString.call([]);        // "[object Array]"
Object.prototype.toString.call(null);       // "[object Null]"  ← correctly distinguishes null!
Object.prototype.toString.call(new Map());  // "[object Map]"
Object.prototype.toString.call(async()=>{});// "[object AsyncFunction]"

4.2 Abstract Operations & Coercion

ToPrimitive(input, hint) — the gateway operation for all coercion; converts an object to a primitive before ToString/ToNumber can act on it. Hint is one of "number", "string", or "default".

ToPrimitive algorithm (simplified):
1. If input already a primitive → return as-is
2. If input has Symbol.toPrimitive → call it with the hint, return result
3. Else, pick method order based on hint:
   "string" hint:  try toString() first, then valueOf()
   "number"/"default" hint: try valueOf() first, then toString()
4. First method returning a primitive wins

const obj = { valueOf: () => 10, toString: () => "ten" };
console.log(obj + 1);        // 11   — "default" hint → valueOf() wins → 10 + 1
console.log(`${obj}`);        // "ten" — "string" hint → toString() wins
console.log(Number(obj));     // 10   — "number" hint → valueOf() wins

ToString, ToNumber, ToBoolean — full coercion table:

Input	ToString	ToNumber	ToBoolean
`undefined`	`"undefined"`	`NaN`	`false`
`null`	`"null"`	`0`	`false`
`true`	`"true"`	`1`	`true`
`false`	`"false"`	`0`	`false`
`""`	`""`	`0`	`false`
`"123"`	`"123"`	`123`	`true`
`"abc"`	`"abc"`	`NaN`	`true`
`[]`	`""`	`0`	`true`
`[5]`	`"5"`	`5`	`true`
`[1,2]`	`"1,2"`	`NaN`	`true`
`{}`	`"[object Object]"`	`NaN`	`true`

console.log([] + []);       // ""       ← both arrays → "" via ToString, concatenated
console.log([] + {});        // "[object Object]"
console.log({} + []);        // 0 or "[object Object]" depending on statement-vs-expression parsing context (classic gotcha)
console.log(+[]);            // 0        ← unary + forces ToNumber
console.log(+"3.14");        // 3.14

4.3 Wrapper Objects: Boxing & Unboxing

const primStr = "hello";              // primitive
const objStr  = new String("hello");   // wrapper OBJECT, not a primitive

typeof primStr;    // "string"
typeof objStr;      // "object"
primStr === objStr; // false — different types entirely
primStr == objStr;  // true  — == unboxes objStr via ToPrimitive first

"hello" === "hello";           // true — string interning, same primitive value
new String("hello") === new String("hello"); // false — two distinct heap objects

Automatic temporary boxing during method calls:

"hi".length;   // engine internally: box "hi" → temp String object → read .length → discard wrapper

This temporary box is invisible and garbage-collected immediately — never assign custom properties expecting persistence (see §2.6's customProp example above; same mechanism).

Calling wrapper constructors WITHOUT new performs plain type coercion instead of object creation:

String(123);       // "123" — primitive string, ToString coercion
Number("42");        // 42 — primitive number, ToNumber coercion
Boolean(0);           // false — primitive boolean, ToBoolean coercion
new Number("42") === 42; // false — object wrapper, not primitive

Master Reference Table

Type	Stack/Heap	Mutable	`typeof` result
`undefined`	Stack (sentinel)	N/A	`"undefined"`
`null`	Stack (sentinel)	N/A	`"object"` (bug)
`boolean`	Stack	No	`"boolean"`
`number`	Stack (Smi) / Heap (HeapNumber)	No	`"number"`
`bigint`	Heap (digit array)	No	`"bigint"`
`string`	Heap (interned/rope/flat)	No	`"string"`
`symbol`	Heap (unique)	No	`"symbol"`
`object` (all subtypes)	Heap, stack holds pointer	Yes	`"object"` / `"function"`