Debugging Asynchronous JavaScript with Chrome DevTools

Debugging Asynchronous JavaScript with Chrome DevTools(html5rocks.com)

220 points by austengary 12 years ago | 48 comments

folz 12 years ago |

Comment from Paul Irish, who is marked [dead]:

Protip with this feature: It can resolve where you originally bound your event listeners, regardless of if you used jQuery or whatever. So, either set up a breakpoint or establish an Event Listener Breakpoint[1] and you can walk back to where you registered the handler.

[1]: https://developers.google.com/chrome-developer-tools/docs/ja...

tricolon 12 years ago | |

I'd guess that Paul's comment was killed because he used a shortened URL.

dang 12 years ago | | |

Good guess. https://news.ycombinator.com/item?id=7628816

All: one reason we ask you to email us at hn@ycombinator.com instead of posting about [dead] comments here is that it guarantees that we'll see the question. I only saw this by accident 10 hours later. There are too many threads for us to read them all.

acdanger 12 years ago |

This looks great. Debugging simple 'click' events has always been a non-trivial task for me -- doubly so on touch devices where an a 'click' event can have a range of unpredictable side effects.

m00t 12 years ago | |

Are there any beginner tutorials for debugging events? Even simple ones?

paulirish 12 years ago | | |

https://developers.google.com/chrome-developer-tools/docs/ja... gives a decent overview of the basics and what you can do beyond that.

_navaneethan 12 years ago | | |

http://www.html5rocks.com/en/tutorials/es6/promises/

ionwake 12 years ago | |

"non-trivial"

You can just say "hard"

EmielMols 12 years ago |

It would have been interesting to be able to setup your own stack links (e.g. by collecting Error().stack, and being able to update this at any other point - Error.setStack?). A heap of 3rd party promise/observer/animation/etc libraries could use such a feature to ease debugging. The current implementation does not allow for this [1].

[1] https://code.google.com/p/chromium/issues/detail?id=272416

paulirish 12 years ago | |

We're evaluating this feature on http://crbug.com/332624

math0ne 12 years ago |

Very nicely produced article, i love the use of animated gifs that is becoming popular for tech demos.

Cthulhu_ 12 years ago | |

I think it's odd, to be honest, given the existence of the html5 video tag. Of course, last time I checked, there wasn't a standardized video codec yet, which would make it tl;dr for authors.

mschuster91 12 years ago | | |

gifs have the advantage of working on lower-resource devices (cellphones, netbooks) without any delay.

youtube and other "feature-rich" sites work only with massive stuttering for me, so I'm happy for any gif instead of a video which needs to be set up and torn down for every play.

mrsaint 12 years ago |

Wow, this is seriously cool! No doubt it will mean more switching back and for between Firebug and Chrome DevTools. Or am I the last one still using Firebug?

CalRobert 12 years ago | |

I still prefer Firebug; you're not alone! It's annoying to see more of the web go Webkit only, though. Reminiscent of IE.

scribu 12 years ago | |

I use Firebug too, mostly because you can see in-progress AJAX requests in the console.

paulirish 12 years ago |

Protip with this feature: It can resolve where you originally bound your event listeners, regardless of if you used jQuery or whatever. So, either set up a breakpoint or establish an Event Listener Breakpoint (http://goo.gl/YYlbDK) and you can walk back to where you registered the handler.

(Yeah, no idea why an editor killed this comment. :/ Thanks folz!)

dang 12 years ago | |

No editor killed this comment. Spam filters pick up on some link shorteners that spammers have used heavily on HN.

bilalq 12 years ago |

This is super cool. With respect to debugging at least, this gives you a similar trace to what you'd get with the Zone.js library[1] it seems. Having this kind of thing baked into the JS engine is great.

[1]: https://github.com/angular/zone.js

roskilli 12 years ago |

Now if only they could make a standalone IDE backed by chrome dev tools! Then I could use it for Node too :D

balls187 12 years ago | |

Have you tried Node-Inspector[1]?

With it, you can use Chrome Dev Tools to debug your nodejs app.

[1] https://github.com/node-inspector/node-inspector

krisgenre 12 years ago | |

GitHub's Atom ( though its an editor, not IDE ) is backed by chrome dev tools I think.

Cthulhu_ 12 years ago | | |

Atom's walking a thin line between editor and IDE, to be honest; it definitely has the base layer (= plugin support) to become the next Eclipse.

fusionflo 12 years ago |

Would anyone know how to achieve this type of animation on the screenshots? Love it!

frankblizzard 12 years ago | |

I have used http://www.cockos.com/licecap/ to achieve this.

thousande 12 years ago | | |

I have been looking for something like this for OS-X. This is excellent.

nraynaud 12 years ago |

I'd like a real console object in worker (at least a variadic pretty-printing log() function and time()/timeEnd()) and a "break all threads" button too, please. Worker debugging is a pain.

paulirish 12 years ago | |

I know it took a while, but take another look: Chrome now has full console support inside of workers: http://crbug.com/63383

Right now, we're doing a bunch of work (hah) on our worker support. We'll address pausing execution in workers as well. Expect good improvements and file a ticket at crbug.com for any other ideas, please!

nraynaud 12 years ago | | |

I don't get it, 10h ago I still didn't have the fancy console.log() in workers (34.0.1847.116). Maybe there is a difference between the per worker debugger and the page global debugger, but my worker are transients (I do heavy computation without stopping the UI thread), so using the per worker debugger is not really practical.

Flenser 12 years ago | |

if you're debugging in chrome but also running in browsers that don't support console.log in workers you can use this polyfill:

https://github.com/paulmillr/console-polyfill/blob/master/in...

jakubmal 12 years ago |

How would you tackle named functions in coffeescript?

Achshar 12 years ago |

Wasn't this possible already? Put a breakpoint or 'breakpoint;' on the function body's first line and it will pause execution when the function is called synchronously or asynchronously. And browse the call stack on the right column. What's new here? I have been doing this for quite sometime.

paulirish 12 years ago | |

Asynchronous hops have never been traceable in JavaScript callstacks before. This feature allows you to hop across the asynchronous gap of a bunch of APIs: addEventListener, setInterval, setTimeout, XMLHttpRequest, promises, requestAnimationFrame, and MutationObservers.

More visually, check out the Before/After images from the doc: http://imgur.com/rZlgrMe

EricDeb 12 years ago | |

The difference (I believe) is in the stack trace depth, specifically that the trace doesn't die if it happens to go through an async event. You can see in the first gif that if the async box is checked it allows a developer to see the stack trace all the way back to when the form submit event was initiated, despite the fact that an async ajax call was made in the middle of the stack. Normally, the stack trace stops at a response to an async event. You can see this in the beginning of the gif without the async box checked.

acdanger 12 years ago | |

This assumes you know the function that's being triggered. It's not always clear. And throw JQuery into the mix and things get murkier pretty quickly.

Cthulhu_ 12 years ago | | |

A means to group entries in a call stack together would be neat too; in most cases, something you're tracing won't be an issue in jquery or your library, so collapsing those would be neat.

jmspring 12 years ago |

Willing to take the rep hit...

Is HN really so focused on front end that this particular topic finds itself rapidly at the top of news feed and staying there for an extended amount of time?

Has there been a recent poll about topics active HN viewers deem as important? If it really is this JS heavy, that is intriguing.

etherealG 12 years ago | |

I think the core idea here is beyond the javascript it's implemented in. I've never seen a debugger that can do this kind of async debugging before anywhere.

Don't you think it's more novel than being some trick only relevant to front end web development work?

NickPollard 12 years ago | | |

At the ScalaX conference last year, someone demoed the Scala plugin for Eclipse debugging actor messages asynchronously, so you can breakpoint on receiving a message, then see the callstack that generated that message on a different actor, and in fact follow back through all the messages leading up to that. Very cool, though I haven't tried it in production yet (I'm currently using IntelliJ for Scala)

BrandonLive 12 years ago | | |

You must not use Visual Studio (or IE). Not only do both of those already do this for JS, but VS does the same thing for C++ and C#.

coldtea 12 years ago | |

>Has there been a recent poll about topics active HN viewers deem as important?

There's an ongoing, full-time poll, based on voting up posts.

phektus 12 years ago | |

Well, HN itself is a poll.

jmspring 12 years ago | | |

True. The frontend/js focus is a tad disappointing considering how many other technologies are involved in ramping up/running most companies.