JavaScript Debugging with Chrome DevTools
A 3-part deep dive into the most powerful tool in every web developer's arsenal. Most developers use 5% of DevTools. This series covers the other 95%.
Why this talk matters
In 2013, Chrome DevTools was evolving rapidly but most developers only knew console.log. This 3-part workshop series was designed to change that.
Part 1 covered the Elements and Console panels in depth. Part 2 tackled Sources, breakpoints, and the debugger statement. Part 3 went into Network analysis, Performance profiling, and memory leak detection.
With 400+ views across the three parts, this became the most-viewed series on my SpeakerDeck. The content was practical: every concept was demonstrated on real code, with attendees following along on their own machines.
Key takeaways
- Breakpoints are more powerful than console.log. Conditional breakpoints, DOM breakpoints, and XHR breakpoints catch bugs that logging never will.
- The Network panel reveals performance bottlenecks that are invisible in your code. Waterfall charts tell stories that stack traces can't.
- Memory profiling is a skill every senior developer needs. Most memory leaks in JavaScript come from event listeners and closures that outlive their purpose.
- The Timeline (now Performance) panel is the key to understanding why your UI feels slow, even when your code looks fast.
This was one of my earliest workshop series, delivered at the tim.js meetup I co-organized in Timisoara. The format of 3 progressive sessions became a template I reused for years.