3 ms·

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 critic

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.

bcrescimanno 15y ago
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.
- jarek-foksa 15y ago
  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.
  - bcrescimanno 15y ago
    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.
  - epidemian 15y ago
    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 :)
masklinn 15y ago
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.
- adrianparsons 15y ago
  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.
  - masklinn 15y ago
    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)
    - latchkey 15y ago
      That doesn't work if you are using CoffeeScript which has no direct line translation. 'debugger' is the best way that I've found.
      - adrianparsons 15y ago
        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 https://github.com/sstephenson/sprockets

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.

bcrescimanno 15y ago

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.

jarek-foksa 15y ago
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.
- bcrescimanno 15y ago
  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.
- epidemian 15y ago
  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 :)

masklinn 15y ago

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.

adrianparsons 15y ago
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.
- masklinn 15y ago
  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)
  - latchkey 15y ago
    That doesn't work if you are using CoffeeScript which has no direct line translation. 'debugger' is the best way that I've found.
    - adrianparsons 15y ago
      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 https://github.com/sstephenson/sprockets