Pro Tip: ‘debugger’ statements cannot be disabled at runtime
In Chrome, you can just press the "Deactivate Breakpoints" button in the DevTools and `debugger` statements won't do anything anymore. Closing the DevTools also prevents `debugger` statements from breaking execution.
You can also trigger the debugger only if certain conditions exist. This is helpful if you are trying to fix a bug in a code branch that is hit very often, but the bug only happens under certain conditions.
1) I have the code open in my text editor but not in the inspector. Rather than open it in the inspector and search around for where I need the breakpoint I can just pop it in the code and the inspector will open up where I need it.
2) Working with single page apps where breakpoints sometimes have a hard time persisting after a file changes. Nothing more frustrating than making a change and losing your breakpoints.
Just to preempt certain comments, I realize that many people have known this for ages, but there are many who have not, and to them this might just make their day.
Since ecmascript 5, Date.now() is the standard way of doing this. Generally speaking, I'd prefer to do that (with shims for older browsers) than do the equivalent of creating a new Date object and calling .valueOf on it (which is what +new Date does).
I don't it'll be much of a concern in a few years, though we're not there yet. Currently, Chrome will just gloss over any debugger statements unless the dev tools is open; if others happen to follow suit, then leaving a debugger statement in won't have any side-effects.
Sorry if I gave that impression! What I meant to refer to was that you can insert them somewhere in a loop and then disable it once the loops ran a few times rather than having to press continue (potentially) several hundred times.
In Chrome, you can just press the "Deactivate Breakpoints" button in the DevTools and `debugger` statements won't do anything anymore. Closing the DevTools also prevents `debugger` statements from breaking execution.