Logging - Ajax Patterns


From Ajax Patterns

Evidence: 1/3

Tags: Capture Log Message Monitor Record


Goal Story

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?


Instrument your Javascript with log messages. Typically, the page contains a div element especially for logging, and each significant action is appended there, e.g.:

  $("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.

Inspired by libraries such as log4j, Javascript logging libraries provide some sort of filtering. Typically, a message is tagged with a priority level, e.g. "debug" or "info" or "error". You can then choose to see only messages above a certain level.

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.

Another approach gaining traction is to embrace Web Remoting and upload the data to a logging Web Service Ajax - more specifically XMLHttpRequest - has been labelled a technique for "spying on users" (http://www.devx.com/webdev/Article/28861). However, techniques for remote logging have been available for a long time. The main impact of Ajax is to increase browser-based interaction, which might create further incentives to log user activity. See http://www.softwareas.com/spying-on-users-with-xmlhttprequest.. This allows permanent storage of the logs, and can also be combined with server-side logs to paint a detailed picture of each interaction. Eric Pascarello, for example, has proposed the technique for usability testing. log4javascript and log4js both support an XMLHttpRequest-driven logging strategy. The benefits of remote logging must be balanced against concerns for user's privacy and consent.


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?

In server-side logging systems, log settings are usually altered by applying environment-specific filters - e.g. in development, all messages are shown; whereas in production, only messages at information level above are shown. But a familiar performance problem then arises: even though debug messages aren't being logged, the arguments must nevertheless be constructed, which takes time. A common solution is to include "if-then" statements to check the log level, an unfortunate idiom that obsures the real point of code. Since Javascript is generated by the server, you can do better than that: configure things so that log commands aren't even spit out in the first place. How you do this depends on the server-side environment. For example, a JSP developer could develop a Javascript logging tag whose implementation dynamically inspects the logging configuration.

Tool Support


log4javascript is a JavaScript logging framework based on the Java logging framework log4j. It features a powerful pop-up or in-page logging console, server logging via Ajax, flexible formatting and can be set up with default options in one line of JavaScript. It is extremely well tested across all major modern browsers (Firefox/Mozilla, IE5+ (Windows), Safari 1.3+, Opera 7.5+ (8.01+ for Ajax support), Konqueror 3.4.3+).


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.


Corey Johnson's Lumberjack is a Javascript logging framework which supports logging at different levels. There's no setup required, because it creates the logging div itself, so you can immediately issue calls like Logger.info("User logged in."). The console is initially hidden, and you can toggle visibility with Alt-D.


David Miller's [1] 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.

Log Hound

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.


Firebug , the excellent web development extension for Firefox also includes a AJAX call and general javascript logger that can be emulated for non-firefox browsers easily. (see ff javascript library for an example of this )

Tool Illustration

The Basic Ajax Pattern Reader is refactored here to include logging with Lumberjack. Lumberjack's logger.js is included, and the code has then been instrumented to include log messages:

  Logger.info("Received " + patternNames.length + " pattern names.");
  Logger.debug("Received summary: " + summaryHTML.substring(0, 100) + "...");
  Logger.info("Adding " + patternOption.value + " to playlist");

Related Patterns


Want to Know More?