Wednesday, October 15th, 2008

Say Goodbye to alert()

Category: JavaScript

Blackbird, G. Scott Olson’s JavaScript logging library, truly has a catchy slogan. The slogan “Say hello to Blackbird and ‘goodbye’ to alert()” definitely captures what the Blackbird library aims to do; make logging messages in JavaScript extremely easy. And setup is very easy. By incorporating the following lines of code, you’ve now added the ability to set checkpoints which will display specific data you’re interested in:

  1. <html>
  2.   <head>
  3.     <script type="text/javascript" src="/PATH/TO/blackbird.js"></script>
  4.     <link type="text/css" rel="Stylesheet" href="/PATH/TO/blackbird.css" />
  5.     ...
  6.   </head>
  7. </html>

From there, its a simple matter of using Blackbird’s methods to send results to the console:


  1. log.debug( 'this is a debug message' );
  2. 'this is an info message' );
  3. log.warn( 'this is a warning message' );
  4. log.error( 'this is an error message' );

The nice thing is that each of these public methods uniquely displays the data to make it easy to determine the type of message being sent:

Blackbird has been tested in:

  • Internet Explorer 6+
  • Firefox 2+
  • Safari 2+
  • Opera 9.5

Brian Dillard was one of the first to announce this release and has also done a nice writeup of Blackbird.

Posted by Rey Bango at 2:25 pm

3.2 rating from 39 votes


Comments feed TrackBack URI

Why not use Firebug lite and stick with console.log?

Comment by mattpowell — October 15, 2008

Pretty nice… Firebug is a more useful tool, even in IE you can use firebug lite.

Comment by whoisyeco — October 15, 2008

“say goodbye to alert” in-case it didn’t hear you 2 years ago.

Comment by Dougal85 — October 15, 2008


Comment by ThomasHansen — October 15, 2008

If debugging, I personally wouldn’t want more code in my page than the bare minimum Which includes FireBug Lite.Whatever happened to using textarea.value+=”foo”? I must be the only one left who still does that on occasion ;)

Comment by TNO — October 15, 2008

It looks pretty… but seems useless compared to Firebug. Pretty icons, but firebug gives me object representations.

You can only log strings?

Comment by seanmonstar — October 15, 2008

I think one of the appealing features is a profiler that allows you to time the execution of your JavaScript. You can call log.profile( ‘label’ ), once to start your profiler and again to stop it.

Object representation and regular expression filtering are on tap for later releases.

I’m surprised nobody has argued for log4javascript

Comment by gscottolson — October 15, 2008

LOL nerds hate when people reinvent the wheel slightly differently.

This actually looks pretty cool, IMO.

Comment by eyelidlessness — October 15, 2008

The UI is a nice consideration. Any utility that gives console.log/warn/error-style debugging that works nicely across Firefox+Firebug, Safari and IE is a good thing, even if it’s been done before (a la Firebug lite.) The ability to filter could be quite useful.

Comment by Schill — October 15, 2008

The reason I continued to use this utility even after the advent of Firebug Lite was the ability to filter log messages selectively. That and the nicer UI (pinning the console to different positions in the window) make for an intuitive utility.

My problem with Firebug Lite is that when I install it in a dev project, it trips up over the real Firebug in Firefox. I end up with two console windows which drives me crazy. I end up having to comment out Firebug Lite when I am debugging in FF, then un-comment it in other browsers. It’s a real drag. Anyone else have that problem?

At any rate, Firebug is super-functional, but its UI is dense and inflexible for my tastes. Competition on UI, not just features, can only enliven the JavaScript debugging arms race – in which case we all win.

Comment by bdillard — October 15, 2008

One more vote for log4javascript, love that one for its feature set:
Ajax log appender, inline regex search and filter, new window mode, etc.

Comment by zachleat — October 15, 2008

You should use LocalScroll :)

Comment by Flesler — October 15, 2008

I’m writing about a problem with log points in js files.

alert, log.* and console.log are ok when you develop, but you don’t want them in your code when you deploy in production. You also don’t want your customers to download yet another js file from your server (i.e. blackbird.js) especially if they’re not meant to see log messages anyway.

Most web frameworks makes it easy to embed the script src tag into a check for production vs. development environment, so that’s part of the problem is solved. I can think about many ways to remove the log points from the static js files but can anybody suggest me a simple and proven way to do it? Thanks!

Comment by pmontrasio — October 16, 2008

@pmontrasio I use an ANT Build Script to minify my JS and CSS files automatically using a single command. I have a string /*RM*/ that I put at the beginning of a line that signifies a line of JS or CSS I want removed prior to minification, and I just use ANT to find and remove those lines.

Comment by zachleat — October 16, 2008

Once you stuff the log with information the profiler doesn’t work correct anymore, I punched like a moron on the test buttons loading up the log and the profilers time kept increasing, until i cleared the log again…

Comment by V1 — October 16, 2008

“Once you stuff the log with information the profiler doesn’t work correct anymore”
Thats because everytime you hit one of the demo buttons, the profiler for example, you add 14 new elements to the document which means that a task like document.getElementsByTagName( ‘A’ ); will take increasingly longer to perform.

Comment by JesperSjoquist — October 16, 2008

Just noting: Dojo has firebuglite out of the box, is used only in debug mode, doesn’t show up with a real firebug present, and console.* commands can be stripped as a build option during the automated minification process (which does whitespace, css, comments, and variable obfuscation) with no special syntax around the function calls (though that is supported in the build, too).

The UI is nicer here though.

Comment by phiggins — October 16, 2008

Wouldn’t it be great if, instead of just a raw logging facility, the Ajax frameworks themselves actually made use a logging, providing built-in diagnostics in various categories? So that if you were troubleshooting, say, layout, you could turn on a “layout” category and see messages explaining how the layout policies were being applied? Or for event handling, enable an “eventHandling” category to see events bubbling up the logical component model?
Part of SmartClient since 2001..

Comment by ckendrick — October 17, 2008



Comment by jzshmyt — October 18, 2008

This works for me:
if(window.console && console.firebug) { alert = function(e) { console.log(e); } }

Comment by andersonjc — October 21, 2008

Another vote for log4javascript here. But then I did write it.

Seriously, does no-one know it exists?

Comment by timdown — November 4, 2008

Leave a comment

You must be logged in to post a comment.