Live data from Hacker News

Debugging Asynchronous JavaScript with Chrome DevTools

html5rocks.com

41–50 of 50 posts

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#42

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.

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

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#43
post #3

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.

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

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#45

Earlier quoted context omitted.

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.

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.

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.

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#46
post #23

Earlier quoted context omitted.

Well, HN itself is a poll.

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

I don't understand your concern. Skip the thread if it has no relevance to you.

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#47

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

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

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#48

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!)

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

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#49
post #12

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

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

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.

Re: Debugging Asynchronous JavaScript with Chrome DevTools

#50

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.

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?

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#.
Post reply on HN