
Debugging Asynchronous JavaScript with Chrome DevTools - austengary
http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/
======
folz
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...](https://developers.google.com/chrome-developer-
tools/docs/javascript-debugging#breakpoints-on-javascript-event-listeners)

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

~~~
dang
Good guess.
[https://news.ycombinator.com/item?id=7628816](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
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
Are there any beginner tutorials for debugging events? Even simple ones?

~~~
paulirish
[https://developers.google.com/chrome-developer-
tools/docs/ja...](https://developers.google.com/chrome-developer-
tools/docs/javascript-debugging) gives a decent overview of the basics and
what you can do beyond that.

------
EmielMols
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](https://code.google.com/p/chromium/issues/detail?id=272416)

~~~
paulirish
We're evaluating this feature on
[http://crbug.com/332624](http://crbug.com/332624)

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

~~~
Cthulhu_
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
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.

~~~
exodust
The first gif on the page is more than 4MB.

You can do a lot better than animated gifs. No pausing or frame control,
forget about audio, limited colour palette, painful to make...

If you cram megabytes of this stuff onto a single page, don't expect everyone
to get the same framerate.

------
mrsaint
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
I still prefer Firebug; you're not alone! It's annoying to see more of the web
go Webkit only, though. Reminiscent of IE.

------
paulirish
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](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
No editor killed this comment. Spam filters pick up on some link shorteners
that spammers have used heavily on HN.

------
bilalq
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](https://github.com/angular/zone.js)

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

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

~~~
Cthulhu_
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
Would anyone know how to achieve this type of animation on the screenshots?
Love it!

~~~
frankblizzard
I have used [http://www.cockos.com/licecap/](http://www.cockos.com/licecap/)
to achieve this.

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

~~~
fusionflo
Thanks for sharing. Just tried it out, and looks great.

------
nraynaud
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
I know it took a while, but take another look: Chrome now has full console
support inside of workers: [http://crbug.com/63383](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
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.

------
jakubmal
How would you tackle named functions in coffeescript?

------
Achshar
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.

~~~
acdanger
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_
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
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
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
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)

