Don't Fear node.js console.log()

Logging is a good thing! However, there is a lot of confusion around Node.JS console.log(), and if it should or should not be used.

The problem is not console.log(), but rather how 'stdout' I/O is handled. Standard Output I/O can be blocking or non-blocking. If run from a terminal, the default is to run in a blocking manner, and this blocking can cause things to run slowly.

Consider the script:

for (x=0; x<100000; x++) {
    console.log("Hello world, lets make I/O that goes to stdout and is very repetitive but fluffy")
}

Try running this two different ways:

time node bench.js 
time node bench.js > /dev/null

When I run this on a remote server, the first run takes 3.25 seconds, but the second only takes 0.41 seconds. The reason is because in the second instance, the Standard Output file handle is setup in non-blocking I/O mode, but the first is in blocking mode--meaning it must wait for my remote host to receive the I/O (If run on a local desktop you will probably see a smaller delta between the two, because there is less to wait for).

Your service should run in production with stdout non-blocking, if you are running it properly.

The conclusion is that you should not fear console.log() because it will cause performance problems. You should ignore any blogger who suggests it is good practice to remove console.log() for this reason. Having good logging is good. Big data is great! Using raw console.log() may still not be a good option simply because it is limited and hard to control. Instead, find a good logging module that verifies the output stream is unbuffered (whether it is going to local file or remote socket is frankly roughly equivalent).