Beyond console.log

There are about twenty, and a handful of them earn their place in real debugging work.

console.log("a message");
console.info("informational");
console.warn("something looks odd");
console.error("something failed");

console.group("Grouped output");
console.log("inside the group");
console.groupEnd();

// Timed output.
console.time("work");
for (let i = 0; i < 100000; i++) { /* do some work */ }
console.timeEnd("work");

// A table of objects.
console.table([
  { id: 1, name: "Ada" },
  { id: 2, name: "Bob" },
]);

// Counters.
console.count("iteration");
console.count("iteration");   // iteration: 2

console.assert(false, "this will be reported");

The two that save the most time are the table method and the timer methods. The table method renders a list of objects as an aligned table, so you can see all the fields of every row at once instead of scrolling through separate log lines. And console.time with console.timeEnd gives you a measured duration, which turns a vague claim that something is slow into a number you can compare before and after a change.

The grouping methods are for structure. When a function logs twenty things, wrapping them in a group with a label turns a wall of output into readable sections.

The count method is surprisingly useful. Add a count to the top of a branch and you can see at a glance whether that branch runs once or a hundred times, which answers a surprising number of bugs in a single line.

And console.assert logs a message only when the condition is false. It is not a replacement for a real assertion in a test suite, but it is a quick way to record an invariant while you are exploring code.

Because the console is a debugging interface, not a logging system, and the differences show up exactly when you need them most.

The first problem is that console output goes to standard output with no metadata. There is no timestamp, no severity, no request identifier and no service name, so when several instances are writing to the same place you cannot tell which line came from where or which lines belong to the same request.

The second is that the console API has no level control. Once a line is in the code it prints, forever, on every request. Production code is full of diagnostic logging that is useful once and then becomes noise, and the usual outcome is that people delete the logs or filter them with a fragile string match.

The third is that the format is not stable or machine readable. It is written for a human looking at a terminal, so it cannot be queried, indexed or alerted on. An error monitoring service needs structured JSON with a stack trace it can group by fingerprint, and the console cannot give you that.

The fourth is that most console methods are synchronous in some environments, so a tight loop that logs can block the event loop and slow the whole request down.

What to use instead. A structured logger that emits JSON, with levels, timestamps, and the ability to sample or silence noisy output. In Node, a logger built on the pino library is the common choice because it writes asynchronously and stays fast even under load. The console is still the right tool for local development, where its simplicity is a feature.

A structured logger is small: a level threshold, a shape for each entry, and a way to print it. This one is enough to show the design and easy to extend.

const LEVELS = { debug: 10, info: 20, warn: 30, error: 40 };

const createLogger = (name, threshold = LEVELS.info) => {
  const log = (level, message, meta) => {
    if (LEVELS[level] < threshold) return;

    const entry = {
      time: new Date().toISOString(),
      level,
      name,
      message,
      ...(meta ? { meta } : {}),
    };

    const line = JSON.stringify(entry);
    if (level === "error") console.error(line);
    else if (level === "warn") console.warn(line);
    else console.log(line);
  };

  return {
    debug: (m, meta) => log("debug", m, meta),
    info: (m, meta) => log("info", m, meta),
    warn: (m, meta) => log("warn", m, meta),
    error: (m, meta) => log("error", m, meta),
  };
};

const logger = createLogger("checkout", LEVELS.info);
logger.info("started", { orderId: 42 });
logger.error("payment failed", { orderId: 42, reason: "timeout" });
logger.debug("verbose detail");   // below the threshold, so nothing is printed

Three design decisions are visible here. The threshold is checked before the entry is built, so a filtered line costs almost nothing. The metadata is merged into the entry only when it exists, so you do not get a bunch of null fields in your logs. And each level goes to a different console method, so a log aggregator that reads standard error separately from standard output can treat errors differently.

A real logger would add a few more things. It would carry a request identifier so that every line from one request can be found. It would attach the current error when you log inside a catch block. And it would write asynchronously to avoid blocking the event loop, which is exactly why the popular Node loggers are built that way.

The last point is worth stating in an interview. The difference between a console call and a logger is not the formatting. It is that a logger has levels, context and a destination you can change without touching the code that produces the messages.