Logs as a thinking tool A log is not just text output. It is a way to structure thinking when facing a bug. Before writing a log, it often helps to clearly define what needs to be verified. Providing context An isolated log is rarely enough. Context around the value is often what makes it … Read more
Interrupting or observing Breakpoints are useful, but they are not always the best first option. Pausing execution often breaks the natural reading of what is happening. The console allows another approach: observing without interrupting. Following the real execution flow With well placed logs, it becomes possible to follow the actual call sequence without freezing state. … Read more
A sentence that often hides an issue “It works on my machine” is rarely a satisfying conclusion. It often means something is still escaping observation. In the browser, the console plays a central role in this gap. It shows what happens locally, in a very specific context, with a state that may differ from another … Read more
What we think we see Reading an object in the console seems simple. You log it, expand it, and inspect its properties. In practice, what the console shows is not always what the code had at the exact moment of the log. This is a common source of confusion, especially when state changes quickly or … Read more
A simple tool, often misunderstood console.log is probably the most common instruction used to debug in the browser. It is also frequently criticized for being too basic or not “serious” enough. The issue is not the tool itself. It mostly comes from how it is used. A log added without a clear goal rarely provides … Read more
An already open tool When a bug shows up in the browser, my first reflex is not to open a heavy debugging tool. The console is already there. Often open, otherwise just a couple of clicks away. Over time, it has become my default entry point to understand what is happening in a web application. … Read more