Debugging and Profiling JavaScript
Meaningless blabber
Before starting, I have to say that I am with you, all those that have been traumatized by Internet Explorer’s epic refusal to help JavaScript developers in their humble quest to debug code.
I personally think that IE hates JavaScript developers; I think that all the IE’s in the world have united into a secret masonic order that wants to rule the planet. They are the Axis of IEvil1 and their plan is:
“Let’s refuse those JavaScript bastards their rights to debugging. We will say that all errors are syntax errors and they all take place on line 1 at a random character; also we will ally with our friend Notepad which will refuse to show line numbers for all eternity. Thus, our evil plan will be complete! Mmbbuhuhohaha…”.
Disclaimer
Hey Microsoft, just (semi-)kidding. Let it be known that even though IE gives (at least to me) much grief in interpreting CSS and JavaScript, I do not hate it! I think this browser is well under way to becoming a mature and stable browser (version 7 is making good progress), and with the risk of sounding stupid, the only thing wrong with it is that it is not openly developed (Yes!, you heard me!).
Enough talk
So how do you properly debug JavaScript? Firefox provided much better error reporting than IE straight out-of-the-box, but still, this form of debugging can barely be called proper debugging at all (I’m not even mentioning profiling yet).
FireBug
The knight in shining armor to the rescue:
“Oh, save me,… save me FireBug!”
“Do not fear Milady JavaScript! I am here at your service!”
“Fear my wrath you wrongdoing errors! Prepare to meet your Maker!”
“Ha Ha…”
FireBug is (in my opinion) the best JavaScript debugging/profiling tool out there. It is the successor of the Venkman extension for the Firefox browser.
Many web developers use the FireBug extension to Mozilla Firefox in order to debug and profile their scripts. This is a very cool piece of software and I personally felt cold chills when, amongst the options in the small FireBug menu, I saw the word “Profile” written in the sub-menu of the Console section… uuuuuuhhh (See?, another one of those cold chills again). Also, it provides a lot more functions that are simply excellent (like real-time editing of CSS styles - how cool is that, people?).
Furthermore, while reading about FireBug on it’s page, I came across this piece of mind-bending information (click on the thumbnail on the right).Can this be real? Well, it is! And this is the place to explain:
http://www.getfirebug.com/lite.html
So as it turns out, there also exists an unobtrusive Lite FireBug JS script that allows one to benefit from a FireBug-like console on other browsers (bare in mind that this is only for the Console, and not the entire enchilada!).
So, for anyone who is interested to do serious, complex and optimized JavaScript work, know that this tool became indispensable to me.
But wait there’s more!
This is all fine for Firefox but what about all the other browsers out there (IE, Opera and Safari to name a few of the most popular ones).
Internet Explorer
IE Developer Toolbar tries to compensate for IE’s lack of debugging support and I think it does a pretty good job. It doesn’t raise up to the level of FireBug (and it doesn’t do profiling at all), but still, it’s a must for testing under IE.
For profiling under IE one can use the very smart JavaScript Profiler made by Stephen W. Cote. All these tools are not very intuitive to install but you get used to them pretty fast and they do the job.
Opera
The Opera developers have created a set of tools (again no profiling) for this browser, but (according to them) they are in alpha state. Use the link above to install the Opera development tools.
The following links also provide good insight on debugging under Opera:
http://www.hallvord.com/opera/jsdebug.htm
http://dev.opera.com/articles/view/how-to-debug-javascript-problems-with-op/
Safari
http://webkit.org/
http://webkit.org/blog/61/introducing-drosera/
Safari uses a rendering engine which is available as open source through the WebKit project. And part of this project is now the Drosera package (second link above) which is actually a development tools package for Safari. Again, no profler is available.
What about profiling man!
The best option I see is to use FireBug mainly and in paralell (though less often, at spread-out moments of development) the JavaScript Profiler script for IE (see above).
This one bugged me for a while and still does. I don’t know about you but the idea of using JavaScript based profilers to do the work simply doesn’t appeal to me. They’re slow and obtrusive (you have to write additional stuff in your scripts to profile them - disgusting). Only resort to obtrusive JavaScript profilers on very specific points in the code (i.e. when you know that a certain function is prone to bad performance and you want to test in every browser!).
Here is a profiling script for you (there are probably more out there and I ask you to add them through comments if you know of any):
http://a-hw.narod.ru/programs/cnt/scripts/profiler/index.html
In this article I only discuss tools that are browser related or integrated. Because of the fact that every browser provides a different implementation of JavaScript, naturally, profiling will be partly dependent on the target browser.
Lastly, if you want to use a generic tool that profiles JavaScript code, you can use Tito Web Studio (shareware and only for Windows). It might be useful for many developers out there.
If you know of a profiler designed for Opera or Safari (not a generic JavaScript one) please add it here. I would be very glad to hear about it.
- Along with the old lady that lives on the 3rd floor. She’s the mastermind behind it all, I just know it! ⇑
Enjoyed this post?, why not subscribe to the RSS feed!
January 18th, 2008 at 10:32 pm
I couldn’t agree more. I’ve got an application that works in FireFox but won’t in IE. Without tools like Firebug it’s brutally hard to determine the cause. Most of the IE debugging tools really lack in comparison and make the job very painful.
This makes me think that unless things change, most web developer (AJAX especially) will build for FF and support IE afterwards. This means that IE will continue to lose market share unless they can address this issue.