Wednesday, 22 December 2010

SP2010 AJAX part 6: Debugging jQuery/JavaScript

  1. Boiling jQuery down to the essentials (technique)
  2. Using the JavaScript Client OM to work with lists (technique)
  3. Using jQuery AJAX with a HTTP handler (technique)
  4. Returning JSON from a HTTP handler (technique)
  5. Enable Intellisense for Client OM and jQuery (tip)
  6. Debugging jQuery/JavaScript (tip) - this article
  7. Useful tools when building AJAX applications (tip)
  8. Migrating existing applications to jQuery/AJAX

In this ‘quick tip’ article I want to quickly introduce how to debug AJAX-type applications, then point you to a more detailed ‘debugging JavaScript’ article which I really like. Although every developer is (should be) comfortable with debugging their server-side .Net code, the advent of JavaScript-heavy applications means that new debugging techniques must be learned. Debugging script is typically done outside Visual Studio and as I see it you have two main options:

  • Use the IE Developer Tools (separate install required for IE7) and debug with IE
  • Use Firefox and install the hugely popular Firebug add-in

In many respects, the JavaScript debugging experience is fairly similar – you first select which of the .js files linked to the page should be debugged, then find the place in the code to add the breakpoint. When the code runs, the debugger will stop and allow you to step through (F10)/step into (F11) and also see/amend local variables and see the call stack etc.

In IE: (click on the images to see clearer versions)


In Firefox:


I think it’s a popular view that Firebug offers a better debugging experience than the IE tools – as the image shows, Firefox allows me to hover over a variable and see it’s value, and also gives me easy access to the ‘this’ variable in jQuery – neither of which the IE tools do. It’s possible to do many of the advanced debugging scenarios such as conditional breakpoints, set watch variables, and even break automatically on a JavaScript error. The ‘Console’ tab is also useful for analyzing the response over the wire from a HTTP module or the SharePoint Client OM – something you need to do frequently. Furthermore, as I showed in article 4, if the response is JSON then Firebug helps out by formatting the response into an expandable/collapsible view:


I’m a huge fan of Firebug, and I highly recommend digging into the other areas of functionality such as the ‘Net’ tab for analysing page load times (something I discussed in my Checklist for Optimizing SharePoint Sites article a while back).

To delve more fully into JavaScript debugging, Elijah Manor’s How to Debug your JavaScript code article should be considered required reading.

Next time: Useful tools when building AJAX applications (tip)

2 comments: said...

It's always surprising to me how many .NET developers pooh-pooh scripting, and I think a big driver of that is probably the debugging experience. It takes experience and skills that can be quite different than what you need for managed code, but that doesn't make it better or worse.

I flip back and forth between IE's Developer Tools and Firebug depending on what I'm doing; they both do some things better than the other. (Sounds like a good post!) If you are using Developer Tools, download Fiddler (free) as an adjunct tool to look at the HTTP traffic.

Great series!


Chris O'Brien said...


Agree with all that. And good reminder that IE Dev Tools do not show HTTP traffic so you need to use Fiddler or similar.