One of the more cumbersome development tasks is debugging client-side JavaScript code. Tools such as Firebug are helpful, but in the case of Firebug, you’re forced to use Firefox. Thankfully, Visual Studio 2008 provides a robust and developer-friendly environment for debugging JavaScript.


Whenever I hear developers discuss the JavaScript debugger features in Visual Studio 2008, I notice that they’re quick to point out that this type of functionality has been available in prior versions of the Visual Studio IDE for a long time. This is certainly true, but the improvements in Visual Studio 2008 make it much simpler to use.

The irritating aspect of JavaScript debugging in Visual Studio 2005 is that you have to first execute the application before any breakpoints can be created in your JavaScript. This approach has been modified in Visual Studio 2008 to allow breakpoints to be defined in the source code before the application runs. In fact, you can set them in both your C#/VB.NET code as well as JavaScript. So, when the application is run, you can step through all breakpoints regardless of the code.


With Visual Studio 2008 installed, there is one additional requirement for enabling JavaScript debugging: Internet Explorer must have script debugging enabled. This setting is available via the Tools | Internet Options menu within Internet Explorer. Once the Internet Options dialog box is open, select the Advanced tab and the Disable Script Debugging option is located in the Browsing section. It should not be checked so that it is enabled. Figure A shows the Disable Script Debugging option deselected.
Figure A

Figure A: Enabling script debugging in Internet Explorer

With debugging feature enabled in Internet Explorer, you can start debugging your JavaScript code.


The JavaScript debugger presents many standard debugging features. The following list provides a review of some of these features.

  • Breakpoints: Breakpoints allow you to stop code execution at specific points within the source code. JavaScript breakpoints work just like C#/VB breakpoints.

    Breakpoints are set/cleared by clicking to the left of the code within the IDE; by using the Debug menu or by using the Breakpoint Context menu available by right-clicking on the code. In addition, you may create conditional breakpoints to allow you to define conditions for the breakpoint, as well as set up a macro to run or a message to print when the breakpoint is triggered.

    Breakpoints are viewable in the Watch window located by default in the lower left of Visual Studio 2008.

  • Call Stack: The Call Stack tab in the lower right of Visual Studio 2008 allows you to view what is being called when the ASP.NET page is loaded/running.
  • Locals: The Locals tab in the lower left of Visual Studio 2008 allows you to view the values of variables and objects during script execution. Also, you may change the contents of one of the local variables while the page is running.
  • Execute code: The Immediate Window tab in the lower right of Visual Studio 2008 allows you to execute JavaScript code on-the-fly during page execution.

The Debug drop-down menu within Visual Studio 2008 provides a Windows submenu that allows you to define what windows to display while debugging. The examples in this article use Locals, Watch, Call Stack, and Immediate Window.

The most used feature during debugging is often breakpoints because you can use them to stop code execution and examine the state of variables and objects at that point in the script. Breakpoints provide a number of features (which are available via the Debug drop-down menu during a debugging session) for their use.

Code execution stops at each breakpoint — unless it is a conditional breakpoint whose condition has not been met. Once the code is halted, you may choose to continue one line at a time or until the next breakpoint is encountered.

The debugger is actually enabled via the Debug menu in Visual Studio 2008. You go to Debug | Start to begin a debugging session or press [F5]. A picture is worth a thousand words, so let’s take a closer look at actually using the debugger.

In action

For a simple example, I have an ASP.NET page that includes three JavaScript functions. One function populates a DIV tag on the page with text passed to it. The second function displays text passed to it in a pop-up window via the alert function. The last function populates a DIV tag with the text “Loaded”; this function is called when the page first loads.

Figure B shows this page running in debug mode. A breakpoint has been set on the line that populates a local variable with the contents of a DIV tag on the page. The red circle to the left of the line lets you know that it is a breakpoint. The line of code waiting to run is highlighted in yellow.
Figure B

Figure B: Sample page opened for debugging in Visual Studio 2008

Also, a watch has been set on the divText variable, so the many properties associated with it are displayed in the Watch window at the bottom of the screen. Watches have been greatly enhanced in Visual Studio 2008 to include much more detail. You can now view runtime object’s methods and events, as well as property and property type information.

Dynamic nature

A unique feature of JavaScript is its dynamic nature, whereas the code actually loaded in the browser when an application runs is often different than what is in the IDE. That is, the code is often generated as scripts may be stored as resources, loaded from other locations, or contained within other compiled controls.

The Script Documents feature of Visual Studio 2008 allows you to easily keep an eye on what is loaded and where it originated. While debugging, the Script Documents node will appear within the Solution Explorer pane. It will include the URL of each resource loaded into the page. It is visible in the upper right of Figure B.

Another note on the dynamic nature of JavaScript is the setting of breakpoints in the source code. Visual Studio 2008 automatically maps the breakpoint location to the dynamically generated page loaded in the browser. Likewise, if you set breakpoints in the executing page, the IDE performs the reverse mapping to update the breakpoints in the source code.

Take a peek

Debugging is an essential aspect of every developer’s job. Debugging standard code has never been a problem, but working with JavaScript has always presented problems. Visual Studio 2008 eases the burden with an enhanced debugger that simplifies the chore of taking a look at what your JavaScript is actually doing at runtime.

What tools do you use to work with JavaScript? Do you plan on using Visual Studio 2008 to work with JavaScript now or in the future? Share your thoughts with the Web Developer community.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.


Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!