Published on January 5, 2018 by Chrome

If you’re still using console.log() to find and fix JavaScript issues, you might be spending more time debugging than you need to. This tutorial shows you how to make the most of Chrome DevTools so that you can debug your JavaScript as quickly as possible.

Demo: goo.gl/MwytjG
Doc version of this tutorial: goo.gl/NZxQdD
Breakpoints Guide: goo.gl/9XYhhF
JavaScript Debugging Reference: goo.gl/osaf2Q

Subscribe to the Google Chrome Developers channel: goo.gl/LLLNvf

Leave a Reply

64 Comments on "Chrome DevTools 101: Debugging JavaScript"

Notify of
avatar

Pinik Manob
Guest
Pinik Manob
14 days 1 hour ago

huh ! still console log is better than this shit

Vladhin
Guest
Vladhin
14 days 2 hours ago

Awesome, thanks! That's pretty helpful

Jan Borup Coyle
Guest
Jan Borup Coyle
14 days 9 hours ago

Thanks – Could very much have used this video many years ago, so very great for newbie debuggers.

vikash vikram
Guest
vikash vikram
14 days 13 hours ago

The video is awesome but I just wish my real life projects were this simple. Moreover, the real challenge arises when we have to deal with a web of callbacks and promises. Despite all the features, it seems I almost always have to fallback to console.log ☹️

Kayce Basques
Guest
Kayce Basques
12 days 3 hours ago

For sure, I hear you. If console.log() is a faster, more efficient workflow for you, then by all means use whatever works best for you. But we're always happy to hear your feedback and learn how to make DevTools useful for you. Regarding async code, the team has been doing work around making it more predictable when you step through async code. See link below. There's also a new stepping button (just called "Step") coming in Chrome 65. I believe that's also related to stepping through async code but I have to do more research.developers.google.com/web/updates/2017/05/devtools-release-notes#step-into-async

Franklin Waller
Guest
Franklin Waller
14 days 7 hours ago

Exactly this, alot of bugs come from timing issues or wrong handeling of promises, when break pointing you may create bugs that only appear in the debugger, or the bugs doesnt occur in the debugger. So for me console.log is also still the best option

Luis González
Guest
Luis González
14 days 16 hours ago

Nice!

Kayce Basques
Guest
Kayce Basques
12 days 3 hours ago

No YOU'RE nice!

Mister Zero
Guest
Mister Zero
14 days 18 hours ago

nice shirt

Kayce Basques
Guest
Kayce Basques
12 days 3 hours ago

Thank you, it was made in Ecuador, but I bought it in San Francisco 🙂

Nick Apperley
Guest
Nick Apperley
14 days 19 hours ago

Important to note that Chrome DevTools can also debug code written in a different programming language (eg Kotlin – kotlinlang.org/docs/tutorials/javascript/debugging-javascript/debugging-javascript.html ), provided source maps are supplied ( ).

Kayce Basques
Guest
Kayce Basques
12 days 3 hours ago

Awesome resources, thanks Nick. I'll have to check 'em out.

xabi
Guest
xabi
14 days 20 hours ago

Be careful with parseInt, you should pass a second parameter (in this case 10) cause we are working in base 10. Without this parameter is you pass “023” to parseInt it will be parsed as an octal number.

Kayce Basques
Guest
Kayce Basques
12 days 3 hours ago

Thanks for the tip!

Mohammed Sheriff
Guest
Mohammed Sheriff
14 days 21 hours ago

Everyone knows this years ago, but don't you do console.log info or warn in nodejs whenever you completed something? repl in nodejs and using chrome to debug nodejs code would be better examples. A bad code is always debugged. A good developer writes complete code with logging. Sorted your order of "thinking in code". medium.com/@paul_irish/debugging-node-js-nightlies-with-chrome-devtools-7c4a1b95ae27

Dimitar Nestorov
Guest
Dimitar Nestorov
14 days 22 hours ago

The event listener breakpoint was probably the worst one to show off since most of us use some type of framework which wraps event listeners and until you get to your code you would've console.logged the whole app 😁

Dimitar Nestorov
Guest
Dimitar Nestorov
8 days 16 minutes ago

This looks awesome, I will be trying it out. You might as well do a short video bringing some awareness to other web devs about this feature.

Kayce Basques
Guest
Kayce Basques
8 days 1 hour ago

I was just talking to the team about this yesterday and they mentioned that blackboxing should help with resolving the event listener breakpoints to the proper location. Have you tried that? developers.google.com/web/tools/chrome-devtools/javascript/reference#blackbox

Dimitar Nestorov
Guest
Dimitar Nestorov
14 days 21 hours ago
That's gonna be a tough one, you'll have to handle frameworks when added from CDNs, when being bundled, AMD, CommonJS… That starts to sound like a dream to have that feature. I advise everyone to start adding debugger statements instead of console.logs everywhere they would've added them, and they would most probably don't feel the need for event listener breakpoints. Also that way when doing cross browser testing of a certain feature you'll always break on the debugger and not whatever the DevTools of browser X gets you to (not to mention just finding their placement in the UI). People… Read more »
Kayce Basques
Guest
Kayce Basques
14 days 21 hours ago

Fair point. If anything we just need to make DevTools handle frameworks better so that Event Listener Breakpoints pause in the app code, not the framework wrappers.

wpDiscuz