There’s sometimes a tribal attitude about how web developers should be debugging their code and solving problems. There’s the console.log loyalists, then there’s the debugger/breakpoint maximalists. I worked on the Firefox DevTools debugger for years and I can tell you my philosophy — use whichever tool helps you get the job done!
I use console.log for very simple problems, other times when I want an audit trail I can analyze after a series of events to spot the problem and share with others. I use breakpoints when I want to halt execution to to see values and the visual state of the UI. One tool you can use to get the best of both worlds is logpoints, a breakpoint-like mechanism in the devtools debugger that logs instead of halts!
To add a logpoint:
- open the devtools debugger
- right-click a line number in a JavaScript file,
- provide the log message accompanied by any variables you’d like in the
log:
You have access to all variables in the current context, which you can add to the logpoint message.
You may be asking “why don’t you just add a console.log to your source file manually? Oftentimes you need to debug third party scripts where manually editing the file isn’t possible. Even if you do have access to the source file, you don’t need to do a bunch of console.log cleanup!
Developer tools are always more popular than believe — take full advantage of them!
MooTools Window Object Dumping
Ever want to see all of the information stored within the window property of your browser? Here’s your chance. The XHTML We need a wrapper DIV that we’ll consider a console. The CSS I like making this look like a command-line console. The MooTools JavaScript Depending on what you have loaded…
GitHub-Style Sliding Links
GitHub seems to change a lot but not really change at all, if that makes any sense; the updates come often but are always fairly small. I spotted one of the most recent updates on the pull request page. Links to long branch…