DEV Community: Mitha

Hunting Memory Leaks in JavaScript: Notes on V8 Mechanics & Chrome DevTools

Mitha — Fri, 02 Oct 2026 06:19:56 +0000

JavaScript developers rarely have to think about manual memory management. Under the hood, the engine's Garbage Collector (GC) cleans up after us.

However, automatic memory management is not foolproof. Memory leaks in modern web apps usually aren't about forgotten allocations—they're about references that remain reachable longer than intended.

In this post, we’ll explore how V8 manages memory under the hood, walk through 7 common JavaScript memory-leak patterns, and show how to use Chrome DevTools Heap Snapshots to track them down.

1. How Garbage Collection Works: Reachability & V8 Heap

Modern JavaScript engines manage memory based on the concept of Reachability: an object is kept alive as long as it can be traced back to a GC Root (such as the global window object, current call stack execution contexts, or active host handles).

The V8 Generational Heap

V8 categorizes objects by age to optimize garbage collection performance:

Young Generation (Scavenger): Short-lived allocations (most objects die young). Fast, frequent GC cycles clean these up using parallel copying algorithms.
Old Generation (Major GC): Objects that survive multiple young-generation sweeps are promoted to the Old Space. Here, V8 uses a combination of Mark-Sweep-Compact alongside concurrent and incremental marking to prevent stop-the-world pauses.

Regardless of which generation an object lives in, Reachability is the deciding factor: if an application retains an unwanted reference path from a GC Root to an object, V8 cannot sweep it.

2. Common JavaScript Memory Leaks

Quick Reference:

No.	Leak Pattern	Root Cause	Quick Fix
1	Global Scope Bleed	Undeclared variables (`userCache = ...`)	Always use `const` / `let`
2	Detached DOM	Removed element retained in JS array/object	Remove long-lived array/cache reference
3	Global Listeners	`window.addEventListener` left unbound	Call `removeEventListener` on cleanup
4	Forgotten Timers	`setInterval` running in background	Call `clearInterval` on teardown
5	Stale Closures	Long-lived closure captures large object	Avoid capturing unnecessary data
6	Unbounded Caches	Standard `Map`/`Set` storing object keys	Evict entries or use weak collections
7	Console Logging	`console.log()` holding objects in DevTools	Clear logs or disable in production

Case 1: Accidental Global Variables & Scope Bleed

In classic non-strict browser scripts, assigning to an undeclared variable can create a property on the global object, such as window, preventing GC from sweeping them even after the executing function ends.

// ❌ LEAKY CODE:
function processUserData(data) {
  // Missing 'const/let' creates window.userCache
  userCache = new Array(1_000_000).fill('Data'); 
}

// ✅ FIXED CODE:
function processUserDataCleanly(data) {
  const userCache = new Array(1_000_000).fill('Data');
  // After the function returns, this reference is no longer held
// by the local scope and the array can become collectible.
}

Case 2: Detached DOM Trees

A detached DOM node occurs when an element is removed from the DOM using .removeChild() or .remove(), but a JS object or cache retains a reference to it—or to one of its children.

const nodeCache = [];

document.getElementById('leak-btn').addEventListener('click', () => {
  const listItem = document.getElementById('item-42');

  // Attaching a huge payload directly to the element so it stands out in DevTools!
  listItem.hugePayload = new Array(1_000_000).fill('💥 LEAKED DATA 💥');

  listItem.parentNode.removeChild(listItem);
  nodeCache.push(listItem);

  console.log('Leaked item with 1M array elements!');
});

Figure 1: Profiling the detached element in Chrome DevTools. While its shallow size is only 0.1 kB, its retained size consumes 74% of the total heap memory due to the attached array.

Case 3: Dangling Global Event Listeners

Attaching event listeners to long-lived objects (window, document, or global event emitters) without explicit unbinding can retain the callback and any objects it captures for as long as the listener remains registered.

// ❌ LEAKY CODE:
function attachTracking() {
  const heavyMetadata = new Array(500_000).fill('📊');

  window.addEventListener('resize', () => {
    console.log('Resized:', heavyMetadata.length);
  });
} 
// Even if the UI component relying on tracking is destroyed, window retains the callback.

// ✅ FIXED CODE:
function attachTrackingCleanly() {
  const heavyMetadata = new Array(500_000).fill('📊');
  const handleResize = () => console.log('Resized:', heavyMetadata.length);

  window.addEventListener('resize', handleResize);

  // Provide clear cleanup handler
  return () => window.removeEventListener('resize', handleResize);
}

Case 4: Forgotten Timers & Unbound Animation Loops

Callback functions passed to setInterval remain referenced by the browser's background timer infrastructure until explicitly cleared with clearInterval().

Similarly, recursive requestAnimationFrame loops that continually schedule another frame will keep running until they stop scheduling frames or are explicitly cancelled with cancelAnimationFrame().

// ❌ LEAKY CODE:
function startSync(serverData) {
  setInterval(() => {
    // The active timer keeps the callback reachable,
    // which can keep serverData reachable as well.
    console.log('Pinging server with ID:', serverData.id);
  }, 1000);
}

// ✅ FIXED: Return cleanup function to be called on teardown
function startSyncCleanly(serverData) {
  const timerId = setInterval(() => {
    console.log('Pinging server with ID:', serverData.id);
  }, 1000);

  // Return teardown function for when component/page unmounts
  return function stopSync() {
    clearInterval(timerId);
  };
}

// Usage:
const stop = startSyncCleanly({ id: 42 });
// ... later when UI unmounts or user navigates away:
stop();

Case 5: Stale Closures

A long-lived closure can keep captured objects reachable for as long as the closure itself remains alive.

// ❌ LEAKY CODE:
let globalRunner;

function createRunner() {
  const giantPayload = new Array(1_000_000).fill('🚀');

  globalRunner = function() {
    console.log(giantPayload.length);
  };
}

createRunner();

// globalRunner remains reachable,
// so giantPayload can remain reachable too.

Here the retention path is straightforward:

Global scope
    ↓
globalRunner
    ↓
closure
    ↓
giantPayload

The fix is to avoid capturing large objects when the callback only needs a small piece of data:

// ✅ FIXED CODE:
let globalRunner;

function createRunner() {
  const giantPayload = new Array(1_000_000).fill('🚀');
  const payloadSize = giantPayload.length;

  globalRunner = function() {
    console.log(payloadSize);
  };
}

Now the long-lived closure only needs payloadSize, not the large array.

Case 6: Unbounded Caches (`Map`/`Set` vs. `WeakMap`)

Standard Map and Set collections hold strong references to the objects they contain. This means as long as the Map itself is reachable, the objects it strongly references through its keys and values remain reachable too.

For general lookups and static data, Map is completely fine. However, using a global Map as an unbounded cache for temporary object metadata (like tracking active user sessions or attaching state to DOM nodes) will cause a memory leak unless you manually call .delete().

// ❌ LEAKY CODE:
const userSessionCache = new Map();

function trackUser(userObject) {
  userSessionCache.set(userObject, { loginTime: Date.now() });
}
// Even if userObject is no longer needed, Map retains it as a key.

// ✅ FIXED CODE: Use WeakMap for object keys
const userSessionCacheClean = new WeakMap();

function trackUserCleanly(userObject) {
  // WeakMap allows keys to be GC'd when no other references exist
  userSessionCacheClean.set(userObject, { loginTime: Date.now() });
}

When to swap Map for WeakMap:

Use Map when keys are primitives (string, number) or when you need to iterate over entries (.forEach(), .keys()).

Use WeakMap when keys are objects (like DOM elements or session instances) and you want their cached metadata to become eligible for garbage collection when no other references to the key remain.

Case 7: Chrome DevTools Console Log Retention

Chrome DevTools maintains internal references to objects logged to the console to enable interactive object inspection in the UI. While inspecting objects during active debugging sessions is harmless, logging massive data structures during performance profiling can artificially inflate heap memory metrics.

// ❌ POTENTIAL RETENTION DURING TEST RUNS:
function evaluateCalculation() {
  const massiveMatrix = new Array(5_000_000).fill(1.0);

  // DevTools may retain logged objects in memory during debugging
  console.log('Matrix result:', massiveMatrix); 
}

3. Systematic Profiling with Chrome DevTools

Step 1: Detect Leak Signals in the Performance Panel

Open DevTools -> Performance.
Check Memory.
Click Record, perform suspect user actions, and click the Collect Garbage (trash icon) button.
An ascending JS Heap baseline after forced GC is a strong signal that objects are remaining reachable and warrants investigation.

Figure 2: Performance panel timeline recording illustrating the classic "stair-step" JS Heap pattern. Repeated user interactions drive memory consumption up, and forcing Garbage Collection fails to bring the baseline down.

Step 2: Trace Retainers with Heap Snapshots

Go to Memory panel -> Select Heap Snapshot.
Take Snapshot 1 (baseline).
Perform the suspect user interaction multiple times.
Take Snapshot 2.
Switch the perspective dropdown from Summary to Objects allocated between Snapshot 1 and Snapshot 2. (Tip: DevTools also provides dedicated preset filters like "Objects retained by detached nodes" in the Summary view to pinpoint DOM leaks instantly).

Figure 3: Inspecting the Retainers pane in Snapshot 2. Tracing the reference path exposes globalLeakedCache in the script scope, revealing the reference that keeps the large array reachable.

Conclusion

When debugging a JavaScript memory leak, always trace the reference path by asking:

What object is being retained?
What GC root is keeping it reachable?
Where in the lifecycle should that reference have been released?

Preventing leaks comes down to explicit lifecycle management: clearing timers, removing event listeners, releasing unnecessary references, and leveraging weak collections like WeakMap and WeakSet.

10 JavaScript Behaviors That Look Weird Until You Understand the Rules

Mitha — Sat, 26 Sep 2026 06:10:42 +0000

JavaScript has a reputation for surprising even experienced developers. Many of its quirks aren't arbitrary, though—they follow directly from the language's coercion rules, execution model, parsing rules, and historical design decisions.

Coming to JavaScript after working with more structured languages like C can make some of these behaviors even more confusing.

Here are 10 common JavaScript behaviors that look strange at first, along with what's actually happening under the hood.

1. `typeof NaN === "number"` Is `true`

A common assumption is that NaN—"Not a Number"—should have a type other than number.

But:

console.log(typeof NaN);
// "number"

This makes more sense once we look at what NaN actually is.

JavaScript's Number type is based on the IEEE 754 double-precision floating-point format. NaN is a special numeric value in that format that represents the result of an operation that doesn't produce a meaningful numeric value.

For example:

console.log(0 / 0);
// NaN

console.log(Number("hello"));
// NaN

Even though these operations don't produce a usable number, their result is still represented using JavaScript's Number type.

So NaN isn't "not a number" in the sense of having a non-numeric JavaScript type. It's a special value within the Number type.

One more important detail: NaN is not equal to itself.

console.log(NaN === NaN);
// false

If you need to check for NaN, use Number.isNaN():

console.log(Number.isNaN(NaN));
// true

Takeaway: NaN is a special IEEE 754 floating-point value, which is why JavaScript considers its type to be number.

2. Why `[] + []` and `{} + []` Behave Differently

These two expressions look almost identical:

[] + []

and:

{} + []

But JavaScript can produce surprising results:

console.log([] + []);
// ""

console.log({} + []);
// 0  (in certain contexts)

The first result comes from JavaScript's type coercion rules.

When the + operator is used with objects, JavaScript first converts those objects to primitive values. Arrays are converted to strings using their toString() method:

console.log([].toString());
// ""

So:

[] + []

effectively becomes:

"" + ""

which produces:

""

The second expression is more subtle because parsing context matters.

When {} appears at the beginning of a statement, JavaScript can interpret it as an empty block rather than an object literal:

{} + []

The empty block doesn't produce a value. JavaScript then evaluates:

+[]

The unary + converts its operand to a number. An empty array is converted to an empty string, which is then converted to 0:

+[];
// 0

So the overall result can be:

However, this isn't a universal property of the expression {} + []. Put the same expression in an expression context and the parsing can change.

For example:

console.log({} + []);
// "[object Object]"

The important lesson isn't really that "{} + [] equals 0."

It's that JavaScript's parser has to determine what {} means before the type coercion rules even come into play.

Takeaway: When JavaScript behaves strangely, there can be more than one mechanism involved. Parsing happens first; coercion happens later.

3. Why `0.1 + 0.2 !== 0.3`

This is one of the most famous floating-point surprises in programming.

You might expect:

0.1 + 0.2

to produce exactly:

0.3

But:

console.log(0.1 + 0.2);
// 0.30000000000000004

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

The problem isn't specific to JavaScript. It comes from how floating-point numbers are represented.

JavaScript's Number type uses IEEE 754 binary floating-point. Computers represent numbers internally using binary, or base 2.

The problem is that some decimal fractions that look simple in base 10 cannot be represented exactly as finite binary fractions.

For example, 0.1 doesn't have an exact representation in IEEE 754 binary floating-point. The closest representable value is used instead.

The same is true for 0.2.

When those approximations are added together, the result is slightly different from the exact mathematical value 0.3.

That's why this:

0.1 + 0.2

produces something close to, but not exactly:

0.3

For calculations where exact decimal arithmetic matters—such as financial calculations—you need to account for this behavior rather than relying on direct floating-point equality.

Takeaway: Floating-point numbers are approximations. Don't assume that decimal values that look exact to us can always be represented exactly by a computer.

4. `Array.prototype.sort()` Doesn't Default to Numeric Sorting

Consider this array:

const numbers = [1, 20, 10, 5];

console.log(numbers.sort());
// [1, 10, 20, 5]

If you expected:

[1, 5, 10, 20]

JavaScript's behavior can seem strange.

The reason is that Array.prototype.sort() uses string comparison when you don't provide a comparison function.

Conceptually, the numbers are compared using their string representations:

String comparison puts "10" before "20" and "5" after both of them, producing:

[1, 10, 20, 5]

To sort numbers numerically, provide a comparison function:

const numbers = [1, 20, 10, 5];

numbers.sort((a, b) => a - b);

console.log(numbers);
// [1, 5, 10, 20]

The comparison function tells sort() how the elements should be ordered.

For ascending numerical order:

(a, b) => a - b

For descending order:

(a, b) => b - a

Takeaway: sort() doesn't know that your values are intended to represent numbers. If you need numeric ordering, explicitly provide a comparison function.

5. Automatic Semicolon Insertion (ASI) Can Change Your Code

JavaScript doesn't require you to explicitly write a semicolon after every statement.

For example:

const name = "Alice"
const age = 30

is valid JavaScript.

This is partly because of Automatic Semicolon Insertion (ASI), a set of language rules that allows certain line breaks to terminate statements.

Most of the time, this works exactly as you'd expect.

But there are cases where a line break can change the meaning of your code.

A. The `return` Pitfall

Consider:

function getUser() {
  return
  {
    name: "Alice"
  }
}

console.log(getUser());
// undefined

It might look like the function is returning the object:

{
  name: "Alice"
}

But JavaScript treats the line break after return as the end of the return statement.

Conceptually, this becomes:

function getUser() {
  return;
  {
    name: "Alice"
  }
}

The function therefore returns undefined.

This is why you'll often see the opening { placed on the same line as return:

function getUser() {
  return {
    name: "Alice"
  };
}

The same kind of issue can occur with other restricted statements such as throw, break, and continue.

B. The IIFE / Array Pitfall

ASI can also cause problems in the opposite direction: JavaScript may not insert a semicolon when the next line can syntactically continue the previous statement.

For example:

let x = 42

(function () {
  console.log("IIFE")
})()

A developer might expect this to be two separate statements.

But JavaScript can interpret it as though the function expression is being applied to 42:

let x = 42(function () {
  console.log("IIFE")
})()

which results in:

TypeError: 42 is not a function

This is one reason you'll sometimes see defensive semicolons before immediately invoked function expressions:

let x = 42;

;(function () {
  console.log("IIFE");
})()

Modern formatters such as Prettier, along with linting rules, can help prevent many of these problems.

Takeaway: ASI makes semicolons optional in many situations, but line breaks aren't always neutral. Be especially careful around return and lines beginning with (, [, or template literals.

6. `let` and `const` Are Hoisted: Meet the Temporal Dead Zone

A common explanation is that let and const aren't hoisted.

That's not quite accurate.

They are hoisted in the sense that their bindings are created when the JavaScript engine sets up the surrounding lexical environment. The important difference is that those bindings aren't initialized immediately.

Consider:

console.log(a);
// undefined

console.log(b);
// ReferenceError: Cannot access 'b' before initialization

var a = 1;
let b = 2;

With var, the variable is initialized with undefined during environment setup.

With let and const, the binding exists but remains uninitialized until execution reaches the declaration.

The period between entering the scope and reaching the declaration is called the Temporal Dead Zone (TDZ).

You can think of it roughly like this:

// b exists, but is uninitialized here

console.log(b);
// ReferenceError

let b = 2;

// b is initialized here

This distinction is important because saying "let isn't hoisted" can lead to an incomplete mental model.

A better model is:

var is hoisted and initialized with undefined.
let and const are hoisted but remain uninitialized.
Accessing an uninitialized let or const binding during the TDZ throws a ReferenceError.

Takeaway: The difference isn't whether let and const are hoisted. The important difference is when their bindings become initialized.

7. Why `var` and `let` Behave Differently in `for` Loops

This classic example demonstrates the interaction between variable scope, closures, and asynchronous callbacks.

Using var:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}

// 3
// 3
// 3

But using let:

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}

// 0
// 1
// 2

Why?

var is function-scoped rather than block-scoped. The loop uses a single i binding.

By the time the callbacks execute, the loop has already finished:

i = 3

All three callbacks close over the same binding, so they all read 3.

let behaves differently in a for loop. JavaScript creates a separate per-iteration binding for the loop variable.

Conceptually, the callbacks end up associated with different bindings:

iteration 1 → i = 0
iteration 2 → i = 1
iteration 3 → i = 2

So when the callbacks eventually execute, each one reads the value associated with its iteration.

This isn't really about setTimeout() itself. The same closure behavior can appear whenever a callback outlives the iteration in which it was created.

Takeaway: var gives you one shared function-scoped binding, while let provides per-iteration bindings in for loops.

8. Loose Equality (`==`) Has Coercion Rules

JavaScript's loose equality operator, ==, is often criticized for producing surprising results:

console.log("" == 0);
// true

console.log(false == 0);
// true

console.log("" == false);
// true

These results aren't random. They're consequences of JavaScript's defined equality algorithm.

For example:

`"" == 0`

When a string is compared with a number, JavaScript converts the string to a number.

Number("");
// 0

So the comparison effectively becomes:

0 == 0

which is true.

`false == 0`

When a boolean is compared with a number, the boolean is converted to a number:

Number(false);
// 0

So:

false == 0

becomes effectively:

0 == 0

and evaluates to true.

`"" == false`

This one involves multiple coercions.

The boolean is first converted to a number:

false → 0

Then the string is converted to a number:

"" → 0

So the comparison eventually becomes:

0 == 0

and evaluates to true.

This is why == can be difficult to reason about if you don't have its coercion rules memorized.

In most application code, === is easier to reason about because it doesn't perform this kind of implicit type conversion.

console.log("" === 0);
// false

That doesn't mean == is inherently broken or unusable. Its behavior is well-defined, and there are situations where developers deliberately use it.

But if you don't specifically want JavaScript's coercion rules, === is usually the clearer choice.

Takeaway: == isn't unpredictable—it has complicated coercion rules. === avoids those conversions and is generally easier to reason about.

9. Object Keys Are Coerced to Strings

In a regular JavaScript object, property keys are either strings or symbols.

That can lead to a surprising result when you try to use objects as keys.

Consider:

const obj = {};

const a = { key: "a" };
const b = { key: "b" };

obj[a] = 123;
obj[b] = 456;

console.log(obj[a]);
// 456

Why did assigning b overwrite the value associated with a?

When an object is used as a property key, JavaScript converts it to a property key. For ordinary objects, that conversion produces a string:

String(a);
// "[object Object]"

String(b);
// "[object Object]"

So these two assignments are effectively doing the same thing:

obj["[object Object]"] = 123;
obj["[object Object]"] = 456;

The second assignment overwrites the first.

If you actually want objects to be distinct keys, use a Map:

const map = new Map();

map.set(a, 123);
map.set(b, 456);

console.log(map.get(a));
// 123

console.log(map.get(b));
// 456

Map is specifically designed to associate values with keys without converting object keys into strings.

Takeaway: Plain objects are primarily string/symbol-keyed dictionaries. If you need objects, arrays, or other values to remain distinct keys, Map is usually the better abstraction.

10. `this` Is Dynamic in Regular Functions but Lexical in Arrow Functions

One of the most common sources of confusion in JavaScript is this.

Consider:

const user = {
  name: "Alice",

  regularFunc: function () {
    console.log(this.name);
  },

  arrowFunc: () => {
    console.log(this.name);
  }
};

user.regularFunc();
// "Alice"

user.arrowFunc();
// Depends on the surrounding context

The key difference is that regular functions and arrow functions determine this differently.

Regular functions: `this` depends on how they're called

When we call:

user.regularFunc();

the function is called as a method of user.

As a result:

this === user

inside the function.

So:

this.name

is equivalent to:

user.name

and produces:

Alice

Arrow functions: `this` is lexical

Arrow functions don't have their own this binding.

Instead, they capture this from their surrounding lexical context.

This means that the arrow function inside our object doesn't automatically get user as its this.

The exact result depends on where the object is created.

For example, in an ES module, top-level this is undefined:

console.log(this);
// undefined

An arrow function defined there captures that value.

In a browser's classic script, top-level this can instead refer to the global object.

This is why relying on the result of the example without specifying the execution environment can be misleading.

The important rule is:

Regular functions get this based on how they're called. Arrow functions capture this from their surrounding scope.

This is also why arrow functions are particularly useful for callbacks:

const user = {
  name: "Alice",

  greet() {
    setTimeout(() => {
      console.log(this.name);
    }, 100);
  }
};

user.greet();
// "Alice"

The arrow function doesn't create a new this; it captures the this from greet().

Takeaway: Don't think of arrow functions as a shorter way to write regular functions. Their handling of this is fundamentally different.

[quick-revisit]: Event Loop - Browser vs. Node.js

Mitha — Mon, 21 Sep 2026 17:18:43 +0000

JavaScript is single-threaded, yet JavaScript runtimes handle high-concurrency I/O effortlessly. They achieve this through the Event Loop—an orchestrator that delegates heavy work (network, disk, timers) to system kernel threads and queues up callbacks for execution on the main thread.

While both environments run JavaScript, the Browser Event Loop is optimized for user interactions and frame rendering (UI thread), whereas the Node.js Event Loop is optimized for high-throughput I/O and OS system operations.

The Mental Model

Think of the Event Loop as a traffic controller managing two highways merging into a single lane (the single JavaScript call stack):

Macrotask Queue (Regular Highway): Timers (setTimeout), I/O callbacks, user clicks, network events.
Microtask Queue (VIP Express Lane): Promises, queueMicrotask, and in Node.js, process.nextTick() (which gets its own ultra-VIP lane before standard Promises).

RULE: The Call Stack MUST be completely empty first.
  1. Flush Microtasks (VIP Lane)     -> Drain to 0
  2. Pick Macrotask (Regular Highway) -> Execute exactly 1 item
  3. Repeat

The Browser Event Loop Workflow

The Node.js Event Loop Workflow

No single macrotask queue: Unlike browsers, Node splits macrotasks into phase-specific queues (Timers -> Poll -> Check).
Timers Phase: Executes callbacks scheduled by setTimeout() and setInterval().
Poll Phase: Processes incoming network requests, database queries, and file system I/O callbacks.
Check Phase: Executes setImmediate() callbacks immediately after the Poll phase completes.
Microtask Interruption: The microtask queue (process.nextTick + Promises) drains completely to zero after every single macrotask and between phases.

3 Rules That Prevent Tricky Async Bugs

1. `process.nextTick()` Always Wins (Node.js Only)

process.nextTick() sits in its own nextTickQueue, executing immediately after the current operation completes—before any standard Promise microtasks.

Promise.resolve().then(() => console.log('1. Promise'));
process.nextTick(() => console.log('2. nextTick'));

// Output:
// 2. nextTick
// 1. Promise

⚠️ Starvation Gotcha: Recursively calling process.nextTick() starves the Event Loop, blocking I/O and timers indefinitely.

2. `setTimeout(fn, 0)` vs `setImmediate(fn)` (Node.js)

setTimeout(fn, 0) runs in the Timers phase (Node converts 0ms to 1ms minimum).

setImmediate(fn) runs in the Check phase.

Execution order is non-deterministic in the main script, but deterministic inside I/O callbacks:

// Main script: Unpredictable output due to CPU/timer initialization bound
setTimeout(() => console.log('1. setTimeout'), 0);
setImmediate(() => console.log('2. setImmediate'));

// Inside I/O callback: setImmediate ALWAYS runs first
const fs = require('fs');
fs.readFile(__filename, () => {
  setTimeout(() => console.log('1. setTimeout'), 0);
  setImmediate(() => console.log('2. setImmediate')); 
  // Output: Always 2, then 1 (Poll phase transitions directly to Check phase)
});

3. Rendering Priority (Browser Only)

Browsers run a Rendering Phase (Style -> Layout -> Paint) inside the event loop targeting ~60Hz (16.6ms per frame).

Microtask Bloat: Blocking the microtask queue delays frame rendering, freezing the page UI.

requestAnimationFrame: Callbacks execute immediately before the repaint step, making them ideal for visual updates compared to setTimeout.

Quick Reference: Execution Order Tracing

Test your knowledge on this classic interview execution tracer:

console.log('1. Sync');

setTimeout(() => console.log('2. Macrotask (Timer)'), 0);

Promise.resolve().then(() => console.log('3. Microtask (Promise)'));

process.nextTick(() => console.log('4. Microtask (nextTick)'));

console.log('5. Sync');

Execution Order:

1. Sync (Main Call Stack)
5. Sync (Main Call Stack)
4. Microtask (nextTick) (Node Ultra-VIP Queue)
3. Microtask (Promise) (Standard Microtask Queue)
2. Macrotask (Timer) (Timers Phase)

[quick-revisit]: MongoDB Indexes & B-Trees

Mitha — Sat, 19 Sep 2026 09:21:41 +0000

The Mental Model

A MongoDB collection without an index is like a cookbook without an index section—finding a single recipe requires flipping through all 500 pages. An index extracts a small subset of fields, sorts them, and maps them to exact disk locations so MongoDB can turn directly to the target page and jump straight to the document.

The Basics

An index is a specialized, memory-friendly data structure that stores a tiny slice of your collection's data in a pre-sorted format.

Key characteristics to keep in mind:

The Structure: MongoDB uses B-Trees to organize index keys, allowing logarithmic lookup times O(log N).
Field Ordering: Index entries are stored strictly ordered by field value (ascending 1 or descending -1).
The Default Index: Every collection automatically gets a unique index on _id. This index cannot be dropped and enforces primary key uniqueness.

4 Rules That Prevent Silent Database Bugs

1. Know Your Execution Stages (`COLLSCAN` vs `IXSCAN`)

Always run .explain("executionStats") on queries you suspect are slow. Look at the stage field in the output:

COLLSCAN (Collection Scan): MongoDB inspected every single document in the collection. This is a massive red flag in production.
IXSCAN (Index Scan): MongoDB used a B-Tree index to locate only the target documents.

⚠️ The Ratio Gotcha: Pay attention to totalDocsExamined vs nReturned. If totalDocsExamined is 100,000 and nReturned is 2, your query spent 99.98% of its effort reading irrelevant data off disk.

2. The ESR Rule for Compound Indexes (Equality, Sort, Range)

When indexing multiple fields (e.g., { status: 1, age: 1, createdAt: -1 }), key order matters immensely. Follow the ESR Rule:

Equality: Place exact match fields first (e.g., status: "ACTIVE").
Sort: Place sorting fields second (e.g., createdAt: -1).
Range: Place range filter fields last (e.g., age: { $gte: 21 }).

// ❌ POOR INDEX: Range before Equality forces in-memory sorting
db.users.createIndex({ age: 1, status: 1 });

// ✅ OPTIMAL INDEX: Equality first, Range/Sort last
db.users.createIndex({ status: 1, age: 1 });

3. The Embedded Document Trap

Single-field indexes work on embedded sub-documents, but only when querying the entire object verbatim.

// Given a document: { user: { name: "Mitha", role: "admin" } }
db.logs.createIndex({ "user": 1 });

// ❌ FAILS TO USE INDEX: Querying a specific sub-field skips the index
db.logs.find({ "user.name": "Mitha" }); 

// ✅ USES INDEX: Must query dot-notation field directly instead
db.logs.createIndex({ "user.name": 1 });

4. Respect The "Write Penalty"

Indexes take up memory and need to be maintained. Every time you run insertOne(), updateOne(), or deleteOne(), MongoDB must modify the collection AND rebalance every B-Tree index on that collection.

High Read / Low Write: Index aggressively.
High Write / Low Read (e.g., IoT logs, telemetry): Keep indexes to an absolute minimum. Excess indexes on write-heavy collections will choke IOPS and create storage bloat.

Quick Reference: Query Patterns vs. Index Choice

When your query looks like...	Use this Index...	What MongoDB actually does
`find({ email: "user@test.com" })`	Single Field `{ email: 1 }`	B-Tree lookup on one sorted field. Instant `O(log N)` match.
`find({ status: "ACTIVE" }).sort({ date: -1 })`	Compound `{ status: 1, date: -1 }`	Navigates to `"ACTIVE"` group, then reads pre-sorted dates directly. Avoids in-memory sort.
`find({ tags: "node" })` (where `tags` is an array)	Multikey `{ tags: 1 }`	Creates B-Tree index keys for every individual array element automatically.
`find({ $text: { $search: "database" } })`	Text `{ description: "text" }`	Builds an inverted index of stemmed words to enable full-text keyword search.
`find()` on temporary data (e.g. JWT tokens, OTPs)	TTL (Time-To-Live) `{ createdAt: 1 }, { expireAfterSeconds: 3600 }`	Background task checks timestamp and auto-deletes expired documents after $N$ seconds.

[quick-revisit]: Express Middleware

Mitha — Thu, 17 Sep 2026 14:56:46 +0000

The Mental Model

Think of Express Middleware as a stack of functions that are called sequentially. Express apps run entirely through a series of middleware function calls.

The Basics

Middleware has access to the following:

The req (request) object.
The res (response) object.
The next() function.
The err object (only accessible to Error-handling Middleware)

Middleware can do the following:

Execute application code.
Manipulate the req and res objects. (e.g.: attaching req.user)
End request-response lifecycle (e.g. res.json()).
Pass control to the next middleware function using next().

4 Rules That Prevent Silent Bugs

1. Every Middleware Must Pass the Torch (`next()` vs. `res.send()`)

Call next() to yield control to the next function down the stack.
Send a response (e.g., res.json()) to close the socket connection.

⚠️ The Endless Spinner Gotcha: If your middleware executes logic but
omits next() without sending a response, the client browser will hang
until hit by a socket timeout.

2. Leverage Middleware Chaining (Separation of Concerns)

Instead of bundling authentication, role checks, and database queries inside a single route controller, chain lightweight single-purpose middlewares directly within the route definition:

// Middleware 1: Verify token & attach user
const authenticate = (req, res, next) => {
  req.user = { id: 101, role: 'admin' }; // Upstream mutation
  next();
};

// Middleware 2: Role-based access control (RBAC)
const requireAdmin = (req, res, next) => {
  if (req.user?.role !== 'admin') {
    return res.status(403).json({ error: "Access denied" });
  }
  next();
};

// Chained Route Handler
app.post('/admin/settings', authenticate, requireAdmin, (req, res) => {
  res.json({ status: "Settings updated" });
});

3. Watch the 4-Parameter Arity Trap (Error Handling)

Express uses JavaScript's Function.length property to inspect handler signatures. An error handler must explicitly declare all 4 parameters: (err, req, res, next).

// ❌ FAILS: Express treats this as standard app middleware and ignores thrown errors
app.use((err, req, res) => {
  res.status(500).send("Error");
});

// ✅ WORKS: Express recognizes the 4-argument signature via arity
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: err.message });
});

4. Catch Async Exceptions (Express 4 vs. Express 5)

In Express 4, thrown errors inside async functions are not automatically caught by the global error handler. You must explicitly pass caught promises to next(err) — or wrap your routes in an async handler utility:

// Express 4 Async Gotcha: Must call next(err) explicitly
app.get('/user/:id', async (req, res, next) => {
  try {
    const user = await User.findById(req.params.id);
    res.json(user);
  } catch (err) {
    next(err); // Without this, unhandled rejections crash the process or hang
  }
});

(Note: Express 5 natively handles rejected promises in async middleware routes automatically).

Quick Reference: The 5 Middleware Types

Type	Syntax Scope	Primary Use Case
App-Level	`app.use()`	Global logging, CORS policies, static assets.
Router-Level	`router.use()`	Scoped API versions (e.g., locking `/api/v1/*`).
Chained	`app.post('/path', m1, m2)`	Single-route validation, payload sanitization.
Error-Handling	`app.use((err, req, res, next))`	Global exception formatting and error logging.

DEV Community: Mitha

Hunting Memory Leaks in JavaScript: Notes on V8 Mechanics & Chrome DevTools

1. How Garbage Collection Works: Reachability & V8 Heap

The V8 Generational Heap

2. Common JavaScript Memory Leaks

Quick Reference:

Case 1: Accidental Global Variables & Scope Bleed

Case 2: Detached DOM Trees

Case 3: Dangling Global Event Listeners

Case 4: Forgotten Timers & Unbound Animation Loops

Case 5: Stale Closures

Case 6: Unbounded Caches (Map/Set vs. WeakMap)

Case 7: Chrome DevTools Console Log Retention

3. Systematic Profiling with Chrome DevTools

Step 1: Detect Leak Signals in the Performance Panel

Step 2: Trace Retainers with Heap Snapshots

Conclusion

10 JavaScript Behaviors That Look Weird Until You Understand the Rules

1. typeof NaN === "number" Is true

2. Why [] + [] and {} + [] Behave Differently

3. Why 0.1 + 0.2 !== 0.3

4. Array.prototype.sort() Doesn't Default to Numeric Sorting

5. Automatic Semicolon Insertion (ASI) Can Change Your Code

A. The return Pitfall

B. The IIFE / Array Pitfall

6. let and const Are Hoisted: Meet the Temporal Dead Zone

7. Why var and let Behave Differently in for Loops

8. Loose Equality (==) Has Coercion Rules

"" == 0

false == 0

"" == false

9. Object Keys Are Coerced to Strings

10. this Is Dynamic in Regular Functions but Lexical in Arrow Functions

Regular functions: this depends on how they're called

Arrow functions: this is lexical

[quick-revisit]: Event Loop - Browser vs. Node.js

The Mental Model

The Browser Event Loop Workflow

The Node.js Event Loop Workflow

3 Rules That Prevent Tricky Async Bugs

1. process.nextTick() Always Wins (Node.js Only)

2. setTimeout(fn, 0) vs setImmediate(fn) (Node.js)

3. Rendering Priority (Browser Only)

Quick Reference: Execution Order Tracing

[quick-revisit]: MongoDB Indexes & B-Trees

The Mental Model

The Basics

4 Rules That Prevent Silent Database Bugs

1. Know Your Execution Stages (COLLSCAN vs IXSCAN)

2. The ESR Rule for Compound Indexes (Equality, Sort, Range)

3. The Embedded Document Trap

4. Respect The "Write Penalty"

Quick Reference: Query Patterns vs. Index Choice

[quick-revisit]: Express Middleware

The Mental Model

The Basics

4 Rules That Prevent Silent Bugs

1. Every Middleware Must Pass the Torch (next() vs. res.send())

2. Leverage Middleware Chaining (Separation of Concerns)

3. Watch the 4-Parameter Arity Trap (Error Handling)

4. Catch Async Exceptions (Express 4 vs. Express 5)

Quick Reference: The 5 Middleware Types

Case 6: Unbounded Caches (`Map`/`Set` vs. `WeakMap`)

1. `typeof NaN === "number"` Is `true`

2. Why `[] + []` and `{} + []` Behave Differently

3. Why `0.1 + 0.2 !== 0.3`

4. `Array.prototype.sort()` Doesn't Default to Numeric Sorting

A. The `return` Pitfall

6. `let` and `const` Are Hoisted: Meet the Temporal Dead Zone

7. Why `var` and `let` Behave Differently in `for` Loops

8. Loose Equality (`==`) Has Coercion Rules

`"" == 0`

`false == 0`

`"" == false`

10. `this` Is Dynamic in Regular Functions but Lexical in Arrow Functions

Regular functions: `this` depends on how they're called

Arrow functions: `this` is lexical

1. `process.nextTick()` Always Wins (Node.js Only)

2. `setTimeout(fn, 0)` vs `setImmediate(fn)` (Node.js)

1. Know Your Execution Stages (`COLLSCAN` vs `IXSCAN`)

1. Every Middleware Must Pass the Torch (`next()` vs. `res.send()`)