19 — Browser DevTools — Where JavaScript Gets Diagnosed

"The F12 panel" was my DevTools model, which made each debugging session a hunt through the same tabs. The idea that everything else hangs off: DevTools isn't one tool — it's a shell holding several distinct tools, and each failure mode I face (a wrong value, a leak, a slow render) has a specific panel that exists to answer exactly that question. [1]

The framing that finally landed is matching the panel to the question. When I used to flail — open DevTools, poke around, hope — I was treating it as one monolithic debugger. The shift was treating each tab as a specialized instrument: there's a panel for "what's this value," a panel for "where did the memory go," a panel for "why is this slow," and a panel for "what did the network do." Naming the question first, then opening the matching panel, cut my debugging time dramatically.

Sources: stepping through code

When the bug is "the code is doing the wrong thing," Sources is the panel [2]. The workflow: open the file, click a line number to set a breakpoint, trigger the action, and execution pauses there. From the paused state I can:

• Step over / into / out — walk the code line by line, into function calls or past them.
• Inspect variables — hover or use the Scope pane to see live values at the current line.
• Read the call stack — the chain of function calls that got me here, clickable to jump to each frame.
• Watch expressions — pin specific variables or expressions and watch them change as I step.

The shift from console.log debugging to breakpoint debugging was the single biggest speedup in my workflow. console.log tells me a value at one line I guessed mattered; a breakpoint lets me stop and look around — at any variable, the stack, the scope — and then step forward one line at a time watching state evolve. For anything more complex than "what's this one value," breakpoints win.

The Console sits alongside Sources as a live REPL — I can type any expression and see its value in the current context. It's where quick console.log output lands and where I scratch-evaluate ("what does document.querySelector('.x') return right now?").

Memory: finding leaks

When the bug is "the tab's memory keeps climbing," Memory is the panel [3][4]. The technique that actually works:

1. Take a heap snapshot at a clean state.
2. Perform the suspected leaky action (open and close a view, navigate, repeat).
3. Force a garbage collection (the Memory panel has a button).
4. Take a second snapshot.
5. Compare the two — the delta shows what was allocated and not freed.

Each retained object shows its retainers — the reference path keeping it alive. That's the diagnostic that turns "memory is high" into "this specific listener on this specific element is holding this specific closure." The retainer chain is the answer to which reference path did I fail to cut — exactly the question the reachability model from the memory notes predicts.

Performance: why it's slow

When the bug is "the interaction janks," Performance is the panel [5]. I hit Record, perform the slow interaction, stop, and read the timeline — a flame chart showing which functions ran, for how long, and where the main thread was blocked. Long yellow tasks are JavaScript; long purple are layout/recalculation; the goal is finding the one function or layout pass eating the frame budget.

Lighthouse, accessible from DevTools, runs an automated audit across performance, accessibility, best practices, and SEO — a checklist of known issues with links to fix each. It's the right starting point for "I don't know what to optimize"; the Performance timeline is the right tool once I have a specific interaction to profile.

How I use this

The rule I keep is: name the failure mode, then open the panel. Wrong value or behavior → Sources with a breakpoint. Memory climbing → Memory panel, two snapshots, read the retainers. Slow or janky → Performance timeline, find the long task. Network or server suspicion → Network panel, check the request and its status. Console is always open as a scratchpad alongside whichever panel I'm in. The discipline of matching the tool to the question — instead of poking around hoping to stumble on the answer — is what made DevTools feel like a real instrument set rather than a wall of tabs.

References

[1] Chrome for Developers, "Chrome DevTools," 2024. [Online]. Available: https://developer.chrome.com/docs/devtools/

[2] Chrome for Developers, "Debug JavaScript with Chrome DevTools," 2024. [Online]. Available: https://developer.chrome.com/docs/devtools/javascript/

[3] DebugBear, "Debugging JavaScript memory leaks," 2022. [Online]. Available: https://www.debugbear.com/blog/debugging-javascript-memory-leaks

[4] Medium / Coding Blocks, "Catching memory leaks with Chrome DevTools," 2021. [Online]. Available: https://medium.com/coding-blocks/catching-memory-leaks-with-chrome-devtools-57b03acb6bb9

[5] Chrome for Developers, "Analyze runtime performance," 2024. [Online]. Available: https://developer.chrome.com/docs/devtools/performance