From Ajax Patterns
Tags: Capture Log Message Monitor Record
Dave's search engine keeps giving a blank result for certain queries. Fortunately, he had previously added some logging commands to see how the query is processed, so he makes the console visible and sets log level to verbose. Entering the query again, he now sees that one of the regular expressions is not matching it as expected.
How can you track program process?
$("log").innerHTML += "User searched for " + query + ".<br/>";
Even this simple implementation offers several benefits over the common alternative: debugging with an alertbox. Most importantly, the log element is a Popup: you can easily toggle visibility by dynamically switching CSS properties such as display, or even make it partly transparent. Further, logging is unobtrusive - there's no impact on application flow. Another benefit is that you have a history to consult when something goes wrong - no need to try replicating the problem.
Logging has an impact on performance, not just in DOM manipulation, but in producing the messages themselves. You can also end up with a memory problem unless some measure is taken to clear old messages, e.g. use a buffer to discard old messages.
Instead of logging to console, some developers output messages to the browser status bar (using window.status), and Firefox developers also have the option of outputting to the browser console. However, this limits portability and requires some configuration.
Will you log during production?
Most servers are configured to perform logging during production as well as development, so should the browser log too? In the past, the answer was usually no. But Ajax makes the case for browser logging more compelling, for two reasons. Firstly, with more logic in the browser, there's more things that can go wrong and need to be logged. Secondly, web remoting makes it possible to accumulate logs on the server, in a completely unobtrusive manner.
How will you change log settings between development and production?
Andre Lewis's JSLog is a lightweight, self-contained logging panel which takes the place of alert() boxes for your AJAX and DHTML apps. It is unobtrusive, easy to use, and can stay in your code through deployment. Requires just one .js file -- no additional markup required.
David Miller's  works similarly to Lumberjack. To use it, you just include a div with optional log level, and make calls like error("No such record.");.
log4js is based more closely on log4j than other frameworks. As well as various log levels, it supports pluggable logging strategies. Logging strategies include: do nothing; log to popup window; upload via XMLHttpRequest Call.
Bob Ippolito's Mochikit framework has a similar API to those mentioned above, and also adds features such as log listeners and a configurable message buffer. Interestingly, the standard way to launch the console is with a bookmarklet.
Facets Technologies Log Hound creates its own floating DIV user interface that allows you to search through the logs based on a wide range of criteria. Since Log Hound can be disabled on a global basis, there's never a need to remove the logging statements from your code.
Logger.info("Received " + patternNames.length + " pattern names."); ... Logger.debug("Received summary: " + summaryHTML.substring(0, 100) + "..."); ... Logger.info("Adding " + patternOption.value + " to playlist");