Getting Started with JavaScript Debugging

Scripting has become an entire class of web development unto itself. With modern day libraries prominently including jQuery we are seeing more HTML/CSS developers taking an interest in coding JavaScript. Admittedly it can be tough to handle at first, especially when it comes to JavaScript code debugging. How you deal with bugs and errors is a true sign for your skills as a programmer.

If you’re just getting started then it can be daunting to look at all the tutorials out there. In this article I want to offer just a few basic techniques for debugging your JavaScript code. You can’t expect the same techniques to work all the time. Just be patient with yourself and through practice this technique of debugging will become much clearer.

Working with Developer Tools

The two most popular development browsers (Firefox and Chrome) both offer a set of tools you can use to manage the DOM. Both offer a DOM inspector as well as a console window. Using the console you can output variables and information stored in JavaScript. You could compare this to the terminal window for a PHP application.

A decade ago in the old days most JavaScript developers would output their questionable code into an alert dialog box. You could test variables and see if you are getting the proper response from a server script. However dealing with these alert messages interrupts the flow of your script, and may cause more issues than it would fix.

console.error('1');
console.info('2');
console.log('3');
console.warn('4');

Instead we can now output any variables we need via the console.log() method. Opera, Safari, Firefox, and Chrome should all be okay with this console window display. Some versions of Internet Explorer may cause trouble, but testing your code in another browser first is a safer bet. With Internet Explorer it's best to start elsewhere and work backwards for compatibility.

Online Code Debuggers

Along with your browser-based tools there are websites you can use for checking code syntax. One of my favorite examples is jsFiddle which you can run from any modern browser. There are some good tutorials about the site which you can find searching through Google.

Another alternative is JSLint which is built around debugging JavaScript code. You can copy/paste and execute the script to determine which errors are being thrown. There are also additional settings you can change to accept new rules for operators and regular expressions. This can be more complicated for beginners - but as a standalone tool it's the best reference!

Practicing Breakpoints

This term breakpoint is thrown around often when discussing JavaScript debugging. A breakpoint is simply a line in your code where the execution halts and you can examine performance up to that section.

In Chrome and Firebug you have tools available for checking each of the breakpoints in your script. The output window will display a set of breakpoints tuned to each individual script in your webpage. This is probably the more sophisticated way to debug issues since you don't need to add any more JavaScript. Check out the Chrome developer's documentation on breakpoints to understand a bit more.

alert('1st time');
debugger;
alert('2nd time');

The code above should also work without doing anything to the console window. The JavaScript command debugger; automatically places a breakpoint at that line in your script. I find this method slightly dated since we can use more advanced browser plugins to manage these points. However try out both methods and gauge how you feel.

In fact breakpoints may not even be useful in many of your scripts! Each situation is very diverse when it comes to writing, implementing, and testing JavaScript.

jQuery Ajax Errors

The XMLHttpRequest Object is a very popular method of passing dynamic data. The web 2.0 boom has clearly come and gone, leaving us somewhere in the middle of a new technological revolution while still molding previous models. jQuery has fantastic documentation on their .ajax() method which can be implemented using any backend script.

But debugging the responses can be gruesome! I'm most familiar coding in PHP - however any backend language such as Ruby or Python would be equally effective. Whenever you call an Ajax method you have to manage two(2) event handlers - on success and on failure. Each event would trigger a different function call where you can manipulate the return data.

$.ajax({
    type: "POST",
    url: "myscript.php",
    data: myform.serialize(),
    success: function(data, textStatus) {
        // on success manage the call
    },
    error: function(xhr, textStatus, err) {
      alert("readyState: "+xhr.readyState+"\n xhrStatus: "+xhr.status);
      alert("responseText: "+xhr.responseText);
    }
});

There are a few different values we can pull from this code. If you would rather use alert() to display errors this is fine in basic instances of debugging. However the console is a more modern approach. You can also gather HTTP header information from the browser without displaying any new data.

xhr - the XMLHttpRequest object. Needed to connect asynchronous data from the server to the frontend.
textStatus - returns a string describing the error which occurred. Possible values may include "timeout", "abort", "parsererror", etc.
xhr.status - the server status returned from our failed connection. Ex. 404 = not found, 500 = internal server error. A status of 200 means everything connected successfully.
xhr.readyState - the current state of the Ajax request numbered 1-4. 1=loading, 2=loaded, 3=processing, 4=complete.

I personally just work with the textStatus and xhr.status values. Between these two error handlers I can manage to figure out if the backend script is having issues, or if my JavaScript code is the problem. From there you can at least narrow down which file you're looking into and run some more detailed tests.

The Power of Resting

I am like many developers and always want to keep coding for hours on end no breaks allowed. Unfortunately this is the worst mentality you can have going into scripting. Even taking five or ten minutes away from the monitor can give you a fresh start coming back to the code.

There have been plenty of times where I've misspelled a variable name or called a method which wasn't declared yet. When you get wrapped up in line after line of code you tend to miss out on these smaller details. And unfortunately these are the details you end up stressing over trying to determine why things won't work!

Definitely give yourself some time between squashing bugs to relax and think about something else. Eat some food, watch TV, hang out with friends, whatever is needed to stop worrying about your code.

However I would argue that it's perfectly fine to go over some solutions in your head. Often times I'll come up with a great idea for debugging something and implement it once I get back to the computer - and viola! You'd be surprised how many issues can be fixed with just a bit of mental clarity away from the computer.

Advanced Reading

These ideas are just something to get you started on the path to coding & debugging JavaScript. Nobody is perfect and we're all prone to errors. Along with my suggestions you can check out some of these related articles below. I have found powerful inspiration skimming through the ideas of other like-minded developers.

Final Thoughts

Coding in JavaScript is one of the most lucrative activities you could adopt. You aren't even required to build code on a web server, and nowadays there are even powerful online code IDEs where you can write JavaScript with just an Internet connection.

As you practice these debugging techniques you'll get a deeper understanding of how JavaScript performs. As a language it can be verbose, although the open source movement has been generating cleaner and cleaner code. Ultimately it's about the learning process and how you grow as a web developer. If you've got any ideas or questions feel free to share with us in the discussion area below.