This recipe doesn't really rely on specific code, but if you want to be able to reproduce exactly what's going on, grab the previous recipe's code.

What makes debugging client side script hard is that the web client heavily relies on jQuery's asynchronous events. Given that breakpoints halt execution, the chance is high that a bug caused by timing issues will not occur when debugging. We'll discuss some strategies for this later:

All of this relies on your browser offering appropriate functionality for debugging. While all the major browsers do that, we'll only look at Chromium here for demonstration purposes. To be able to use the debug tools, open them by clicking the top-right menu button and selecting More tools | Developer tools:

When the debugger is opened, you should see something similar to the following screenshot:

Here, you have access to a lot of different tools in the separate tabs. The currently active tab in the screenshot is the JavaScript debugger, where we set a breakpoint in line 31 by clicking on the line number. Every time our widget fetches the list of users, execution should stop at this line and the debugger allows you to inspect variables or change their value. Within the watch list to the right, you can also call functions to try out their effects without having to continuously save your script file and reload the page.

The debugger statements described above will behave the same as soon as you have the developer tools open: execution will stop and the browser will switch to the Sources tab, with the file in question opened and the line with the debugger statement highlighted.

The two logging possibilities from above will end up in the tab Console. This is the first tab you should inspect in case of problems anyways, because if some JavaScript code doesn't load at all because of syntax errors or similar fundamental problems, you'll see an error message there explaining what's going on.

Use the Elements tab to inspect the DOM representation of the page the browser currently displays. This will prove helpful to make yourself familiar with the HTML code existing widgets produce, but also allows you to play with classes and CSS attributes in general. This is a great resource for testing layout changes.

The Network tab gives you an overview which requests the current page made and how long it took. This is helpful to debug slow page loads, as you'll usually see the culprit in one glance here, represented by a long bar. Then you can check on the server side why this call takes as long as it does. Also, this view helps you to determine if it makes sense to parallelize calls; this would look like several long bars, one after another. If you select a request, you can inspect the payload passed to the server and the result returned, which helps you to figure out the reason for unexpected behavior on the client side. You'll also see the status codes of requests made, for example 404, in case a resource can't be found, for example because you misspelled a file name.

For other browsers, you'll have to look up similar functionality in the documentation. Firefox for example has the very powerful firebug addon, which lets you perform most of the mentioned actions.

As stated above, debugging becomes complicated as soon as asynchronous operations are involved. Breakpoints are of limited use here because they interrupt code execution and the call stack won't contain the place where an event handler was attached, but mostly internal jQuery functions and the browser's implementation of the event system. The Profiling tab helps you here by showing call graphs, including timings. This can hint at event handlers being called in the wrong order. Another strategy is to spread out console.log statements throughout your handlers in order to plot a sort of call graph in the JavaScript console. Before diving into this, have a critical look at all your custom code in order to check if you forgot to return super's result in case it is a deferred object. This is a very common cause of timing problems.