Stop Overusing Console.log in JavaScript

Bilde av artikkel forfatter
Skrevet av: Marius Ibsen

The web browser console gives us more options than just the console.log()

Image of a road sign containing the text: Watch out! overuse detected

OK, I admit it, and I’m not very a fan of it. Mostly I use console.log() for troubleshooting, checking that the arguments of a function get the correct values or that a function returns what I expect it to do. Sometimes I take shortcuts using the built-in browser method console.log() to clarify the result of some piece of code. On infrequent occasions, instead of rendering a ReactJS-component to the Graphical User Interface (GUI), I may print the component to the console to examine its properties.

I’ve seen many developers are using the web console in similar ways as I do. We developers should stop overusing the console.log() and instead draw advantages from what we can do with the web console than just reading simple logs.

I want to discuss some common issues and bad habits that we usually do and some solutions for using the console better.

Issues and bad habits

How often do we think about why we use the console.log() method, and in what contexts? Is it just purely automatic that we use it? Why do we always have to do all this logging, especially with console.log()?

In many of these situations, instead of reading and understanding the code, we make guesses and try to help ourselves by logging stuff to the console. All this time we spend on logging can be very time-consuming (sometimes it can even make us even more confused), and we probably “learn” slower.

Unnecessary logging = less confidence

An unnecessary amount of logging to the console makes us less confident. Developers often log to the console in many parts of the code — especially if functions are deeply chained — to “test” our code is reliable.

Using the console for “confirmation”

In far too many cases, we also accept that when logging something to the console, we get an indication that “everything works fine.” We can prevent building agents or scripts from breaking if we read and understand the code thoroughly instead of relying on the “confirmation” that the console may give us.

We often use this “confirmation” to check whether something is wrong or not, whether an object is undefined or an array has a length. I would say that “confirmation” is OK when our code breaks, and there are no other options.

Debugging is time-consuming

Debugging in the console may be time-consuming. Sometimes we can sit for days logging things to the console, taking away the focus on understanding how the code “actually” works and other options that we could have tried instead of just logging stuff.

Logs may end up in production

Logging to the console can be deployed in production, which is not always that great — especially if we log critical information that should not be available to “everyone” on the web.

How we should use the web console

What is essential to know is that the console also is a REPL. That means we can interact with JavaScript on the page we’re inspecting. Using the REPL is a great way to play with and learn JavaScript.

Using the console REPL to add textContent to an HTML element with a wordmark CSS-selector. Here we add a string “Hello” above the Firefox logo.

Useful console methods

The overusedconsole.log() is just one of many methods we may call on the console object. console.error(),, and console.warn() may be better in cases where we will separate different states of messages. And, to get a better representation of our data in the console we can use methods like and console.table().

console.error(): Prints an error message to the console, where the printed content will have a red colour. Most browsers also displays an error icon beside the console message.

console.error(‘Something is wrong’)

console.warn(): Prints a warning message to the console, where the printed content will have a yellow color. Most browser also displays an warning icon beside the console message.

console.warn(‘Heads up! This is a warning’)

Illustration: console.warn example in Firefox. console message with a yellow triangle containing an exclamation mark Prints a group of console methods executed within the group. Such logging is usable when we need to do more than a single log in different files which is not related. We can also open and close groups in the console.‘feature’)
console.warn(‘Heads up! This is a warning’)
console.error(‘Something is wrong’)
Illustration: example in Firefox. console messages grouped within a console group called “feature.”

console.table(): Prints a table representation of the data provided. The method accepts objects and arrays.

console.table([{ a: 1, b: 2 }])

Illustration: console.table example in Firefox. console messages are displayed in a table representation

Some final words

It’s not uncommon [for JavaScript beginners and professionals] to just print strings that say “works” or “done” or something similar and then use them to “confirm” that our code works as expected. I’ve seen far too many uses of console.log() in different places in a codebase simultaneously during a pair programming session.

Browser consoles are great tools, and we should use the great utils they provide to our benefit; testing JavaScript methods or extracts, playing with Document Object Model (DOM) or objects in our code. We can do much more with the console than log simple strings, numbers, or lengths on a list.

We should focus on understanding the underlying code and using the console for its benefits and not as a tool for confirmation; then, we will learn faster, become more confident and write better code in the future.

Thanks for reading

Code foh shizzle

Stop Overusing Console.log in JavaScript was originally published in Dfind Consulting on Medium, where people are continuing the conversation by highlighting and responding to this story.