With a script debugger, you can pop the hood and study exactly how things work — the catch being that the only really robust debuggers exist only for Internet Explorer and the Mozilla family of browsers. But that’s OK. You don’t really care about browser compatibility yet; you just want the darn thing to work.
The first time you open Venkman, you’ll be treated to a classic open-source interface that offers up eight panes in a single window. Don’t freak out just yet. You can rearrange the layout to your liking and get rid of the panes and elements you don’t care about. You can drag a pane around the window to rearrange things, and remove a pane entirely by clicking the X in its upper-right corner. To dock two panes together, drag one to the box on the left side of the other’s title bar and let go of the mouse button. The two panes will be joined, and you can toggle between them using tabs.
Venkman’s interface (Take a closer look)
The Loaded Scripts pane shows the script files currently loaded. By clicking the disclosure triangle beside a script file, you can browse to specific functions in the file. The Open Windows pane gives you a similar view, but further separates things by browser windows.
The Local Variables pane lets you peek at variable values as your code executes. More about this in a minute. The Watches and Breakpoints panes let you specify when to start debugging. And the Call Stack pane shows where you are in the code — that is, what function is executing and who called it.
That leaves two panes: Source Code, which shows your code as you debug, and Interactive Session, which gives you a command line to work with. You don’t have to use this pane at all, but if you’re interested in it, type
/help to get a command reference.
Alright, now let’s do some debugging.
The best way to jump into the debugger is to set a breakpoint. A breakpoint simply says, “When we reach this line, start debugging.” Let’s set one now.
Open our demo page and fire up Venkman. Look for demo.html in the Loaded Scripts pane. Look inside the file by clicking on the disclosure triangle and find the countTo function. Double-click that to pull it up in the Source Code pane.
See how in the left margin of the Source Code, there are dashes? Click the one beside the line that reads:
for (var i = 1; i <= number; i++)
The dash turns into a bright red B, indicating you’ve set a breakpoint. You can click it two more times to clear the breakpoint. (It toggles to an F along the way — this indicates a special kind of breakpoint that you don’t need to worry about just yet.) But leave it be for now and switch back to the regular browser window. Click the countTo button and it’ll throw you back to the debugger, only now you’ve frozen execution.
Notice that the Local Variables pane now shows our variables: i, number, and target. Because “target” is an object, you can dig into its properties like you did the source code files.
Venkman displaying object properties (Take a closer look)
You can use the debugger’s toolbar to control the flow of execution. The Continue button stops debugging entirely, and runs the rest of the script. The three Step buttons work in similar ways — they basically control whether you dive into subfunctions or not. Step Over skips past a subfunction call, while Step Into delves deeper. If you get too deep into things, use Step Out to jump up the next highest function call. If you click Step Out at a function that was invoked directly by the user, it acts just like the Continue button.
So go ahead and click Step Into a bunch of times. Watch how the i value changes as you loop through the for loop. Pretty nifty, eh? You don’t have to just sit there. Right-click the value of number and choose Change Value. Type in
14 and hit OK, then click Continue in the debugger toolbar. Indeed, it counts to 14 instead of 7. You can use this trick to simulate weird conditions in your script, or just to experiment to see how your script reacts.
Digging through an object to find a particular property can be cumbersome. Watches provide shortcuts to exactly the sliver of information you want to “watch” for. Right-click the empty space in the Watches pane and choose Add Watch Expression. Type in
target.innerHTML and hit OK. When you step through the countTo function again, you can watch innerHTML get written to.
Watches can evaluate any kind of expression at all. Add another watch, but this time type
(i == number). The debugger tells us it’s false. This is a pretty simple condition, but you could use similar ones to track all kinds of things while you step through your code. You can even save a set of watches for future reference. Just right-click the Values pane and choose Save Watch Settings. The item below it, Restore Break/Watch Settings, gets them back. Incidentally, there is a matching Save menu item for the Breakpoints pane.
Now that I’ve given you some toys to play with, go ahead and try them out with your own code. For more information on Venkman, try the official FAQ or even this guide, which goes into more detail than I have space for here.
Did you love this article? Did you hate it? Think you can do better? Send us your Feedback. Feedback submitted here will be considered for publication on Webmonkey or Wired News, so if you don’t want us to print your comments, please say so in your email.