Memory Management

// Phase 1: Mark — traverse from roots
// Global -> obj1 -> obj2 (both marked as reachable)

// Phase 2: Sweep — free unmarked objects
// Any object not marked is collected

// Generational GC (V8):
// - Young generation: new objects, collected frequently (Scavenge)
// - Old generation: survived objects, collected less often (Mark-Compact)

// Reference counting (older approach) fails with cycles:
let a = {};
let b = {};
a.ref = b;
b.ref = a;
a = null;
b = null;
// Mark-and-sweep handles this — both unreachable from root
// Reference counting would keep them alive (count never reaches 0)

Why it matters: Understanding mark-and-sweep and generational GC explains why object allocation patterns matter for performance. Short-lived objects (young generation) are cheap; long-lived objects (old generation) trigger more expensive major GC cycles.

Real applications: Writing animation loops that minimize object allocation per frame (avoids triggering GC mid-animation), designing data processing pipelines that process-and-discard objects quickly, and understanding why React's fiber reconciler was designed to create many short-lived objects efficiently.

Common mistakes: Creating many long-lived objects when short-lived ones would suffice (fills old generation), allocating in hot code paths during animations (causes GC jank), and not understanding that V8's incremental/concurrent GC reduces but doesn't eliminate pauses.

// 1. Forgotten timers
const id = setInterval(() => {
  doSomething(); // keeps running and referencing scope forever
}, 1000);
// Fix: clearInterval(id) when done

// 2. Event listeners not removed
element.addEventListener('click', handler);
// Fix: element.removeEventListener('click', handler)

// 3. Accidental globals
function leak() {
  leaked = 'oops'; // no let/const — becomes global variable
}

// 4. Growing arrays/maps never cleared
const cache = [];
function addToCache(item) {
  cache.push(item); // grows forever with no limit
}

// 5. Closures holding large scope
function createLeak() {
  const bigData = new Array(1000000);
  return () => console.log(bigData.length); // holds bigData forever
}

Why it matters: Memory leaks are the most common performance issue in SPAs. They manifest as gradual slowdown over time as users navigate and interact. This is an OWASP-adjacent concern for long sessions involving sensitive data that should be freed after use.

Real applications: React useEffect cleanup functions (prevent listener and timer leaks), component lifecycle cleanup in Vue/Angular, clearing setInterval in dashboard pages, and removing global event listeners when components unmount.

Common mistakes: Not returning a cleanup function from React's useEffect, using setInterval without storing the ID for later clearInterval, adding global event listeners in component code without removing them on unmount, and using var (accidental globals are a classic leak source).

let target = { name: 'data', payload: new Array(10000) };
const weak = new WeakRef(target);

console.log(weak.deref()?.name); // "data"

target = null; // now eligible for GC

// Later — may or may not be collected
const obj = weak.deref();
if (obj) {
  console.log('Still alive:', obj.name);
} else {
  console.log('Garbage collected');
}

// FinalizationRegistry — cleanup callback when object is collected
const registry = new FinalizationRegistry((id) => {
  console.log('Collected:', id);
  // Clean up external resources associated with id
});
registry.register(target, 'resource-123');

Why it matters: WeakRef fills the gap between the strong references of regular variables and the object-keyed-only WeakMap/WeakSet. It enables caches that automatically evict entries when the cached objects are no longer used elsewhere — without any explicit eviction logic.

Real applications: In-memory caches that auto-expire when their subject objects are GC'd, observer/subscription systems where the observer shouldn't keep observed objects alive, event system implementations that don't retain listeners that have been abandoned, and plugin systems where unloaded plugins should be GC'd.

Common mistakes: Relying on WeakRef for precise timing of cache eviction (GC is non-deterministic), not always checking .deref() for undefined before use, and using WeakRef when a WeakMap would be simpler and more appropriate (WeakMap should be first choice for object-keyed caching).

const cache = new WeakMap();

function expensiveCompute(obj) {
  if (cache.has(obj)) return cache.get(obj);

  const result = obj.data * 2; // heavy computation
  cache.set(obj, result);
  return result;
}

let item = { data: 42 };
expensiveCompute(item); // computes and caches
expensiveCompute(item); // returns cached result instantly

item = null;
// Cache entry for item is automatically cleaned up by GC

// WeakMap vs Map for caching:
// Map: keeps keys alive — memory leak potential
// WeakMap: lets keys be collected — no leak

// Practical: store private data for DOM elements
const elementData = new WeakMap();
function track(element) {
  elementData.set(element, { clicks: 0, visible: true });
}
// When element is removed from DOM and dereferenced, data is freed

Why it matters: WeakMap-based caching is the idiomatic way to attach metadata to objects without preventing their GC. This pattern is used in React (component fiber data), CSS-in-JS libraries (computed style caching), and any system that annotates third-party objects.

Real applications: Memoizing computed values keyed by DOM elements, caching parsed results keyed by input objects, storing private instance data in class implementations, and attaching behavioral metadata to objects you don't own (e.g., third-party SDK objects).

Common mistakes: Using a regular Map for a cache keyed by objects (memory leak — the Map keeps objects alive forever), expecting to iterate WeakMap entries (not supported), using primitive keys with WeakMap (TypeError — only objects and symbols allowed), and forgetting that WeakMap entries may disappear at any time.

function createHandler() {
  const largeData = new Array(1000000).fill('x');

  // This closure keeps largeData alive
  return function handler() {
    console.log(largeData.length);
  };
}

const fn = createHandler();
// largeData cannot be GC'd as long as fn exists

// Fix: extract only what you need, then release the large object
function createBetterHandler() {
  let largeData = new Array(1000000).fill('x');
  const length = largeData.length; // extract what you need
  largeData = null; // release the large array

  return function handler() {
    console.log(length); // only keeps the number, not the array
  };
}

Why it matters: Closures are among the most common unintentional memory retention mechanisms in JavaScript. Every event listener callback, every setTimeout handler, and every returned function potentially retains its entire lexical scope. This is widely misunderstood.

Real applications: React class components with event listener callbacks holding entire component instances, Node.js request handlers that close over large request objects, factory functions that return closures holding large datasets, and long-lived observable subscriptions.

Common mistakes: Not nulling out large variables inside a closure when they're no longer needed, using eval() or dynamic function creation inside closures (disables V8 scope optimization), not understanding that a closure keeps ALL outer scope variables alive, not just the ones it explicitly uses.

// Leak: reference to removed element
const btn = document.getElementById('myBtn');
document.body.removeChild(btn);
// btn variable still holds reference — element stays in memory

// Fix: null out the reference
let element = document.getElementById('myBtn');
element.remove();
element = null; // now GC can collect it

// Listeners on removed elements
const card = document.querySelector('.card');
card.addEventListener('click', handler);
card.remove();
// Fix: remove listener before or after removal, null reference
card.removeEventListener('click', handler);

// Using AbortController for easy cleanup
const controller = new AbortController();
element.addEventListener('click', handler, { signal: controller.signal });
// Later: controller.abort(); // removes all listeners at once

Why it matters: DOM memory leaks are particularly insidious in SPAs because JavaScript code keeps references to removed DOM nodes indefinitely. A single un-cleaned listener can prevent megabytes of DOM from being freed, causing progressive memory growth.

Real applications: React and Vue component cleanup hooks (remove listeners when components unmount), delegated event handling patterns (attach to parent, not individual children), virtual DOM frameworks that need to discard entire component trees, and single-page navigation where old route components must be fully freed.

Common mistakes: Using arrow function expressions as event handlers (can't call removeEventListener with them), not removing listeners from elements before they're removed from the DOM, and not using AbortController for batching listener cleanup in modern code.

// Creating a detached DOM tree
let container = document.createElement('div');
for (let i = 0; i < 100; i++) {
  container.appendChild(document.createElement('span'));
}
// container is never appended to document = detached tree

// In SPAs — component unmount without cleanup
class Widget {
  constructor() {
    this.el = document.createElement('div');
    document.body.appendChild(this.el);
  }
  destroy() {
    this.el.remove();
    this.el = null; // release reference!
  }
}

// Detect in DevTools:
// Memory tab -> Take heap snapshot
// Filter by "Detached" to find leaked DOM nodes
// Look for "Detached HTMLDivElement" etc.

Why it matters: Detached DOM tree leaks are one of the hardest memory leaks to diagnose because the nodes don't appear in the visible page — only in heap snapshots. They're a common real-world leak pattern in SPA frameworks that manage their own component trees.

Real applications: Modals and popups that are removed from DOM but have references stored in component state, drag-and-drop libraries that cache element references, virtualized list implementations that retain removed rows, and global event bus patterns that cache sender DOM elements.

Common mistakes: Storing DOM element references in long-lived data structures (Maps, module-level variables) without clearing them on removal, not nulling ref callbacks in React when components unmount, and using DevTools Elements panel instead of Memory panel to look for detached nodes (Elements only shows live DOM).

// Performance API for basic monitoring
console.log(performance.memory);
// { usedJSHeapSize, totalJSHeapSize, jsHeapSizeLimit }

// DevTools workflow for finding leaks:
// 1. Memory tab -> Take Heap Snapshot (baseline)
// 2. Perform the suspected leaking action
// 3. Take another snapshot
// 4. Compare snapshots -> "Comparison" view
// 5. Look for objects that grew unexpectedly

// Allocation timeline:
// Records allocations over time
// Blue bars = allocated, gray = freed
// Persistent blue bars = potential leak

// Mark timeline for correlation
console.timeStamp('Action started');
// ... perform action ...
console.timeStamp('Action ended');

// Force garbage collection in DevTools (for testing)
// Click the trash can icon in Performance/Memory tab

Why it matters: Knowing how to use browser DevTools for memory profiling is a critical skill for senior front-end developers. Without it, memory leaks are detected only through user-reported slowdowns after hours of use.

Real applications: Diagnosing growing memory in long-running dashboards, verifying that component cleanup hooks actually free memory (before/after heap comparison), auditing third-party library memory behavior, and catching regressions in memory usage during CI/CD with automated performance budgets.

Common mistakes: Taking only one snapshot (can't identify leaking objects without comparison), not forcing GC before taking snapshots (collected objects pollute the baseline), focusing on total heap size instead of object count growth, and not filtering snapshot results to find "Detached DOM" objects specifically.

// 1. Clean up in component lifecycle
class Component {
  init() {
    this.timer = setInterval(this.update, 1000);
    this.controller = new AbortController();
    document.addEventListener('click', this.onClick, {
      signal: this.controller.signal
    });
  }
  destroy() {
    clearInterval(this.timer);
    this.controller.abort(); // removes all listeners
  }
}

// 2. Use WeakMap/WeakSet for metadata
const metadata = new WeakMap();
metadata.set(domNode, { clicks: 0 });

// 3. Limit cache size with LRU
class LRUCache {
  #map = new Map();
  #max;
  constructor(max = 100) { this.#max = max; }
  get(k) {
    const v = this.#map.get(k);
    if (v !== undefined) { this.#map.delete(k); this.#map.set(k, v); }
    return v;
  }
  set(k, v) {
    this.#map.delete(k);
    this.#map.set(k, v);
    if (this.#map.size > this.#max)
      this.#map.delete(this.#map.keys().next().value);
  }
}

Why it matters: Memory best practices are the difference between an application that degrades after 30 minutes of use and one that runs stably for hours. These patterns are standard expectations in senior engineer interviews and production code reviews.

Real applications: Dashboard applications running in operations centers (must not degrade over hours), mobile PWAs where JavaScript heap is limited, Electron apps that run for days without restart, and any application serving users on low-memory devices.

Common mistakes: Not implementing cleanup at all in development (only caught by testing with long sessions), using unbounded caches without size limits (most common production memory issue), and not profiling before optimizing (premature optimization based on assumptions rather than measurements).

// Create a registry with a cleanup callback
const registry = new FinalizationRegistry((heldValue) => {
  console.log('Object collected, cleaning up:', heldValue);
  // Close file handle, release buffer, etc.
  externalResources.release(heldValue);
});

// Register an object with a held value for cleanup
let obj = { name: 'resource' };
registry.register(obj, 'resource-id-123');
// When obj is GC'd, callback fires with 'resource-id-123'

obj = null; // eligible for GC — callback will fire eventually

// Unregister if cleanup is done manually
const token = {};
registry.register(obj, 'cleanup-data', token);
// Later, if you clean up manually:
registry.unregister(token); // prevent callback from firing

Why it matters: FinalizationRegistry enables GC-triggered cleanup for external resources (OS handles, GPU textures, network connections) associated with JavaScript objects. This is a critical capability for systems programming in JavaScript that wasn't possible before ES2021.

Real applications: Finalizing OS file handles when wrapper objects are GC'd, releasing GPU resources when WebGL wrapper objects are abandoned, closing unused database connections, cleaning up WASM memory when JavaScript wrappers are collected, and freeing event subscription objects in observer patterns.

Common mistakes: Using FinalizationRegistry as the primary cleanup mechanism instead of a safety net (callbacks may never fire), not understanding that the held value (second argument) must not reference the registered target (creates a strong reference defeating the purpose), and using FinalizationRegistry for timing-sensitive cleanup that must happen immediately.

// Worker has its own heap — no shared objects
const worker = new Worker('worker.js');

// Data is COPIED via structured clone (not shared)
worker.postMessage({ data: [1, 2, 3] }); // clone sent to worker
// Original array is not affected by worker's changes

// Transferable objects — move ownership (zero-copy)
const buffer = new ArrayBuffer(1024);
worker.postMessage(buffer, [buffer]); // transferred, not copied
console.log(buffer.byteLength); // 0 — ownership moved to worker

// SharedArrayBuffer — true shared memory
const shared = new SharedArrayBuffer(1024);
const view = new Int32Array(shared);
worker.postMessage(shared);
// Both threads see the same memory
// Use Atomics for thread-safe operations
Atomics.add(view, 0, 1); // thread-safe increment

Why it matters: Web Worker memory isolation means you don't get thread-safety issues from shared mutable state — but you also need to understand how to efficiently pass data between main thread and workers without expensive serialization of large payloads.

Real applications: Image processing workers that receive and return large ArrayBuffers via transfer (zero-copy), SharedArrayBuffer-based worker pools for parallel computation, offloading large JSON processing to workers to prevent main thread blocking, and building WebAssembly modules that share memory with JavaScript via SharedArrayBuffer.

Common mistakes: Posting large ArrayBuffers to workers without transferring them (copies entire buffer — slow and doubles memory), using the original ArrayBuffer reference after transferring it (becomes empty/detached), and using SharedArrayBuffer without Atomics (race conditions in concurrent access).

// Shallow copy — shared nested references
const original = { a: 1, nested: { b: 2 } };
const shallow = { ...original };
shallow.a = 99;           // does NOT affect original
shallow.nested.b = 99;    // DOES affect original!
console.log(original.nested.b); // 99

// Deep copy methods
// 1. structuredClone (modern, recommended)
const deep = structuredClone(original);
deep.nested.b = 100;
console.log(original.nested.b); // 99 — independent

// 2. JSON parse/stringify (limited — no functions, Date, etc.)
const jsonDeep = JSON.parse(JSON.stringify(original));

// Memory implications:
// Shallow: less memory, shared references
// Deep: more memory, no shared references
// Choose based on whether mutation isolation is needed

// structuredClone handles:
// - Nested objects, arrays, Maps, Sets
// - Date, RegExp, Blob, File, ArrayBuffer
// Does NOT handle: functions, DOM nodes, symbols

Why it matters: Deep vs shallow copy is a fundamental concept for preventing accidental mutations through shared references. Choosing the right copy strategy affects both correctness (shared vs independent data) and performance (deep copy is O(n) and allocates new memory).

Real applications: Redux state reducers (return new state objects instead of mutating), form state snapshots for undo/redo, API response objects that should be independent of each other, and data passed to Web Workers that shouldn't share mutation state with the main thread.

Common mistakes: Using JSON.parse(JSON.stringify()) for deep copy (loses Date, Map, Set, undefined, and function values), performing unnecessary deep copies when shallow would suffice (wastes memory and time), and modifying spread object properties and expecting the original to change (spread is shallow — nested objects are still shared).

// Allocate 16 bytes of raw memory
const buffer = new ArrayBuffer(16);
console.log(buffer.byteLength); // 16

// Create typed views into the same buffer
const int32 = new Int32Array(buffer);   // 4 elements (4 bytes each)
const uint8 = new Uint8Array(buffer);   // 16 elements (1 byte each)

int32[0] = 42;
console.log(uint8[0]); // 42 — same underlying memory!

// Direct allocation with TypedArray
const floats = new Float64Array(1000); // 8000 bytes
floats[0] = 3.14;

// DataView for mixed types
const view = new DataView(buffer);
view.setInt16(0, 256, true);   // little-endian
view.setFloat32(4, 3.14, true);

// Practical use: reading binary file data
const response = await fetch('image.png');
const arrayBuffer = await response.arrayBuffer();
const bytes = new Uint8Array(arrayBuffer);

Why it matters: TypedArrays are the gateway to high-performance JavaScript. Any low-level binary data operation — WebGL, WebAudio, FileReader, WebSockets, WebAssembly — uses ArrayBuffer under the hood. Understanding them is essential for graphics, audio, and binary protocol work.

Real applications: WebGL vertex buffers (Float32Array), PCM audio buffers (Float32Array in Web Audio API), binary WebSocket protocol parsing (DataView), file reading and manipulation (FileReader with ArrayBuffer), and WASM memory access via TypedArray views.

Common mistakes: Using regular JS arrays for binary data processing (10x+ slower than TypedArrays due to boxing overhead), creating a new ArrayBuffer per operation instead of reusing (excessive allocation), confusing TypedArray and DataView (TypedArray for homogeneous data; DataView for mixed-type binary structs), and not using typed array subarray for slicing without copying.

// Hidden classes — V8 tracks object shape
// Objects with same property order share a hidden class
const a = { x: 1, y: 2 };  // shape: {x, y}
const b = { x: 3, y: 4 };  // same shape — optimized!
const c = { y: 1, x: 2 };  // different order = different shape!

// Monomorphic vs polymorphic function calls
function getX(obj) { return obj.x; }
getX({ x: 1 });        // monomorphic — fast (one shape)
getX({ x: 1, y: 2 });  // polymorphic — slower (multiple shapes)

// V8 memory layout:
// - Young generation (semi-space): 1-8 MB, fast allocation
// - Old generation: larger, mark-sweep-compact
// - Large object space: objects > 512KB
// - Code space: compiled functions

// Tips for V8-friendly code:
// 1. Initialize all properties in constructor
// 2. Don't add/delete properties after creation
// 3. Use consistent object shapes
// 4. Avoid sparse arrays

Why it matters: V8's hidden classes are why consistent object shapes matter for performance. Hot code paths that create objects with different shapes (different property orders) cause deoptimizations that can make JS 10x slower. This is a frequent finding in V8 performance audits.

Real applications: Keeping objects in hot loops consistently shaped (same properties in same order), using object factories instead of ad-hoc object literals for performance-critical allocations, and understanding why TypeScript's type system inadvertently helps V8 optimization by enforcing consistent shapes.

Common mistakes: Adding properties conditionally after object creation (breaks hidden class sharing), deleting properties from objects in hot paths (forces monomorphic to polymorphic transition), and not knowing that Object.assign({}, ...) creates consistent shapes while property-by-property assignment may not.

// TypedArray vs Array for numbers
const regularArr = new Array(1000000).fill(0);     // ~8MB (boxed numbers)
const typedArr = new Int32Array(1000000);           // ~4MB (raw 32-bit)
const smallTyped = new Uint8Array(1000000);         // ~1MB (raw 8-bit)

// Set vs Array for lookups
const arr = [1, 2, 3, /* ... 10000 items */];
arr.includes(9999); // O(n) scan

const set = new Set(arr);
set.has(9999); // O(1) lookup

// Map vs Object for dynamic keys
// Map: more memory-efficient for frequent add/delete
// Object: more memory-efficient for static known keys

// BitSet for boolean flags (extremely compact)
class BitSet {
  constructor(size) { this.data = new Uint32Array(Math.ceil(size / 32)); }
  set(i) { this.data[i >> 5] |= (1 << (i & 31)); }
  get(i) { return (this.data[i >> 5] >> (i & 31)) & 1; }
}
// 1 million booleans in ~125KB vs ~8MB for boolean array

Why it matters: Memory-efficient data structures change the scalability of data-intensive applications. The difference between a flat array and a linked list, or between an array of objects and a parallel arrays layout, can be 3-10x in memory usage at large scale.

Real applications: Using Uint8Array instead of number[] for byte data (8x memory reduction), TypedArrays for numeric datasets, generators for streaming large CSV files, virtual scrolling for rendering 100k-row lists, and bitsets for large boolean flag arrays.

Common mistakes: Using arrays of objects when parallel arrays (separate typed arrays per field) would use far less memory, not using typed arrays for numeric data (regular JS numbers are 64-bit doubles in V8), eagerly loading full dataset into memory when lazy loading would work, and not understanding that each JS object has ~100 bytes of overhead beyond its properties.

// Basic memory monitoring
console.log(process.memoryUsage());
// {
//   rss: 30000000,        // resident set size (total)
//   heapTotal: 7000000,   // V8 heap allocated
//   heapUsed: 5000000,    // V8 heap actually used
//   external: 1000000,    // C++ objects bound to JS
//   arrayBuffers: 500000  // ArrayBuffer memory
// }

// Detect leaks with periodic logging
setInterval(() => {
  const { heapUsed } = process.memoryUsage();
  console.log('Heap:', (heapUsed / 1024 / 1024).toFixed(2), 'MB');
}, 5000);

// Use --inspect for Chrome DevTools
// node --inspect server.js
// Open chrome://inspect in Chrome

// Heap snapshot programmatically
const v8 = require('v8');
const fs = require('fs');
const snapshotStream = v8.writeHeapSnapshot();
console.log('Snapshot written to:', snapshotStream);

// Trigger manual GC for testing (requires --expose-gc flag)
// node --expose-gc script.js
// global.gc();

Why it matters: Node.js memory leaks cause servers to grow in memory consumption until they OOM-crash or need restarts. In containerized deployments, this means unpredictable pod restarts. Detecting and fixing them is a critical SRE/backend skill.

Real applications: Express.js servers with uncleared session stores, database connection pools that don't release connections, long-running microservices with growing in-memory caches, and scheduled Node.js jobs that accumulate memory across runs.

Common mistakes: Not setting max listeners on EventEmitter (default 10 — exceeding it prints warnings), using module-level objects as unbounded caches, not calling stream.destroy() on error/close events, and not setting --max-old-space-size flag so Node.js doesn't hit the default 1.5GB limit in production.

// structuredClone — the public API for structured cloning
const original = {
  date: new Date(),
  regex: /hello/gi,
  map: new Map([['key', 'value']]),
  set: new Set([1, 2, 3]),
  buffer: new ArrayBuffer(8),
  nested: { deep: { value: 42 } }
};

const clone = structuredClone(original);
clone.nested.deep.value = 99;
console.log(original.nested.deep.value); // 42 — independent copy

// Handles circular references
const circular = { name: 'self' };
circular.self = circular;
const cloned = structuredClone(circular); // works!

// NOT supported:
// - Functions
// - DOM nodes
// - Symbols
// - Property descriptors (getters/setters)
// - Prototype chain
// structuredClone(() => {}); // DataCloneError

Why it matters: The structured clone algorithm is the serialization mechanism underlying Web Workers, BroadcastChannel, IndexedDB, and the History API. Understanding what it can and can't clone helps debug mysterious "DataCloneError" failures when passing data across these boundaries.

Real applications: Deep copying state objects in Redux reducers, serializing data for postMessage to Web Workers, storing complex objects in IndexedDB, undo/redo history systems that snapshot application state, and cloning form data objects before validation mutations.

Common mistakes: Expecting JSON serialization to deep copy (silently drops undefined, functions, symbols, and Date types), not knowing that structuredClone cannot clone functions or class instances with methods (DataCloneError), and serializing large objects unnecessarily when a shallow copy or immutable update pattern would work.

// 1. Component cleanup pattern
class AppView {
  #subscriptions = [];
  #controller = new AbortController();

  mount() {
    // Track all subscriptions for cleanup
    this.#subscriptions.push(
      store.subscribe('update', this.onUpdate)
    );
    window.addEventListener('resize', this.onResize, {
      signal: this.#controller.signal
    });
  }

  unmount() {
    this.#subscriptions.forEach(unsub => unsub());
    this.#subscriptions = [];
    this.#controller.abort(); // removes all DOM listeners
  }
}

// 2. Object pool for frequently created/destroyed objects
class ObjectPool {
  #pool = [];
  acquire() { return this.#pool.pop() || this.create(); }
  release(obj) { this.reset(obj); this.#pool.push(obj); }
  create() { return { x: 0, y: 0, active: false }; }
  reset(obj) { obj.x = 0; obj.y = 0; obj.active = false; }
}

// 3. Virtual scrolling — only render visible items
// Instead of 10,000 DOM nodes, render ~20 visible ones
// Libraries: react-window, @angular/cdk virtual-scroll

Why it matters: Large-scale application memory management is the difference between a product that scales to millions of users and one that degrades at 10,000. These patterns are standard in enterprise applications, games, and high-traffic consumer products.

Real applications: Virtual scrolling in data grid components (ag-Grid, Tanstack Virtual), object pooling in WebGL particle systems and game engines, lazy module loading in large SPAs, LRU cache implementations for API response caching, and incremental DOM hydration in SSR frameworks.

Common mistakes: Not implementing virtual scrolling for any list over 1000 items (DOM bloat), treating object pooling as premature optimization (it's mandatory for 60fps animations), not measuring before optimizing (many perceived memory issues are actually GC pause timing issues), and applying optimizations uniformly instead of targeting only hot paths identified by profiling.