How do you debug JavaScript and React applications effectively?

Reach for the right tool for the bug class: logical bugs → DevTools breakpoints + React DevTools; perf → Performance/Profiler; network → Network tab + replays; production → source maps, error tracking, Replay/Sentry.

6 min read·~12 min to think through

A senior answer demonstrates a taxonomy — different bugs need different tools:

Logical bugs

Chrome Sources panel, set breakpoints (line, conditional, logpoint) — far better than console.log once you know where to stop.
React DevTools — inspect props/state, find which component re-rendered, profile renders.
debugger; statement when you need to land in the call from a build.

Performance

Performance panel for CPU/main-thread bottlenecks. Look for long tasks, layout thrash, GC.
React Profiler — flame graph of commits, find why a parent re-rendered.
Lighthouse + Web Vitals for end-user perception (LCP, INP, CLS).

Network

Network tab — payload sizes, waterfalls, blocking requests.
Replays (Sentry / FullStory) for "what did the user actually do" reproduction.

Memory

Heap snapshots, allocation-timeline. Look for detached DOM, growing arrays, retained closures.

Production

Source maps uploaded to error trackers (Sentry/Rollbar).
Structured logging with correlation IDs across server/client.
Feature flags to dark-launch and bisect regressions.

The mindset matters more than the tool: form a hypothesis, design a test that invalidates it, run it. Bugs that "happen sometimes" are state-dependent — capture the state, not just the symptom.

Code

// In Chrome DevTools, right-click the gutter at any line:
//   Add logpoint → "rendered with id=" + id
// Console output appears without modifying source.

Logpoints — better than throwaway console.logs

Follow-up questions

•How do you debug a memory leak in a long-running SPA?
•How do you reproduce a bug that only happens for one user in production?
•What does the React Profiler tell you that DevTools doesn't?

Common mistakes

•Throwing console.logs everywhere instead of setting a breakpoint with a condition.
•Profiling a debug build — measurements are dominated by dev-mode overhead.
•Treating React DevTools 'Highlight updates' as the source of truth — it shows commits, not wasted work.

Performance considerations

•Recording the Performance panel on a slow-CPU emulation reveals issues that disappear on M-series Macs.

Edge cases

•Strict Mode double-invokes effects in dev — looks like a bug, isn't.
•Source maps with code-mangling can mislead breakpoints; verify with the original file open.

Real-world examples

•Sentry + Replay reproduces a hydration mismatch by replaying the exact DOM before the error.

Senior engineer discussion

Senior signal: structured-logging + correlation IDs across services, Replay-style production debugging, and using feature flags + experiments to bisect regressions safely.