Stop 04 · JavaScriptTopics · 28/36

Memory

In short

Every variable, array and DOM node your app keeps around takes up RAM. JavaScript handles most of it for you, but leaks can make a tab slow and heavy over time.

How JavaScript allocates memory for variables and objects (stack for primitives, heap for objects) — understanding this helps you reason about performance and leaks. JavaScript engines manage memory automatically, but developers still need to understand references and object lifetime to diagnose excessive allocation and leaks.

The jaadu mascot stands at a college locker holding a slip, next to a store room with a kit bag.

Think of it like this

Your locker and the store room

Your college locker has a small shelf for quick things, like your ID. Big stuff, like a cricket kit, goes to the store room, and your locker just keeps a slip saying where it is. Roughly, the shelf is the stack and the store room is the heap.

Watch it happen

A leak, then the fix

window

onResize

cache

resize

1/6You resize the window and onResize runs.

The big ideas

What you need to know

Stack and heap, roughly

Function calls and small values sit on the fast, tidy stack. Objects, arrays and functions live in the bigger heap.

Variables hold references

A variable holding an object stores a pointer to it in the heap, not the object itself. That's why copies share data.

What causes leaks

Timers never cleared, listeners never removed, global arrays that only grow, and references to DOM nodes you already removed.

Measure, don't guess

DevTools has a Memory panel. Take heap snapshots before and after an action and compare what grew.

See it in code

Walk through the code

1const cache = [];2 3function onResize() {4  cache.push(new Array(100_000).fill("data"));  // grows forever: a leak5}6window.addEventListener("resize", onResize);7 8// Fix: clean up when you're done9function stop() {10  window.removeEventListener("resize", onResize);11  cache.length = 0;12}13 14const id = setInterval(() => console.log("tick"), 1000);15// Later: clearInterval(id). Otherwise it runs as long as the page is open.

1/4Each call pushes a big array into a global cache that never shrinks.

Nothing here is a syntax error. The page just gets heavier every time you resize. Leaks are quiet, which is why cleanup has to be a habit.

Save yourself the pain

Common mistakes

Oops

Starting setInterval or adding listeners and never cleaning them up.

Do this instead

Keep the id and the handler. Call clearInterval and removeEventListener when the feature or component goes away.

Oops

Removing an element from the page but keeping it in an array or variable.

Do this instead

It stays in memory. Drop your references too, for example set the variable to null.

Your mission

Catch a leak

~25 min

Quick check

Which of these is most likely to cause a memory leak?

Go deeper

1Read a short explainer on the JS memory heap vs stack. Then apply the idea in a small example so the theory becomes practical.
2Use Chrome DevTools' Memory tab to take a heap snapshot of a page. Verify the behavior with realistic data and handle the failure or empty state as well.
3Learn what commonly causes memory leaks in JS apps (detached DOM nodes, forgotten listeners).

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download