Debugging is one of the most time consuming tasks one can do while programming in my opinion. Debugging JavaScript that runs within a browser is the most time consuming and annoying tasks one has to do, period. Which is why I’m all for finding better ways to debug JavaScript within a browser. Here I’ll talk about some of the tips and tricks that I use to make debugging JavaScript within a browser a little less tedious and annoying (I’m not going to say fun, since debugging is rarely fun:)).
The first technique I employ is using alert statements. The alert statement pops up the dialog box with a message, that you as the programmer have inserted into the code. I use these to pinpoint where in the JavaScript code the script is failing so I can quickly get to the problem segment or method within the code. This makes a great first pass since you don’t need any specialized tools or add-ons to your browser for this to work. The problem is, you’re always rerunning your code in order to see where it fails once you make a change or in order to further pinpoint the problem section.
The second method I use is the Web Developer tool bar add-on for FireFox and Google Chrome. The Web Developer tool bar lets you inspect each element in the HTML and see all of its properties. This is extremely handy when scripts are changing properties of HTML elements; using it you can see if an element has changed it’s properties or not or if the property you’ve added has actually been added. The only downside to the Web Developer toolbar is that it doesn’t seem to work in real time. If you’ve made it display form details then run a JavaScript script that modifies the form details programmatically, the updates won’t be shown until you hide then redisplay the form details.
The third option, and the one I’ve grown most fond of recently, is using Safari and WebKit add-on. I’ve found this to be the nicest real-time debugger for JavaScript. With a simple selection of Develop->Start Debugging JavaScript from the menu button, a fully functional debugger is added to the bottom of the window and it allows you to set breakpoints, see the call stack and inspect all the elements being used within the JavaScript code being run. This has been the most helpful when I’ve located the method in which a problem is occurring, but can’t figure out why exactly it is happening. All it takes is setting a breakpoint, running the code to the breakpoint, then stepping through the code line-by-line and watching all the scope variables to see if one does not have the value I think it should. More often than not, I find out a variable is null or undefined when I thought it should have had a value.
The fourth option, I’ve used when debugging AJAX methods within my code. Using a tool called Fiddler, a web debugging proxy, I can intercept all messages being passed between the server and the browser and see exactly what is being passed in the AJAX commands. I’ve found Fiddler to be the most helpful when used in conjunction with another tool, like WebKit’s JavaScript debugger.
These four options do a very good job of helping me determine where errors are within the code and fixing them. When it comes to speeding up JavaScript, a JavaScript Profiler is what is needed. Safari with WebKit has a nice one that can be started with the Develop->Start Profiling JavaScript menu choice and FireFox has a nice one with the YSlow plugin. In the case of profilers, I find YSlow to be a bit nicer since it will profile the page and return hints on how to speed up the loading of the page. However, that doesn’t mean that Safari’s JavaScript profiler is worthless — I’ve used it an awful lot too. It does a very good job as well. Lastly, Fiddler has a very good profiler for determining the time it takes for various elements within the HTML to be transferred from server to client.
Hopefully these four options I’ve shown will give you a better idea of tools that can be used to debug and profile JavaScript in order to have bug-free code with a swiftly loading web page. If there are any other tools that I’ve missed, or debugging methods that you’ve found helpful, let me know in the comments section and I’ll update this page accordingly.