Clean Up Debugging

I've come to depend on Firebug so much that I left behind a couple console.log messages while testing a project. Problem was, with Firebug disabled (or not installed as was the case with a client), the application was failing. Looking at the code, nothing seemed out of place. I tried disabling Firebug and true enough, it stopped working. Took me a couple minutes to realize the debug code was getting in the way.

I've gotten so used to looking for error messages in the bottom left, I'm not even sure what the JavaScript console in Firefox looks like anymore!

Published January 30, 2007
Categorized as JavaScript
Short URL:


24 Comments · RSS feed
Mohammad said on January 30, 2007

I had the same problem back in the day but still continue to use firebug. Still have that problem but now I pretty much send ajax and java related items to another programmer in our company.

Steve said on January 30, 2007

I know leaving debug code in production is not the best idea, but why not write a little wrapper function to test for the existence of the console object first. Something like:

function debug(msg)
if (typeof console != "undefined")

This way your debugging degrades gracefully and if you forget to remove a debug statement you are in the clear.

Paul R. Redmond said on January 30, 2007

Hey Jonathan, do you have any recommendations on learning how to use firebug effectively?

Jonathan Snook said on January 30, 2007

@Steve: yeah, I should probably do something like that. Plus, with the new firebug, I'm embedding less and less on the page which leads me to the next question.

@Paul: if you haven't already, I HIGHLY recommend you check out Joe's video in Yahoo! Theatre. The presentation is a little dry but the stuff Joe covers is absolutely awesome. I'm a heavy Firebug user and I discovered a bunch of new stuff from the video. Well worth it.

Tim McCormack said on January 30, 2007

You can pull in Firebug Lite, which will take care of all those little errors until the app is ready for deployment.

Mislav said on January 31, 2007

The wrapper function is safe, but I like to stick with the default API for debugging. What I do is write code at the beginning that defines the "console" object with empty methods if it is not already defined.

Colin Ramsay said on January 31, 2007

Joe has a script which can be used for this eventuality. It also has the side effect of allowing Firebug debugging to be used in other browsers:

Colin Ramsay said on January 31, 2007

Oops! Tim beat me to it!

Assaf said on January 31, 2007

frankly I don't understand what's all the fuss about, firebug has some nice features - but nothing essential to development.

  1. it's not like it replaces the text editor, each "live edit" I make there needs to be copied to the text editor as well.
  2. instead of "breaking points" why not jsut use alert("!") ?
  3. it's nice to visualize padding and margin before you finish a project to see if you did something wrong, but I can hardly see how that makes you stop using the firefox Javascript Console
Ara Pehlivanian said on January 31, 2007

LOL, I hear you... though I usually get a nasty error message in IE before we go to production. (That's because I've got IE set to display every error and I don't use Firebug Lite).

Jonathan Snook said on January 31, 2007

Unfortunately, Firebug Lite doesn't really solve my problem as I'm trying to mimic a production app. Using the debug function or console alternatives is probably the best bet.

@Assaf: alert's are annoying because they interrupt the flow of activity. Plus, firebug allows you to drill into various points, watch function calls and so much more. If you haven't checked out the Y! video I linked to above, I highly recommend you do. There's also a screencast floating around which is less impressive but honestly, Firebug saves me hours over and above what alert's could do.

Felix Geisendörfer said on January 31, 2007

@Steve: Why create a new debug() function? Solving this issue is a matter of 2 lines of code:

if (!console)
    var console = {log: function(){}, trace: function(){}, [...]};

[...] = other Firebug functions one uses that need to be silenced if Firebug is not present.

Jonathan: And if you want to make sure that even other web developers don't notice you forgot to remove your debugging code, you can even overwrite the 'console' element based on a production-mode switch you put in somewhere ; ).

Mr. Muskrat said on January 31, 2007

@Assaf: Alerts can break dynamic pages that rely upon things being asynchronous. An alert brings everything to a dead stop until you click the button which makes debugging a much longer and more difficult process in the end.

Steve said on January 31, 2007

@Felix: I hadn't thought of that and its definitely a bit nicer than creating a new function. Thanks for the tip.

Ara Pehlivanian said on January 31, 2007

I think the solution is to have a rigorous QA process prior to deployment. The QA test environment shouldn't have any of the development tools you use installed thus making it easy to pick up on a forgotton console.log() statement.

That's of course if you have a QA team and/or cycle.

Aaron Newton said on January 31, 2007

Hey Jonathan, I'd like to point you to two things:

1) we have a wrapper for firebug that lets you log statements but doesn't do anything until you enable it. It's tiny and stand-alone.

2) I'll also direct you to the Mootools Debugger.js file that emulates firebug for browsers without it (example of it in action). Very useful if you're trying to debug in something other than firefox.

Andy Kant said on January 31, 2007

I do something similar to Steve, except that I add a debug mode check. I also try to remember to do a search for any console references before I commit my changes to source control.

var $debug = false;
var $error = function(message) {
if ($debug) {
if (typeof console != 'undefined')
console.error('Error: ' + message);
throw(new Error('Error: ' + message));

Stu said on January 31, 2007

I discovered recently that Firebug will actually allow bad logic to run. I was putting together and knocked it together pretty quickly.

It worked on firefox on both my machines, but not IE. I just assumed it was IE (i mean, come on, surely it's the TOOL you blame, not the wielder .. heh)

Ended up being some bad javascript coding on my part, the misassignment of variables i think, which i later found out, Firebug was letting through.

After disabling Firebug, Firefox no longer ran either.

So there you go. I like Firebug .. it's a cool tool. But just that. Doesn't magically make me a better programmer.

Assaf said on January 31, 2007

@Jonathan, Mr. Muskrat: I like alerts because they stop everything, that way I can stop and see what happend in that same moment. I guess working with firebug is a matter of style.
by the way, I love the new comment box!

Matthew Pennell said on February 01, 2007

@Assaf: If you find that using alert() works for your debugging, I'd guess you're not working on anything more complicated than click events; as soon as you start trying to debug mousemove or mouseover events, alert becomes useless.

Thomas Messier said on February 01, 2007

Getting off the subject of console.log, one bit of advice: if you ever have an incomprehensible, impossible-to-solve javascript error that somebody keeps getting, try disabling firebug. It's only happened to me once, but I was pulling my hair out. Turns out Firebug was somehow suppressing the error. It's only happened to me once, but it's a good thing to keep in mind.

Jeff L said on February 01, 2007


I use a function that will log to the console when available, but put up an alert when it's not...

function cLog(str) {
if (typeof console == 'undefined') {
} else {

it doesn't allow for some of console.log's goodness like comma seperated values, but for 95% of my debugging needs it works fine, and allows me to debug in Firefox and IE at the same time without needing to change my code.

Daniel said on February 01, 2007

It's just like those C programs which don't work when the asserts are disabled. Javascript is a real language now.

I don't think it was clear from earlier comments, so for anyone who missed it, firebug lite also has an ignore console stuff thing. You can set up your build system to include it in release mode, it'll be great.

But if that isn't for you, I'm not sure if it's a good idea to remove your debugging code - you never know when it's going to be needed. Dean Edwards' triple semi-colon convention might be useful. But remember not to avoid any side effects in your debug code.

Aaron Bassett said on May 23, 2007

Well after being annoyed with the same thing for a while now I wrote a few little methods to stop my debug code from breaking scripts in IE etc

Its based heavily on Joe's firebugx.js I just wrapped it up in a prettier box :)
I put together 2 different versions 1 for prototype users and another for use without any other libraries. Both can be found here: Stop console undefined errors

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.