Hacker News new | past | comments | ask | show | jobs | submit login

I would add one very useful hint which was not mentioned in Paul's videos: place the word "debugger" (without quotes) anywhere in your script to set a breakpoint.

I'm always surprised more people don't know this. I haven't seen it any books and only occasionally in tutorials.

I use it dozens of times a day -- it's critical for writing and understanding JS.

Breakpoints, yes. But many folks (myself included) set the breakpoints in the debugger itself--you don't have to put that line into your code to set a breakpoint.

Since some folks write JS that has to go through a "build" process, it's easier to set a breakpoint in the debugger than to go back, modify the code, and "re-build" to get a breakpoint.

It would be even easier if you could just fix the build system.

If you are worried to modify your code because of the long build process then the build system probably needs rethinking - make sure that only the files that were modified are rebuilt, configure your text editor so that it runs build script on file save.

It's not that it's long, it's that it has to be done at all. Even without a build process (or one like ours that takes at most 5-10 seconds) it still takes longer than finding the line of code you're concerned about and setting a breakpoint within the debugger itself.

To each there own as to how setting breakpoints works best for them in their workflow--my only reason for commenting was to let people know there were other ways to set breakpoints than adding "debugger" lines all over their code.

Another reason to use breakpoints in the debugger itself, when doing client-side development, is that you usually don't need to refresh the page (well, you may have to, if the breakpoint is in a piece of code that executes only on page load). You set the breakpoint, trigger the action that executes that code (or call it from the console) and you're already debugging :)

Setting it from the debugger window itself is simpler, allows for setting a conditional breakpoint and allows for disabling (temporarily or completely) the breakpoint without having to source-edit and reload the page.

The debugger also lists all breakpoints set through it, which lets you easily jump to them.

For complex/single page applications, the `debugger` pseudo-keyword is not quite that good.

I have a lot of trouble finding the desired code block in, say Firebug or Chrome dev tools. Especially if a page has multiple concatenated JS files. The search box is helpful, but often unreliable.

If I'm working with the code in a text editor, it's usually easier for me to find the code block in the text editor and type 'debugger' rather than root around in the dev tools.

Both WDT and Firebug let you jump to a given line. In Firebug, type # followed by the line number in the search box.

In the WDT, there's a keystroke which you should be able to find (it's command-L in Safari)

That doesn't work if you are using CoffeeScript which has no direct line translation. 'debugger' is the best way that I've found.

Similarly, we concatenate our JS with sprockets[0] -- so what's on line 50 of module.js in the pre-compiled code base may be on line 1350 of app.js in the browser.

0 : https://github.com/sstephenson/sprockets

Can't believe I wasn't even aware of this. I've been manually setting breakpoints for years... Thank you!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact