The curse of console.log
Here’s a common scenario, you’re on-site demonstrating some fancy new Javascript interface you’ve written, only to discover that some part of it that was working so beautifully on your dev box inexplicably breaks. hmm you think, must be a bloody IE bug. You try it in Firefox.. it still doesn’t work, what the?!
Later that day you get home and on a hunch run a quick search through your source tree:
> ack ‘console.log’
www/extras/wobject/Survey/dd.js
96:console.log(destEl);
The culprit is Firebug’s console.log() function. The damn thing is just too handy. So handy that a few years ago the collective web development community abandoned alert() as the #1 debugging weapon of choice. Now we all use console.log(). Forget the firebug debugger, nobody can be bothered bringing up their js source in the script tab and clicking the break button or setting a watch variable, that’s like, 4 clicks too many man! Whack in a of console.log(a, b, c)s and it’s all there, plain as day in the firebug console, ready to be clicked on and examined further in the DOM tab.
Until you forget that not everyone in the world runs firebug. Hard to believe, I know. But actually, the problem occurs for anyone who hasn’t got the firebug console turned on for YOUR SITE. The problem being of course that you probably always have the firebug console turned on for your site, but no-one else in the world does. So the likelihood of being bitten are pretty high.
Of course, there are lots of workarounds. One approach is to just define console.log as an empty function (and while you’re at it, you may as well define all the other Firebug functions too):
if (!("console" in window) || !("firebug" in console)) {
var names = ["log", "debug", "info", "warn", "error", "assert", "dir", "dirxml", "group", "groupEnd", "time", "timeEnd", "count", "trace", "profile", "profileEnd"];
window.console = {};
for (var i = 0, len = names.length; i < len; ++i) {
window.console[names[i]] = function(){};
}
}
In my case the code was part of a drag and drop method used in WebGUI. And like all sane web projects, WebGUI oursources its cross-browser Javascript concerns to a library (in our case YUI). And it turns out YUI has a perfectly good logger of its own, guaranteed to be available on any page that YUI is loaded onto. Hello YAHOO.log();
Now, “YAHOO.log” is 1 letter shorter than “console.log”, so why does everyone end up using console.log() all the same? Maybe they don’t like typing in upper-case. More probably they noticed that when they use YAHOO.log(‘blah’); nothing appears in the firebug console. What gives? Well, you need to tell YAHOO to pass on log messages to the console, that’s what. Type the following line first, and everything will work out just fine:
YAHOO.widget.Logger.enableBrowserConsole();
Of course, that’s a lot more letters than just typing console.log(), and what’s more you need to use YAHOO.lang.dump() to serialise objects passed to log() (no nice firebug object examination), which admittedly is a lot less fun. But it does mean a little less broken code in production.
