DEV Community

Why using just console.log in 2023 is a big no-no 🚀

Al - Naucode on December 07, 2022

Here are 5 must-know console object methods and tricks! Are you still using console.log for all your JavaScript debugging needs in 2023? It's tim...

Read full post

leob • Dec 8 '22

Great article, useful to know, but console.log isn't a "big no-no" at all, it just depends on how you use it - most of the time I just use it as a temporary statement to debug something, and when I'm done I delete it from my code :)

Leober Ramos • Dec 8 '22

Marketing bro, you have to know how to sell your post. Also, the man tries to talk about people who only use "console.log" and don't know the other methods that the JavaScript "console" object has.

But yes, console.log is also a good method and can be used together with these others, since although the others are good, for example to print any type of data on the console (boolean, object, string, etc.) it's better to use console.log.

leob • Dec 8 '22

Yeah you're right, the "big no-no" makes for a catchy title, it draws attention ... well yes, I purely insert console.log's to dump a piece of data in order to debug an issue, once I've solved it my console.log statement will be promptly deleted from the code ... anyway, these new console methods are definitely cool!

Al - Naucode • Dec 8 '22

Yeah, most people most of the time (even myself) will continue using the console.log. It is not a bad thing. This is just a way to raise some attention in other methods that sometimes we can use. I like to use for example the time and assert ones.

leob • Dec 8 '22

I've used the time one as well, it's great (to time a piece of 'synchronous' JS code)

Radu-Alexandru B • Dec 9 '22

Yes logging is very okay.
However in my most scenarios I just use console.debug() and console.error() instead (so most of the logging will be invisible to the end user -> "verbose" mode should be enabled in order to see the debug logs).

Here's an example of how I use logging most of the times:

  onBuildUrl(urlNewForm: NgForm) {
    const methodName = 'onBuildUrl()';

    console.debug(
      `${methodName} urlNewForm ${JSON.stringify(urlNewForm.value)}`
    );
    try {
      this.urlNew = new URL(urlNewForm.value.href);
      console.debug(`${methodName} New URL ${this.urlNew}`);
    } catch (error) {
      console.error(
        `${methodName} ${urlNewForm.value.href} is not a valid URL - ${error}`
      );
    }
  }

leob • Dec 9 '22

Yeah that could be very useful, especially if you could make the logs available in a production app (that would require some sort of periodic Ajax call to sync the logs to a backend) ... I assume that console.debug has negligible overhead if it's disabled/non-verbose?

Radu-Alexandru B • Dec 10 '22 • Edited

Yes, that's right. In production we should not only use console.log/debug/anything as they're only accessible on end-user's browser... instead, we should (also) use a proper Node.js logging library (that could provide full timestamps as well), such as the ones mentioned on this StackOverflow thread. (Also keep in mind that some apps should never use console.logging in the browser, as sensitive information could be shown/accessible by end user)

Also on end-user's browser, console.debug are still written on the console (eg. DevTools), but they are just not visible if "Verbose" is not checked from options.

wallace fares • Dec 13 '22

Yea I was gonna say the same thing, other than the cringy click baity title, the article is good as well

Rense Bakker • Dec 7 '22

Console assert is awesome! Doesn't polute your console when everything is running fine and gives you enough data to debug when something goes wrong

Al - Naucode • Dec 7 '22

Yeah! It is a really good method

Liftoff Studios • Dec 7 '22

Or better yet, Don't use console methods 😬, use the inbuilt browser debugger :)

Al - Naucode • Dec 7 '22

Even better! Although I find myself going back always to the usual console functions 😂

Oskar Pietrucha • Dec 8 '22

I just prefer to set a debugger and then do everything inside the Dev Tools and next on copy the insights to my code.
I think it's just I have a bigger overview on what is currently happening inside the app and browser.
I don't use console.log at all

Davide de Paolis • Dec 8 '22 • Edited

nice and very well written post.

using just console.log in 2023 is a big no no

it was already in 2020, and 2015... because you should debugging using other other tools!
these tricks are nice and neat (and definitely helpful sometimes) but if you really want to sharpen your axe please use a proper debugger and breakpoint (and conditional breakpoints) .

Nazim Ansari • Dec 8 '22

Great post! I totally agree that using just console.log in 2023 is a big no-no. With the rapid advancements in technology and the abundance of better debugging tools available, relying solely on console.log is not only inefficient but also outdated. Using more advanced debugging tools not only helps us find and fix errors faster, but also allows us to gain a deeper understanding of our code. Thanks for bringing this important topic to light!

Daniel Einars • Dec 7 '22

Oh man, those are a bunch of really useful console loggers! I knew some of them but not all!

Going to have to update my postfix completions

Al - Naucode • Dec 7 '22

Thanks for the amazing comment! I was also amazed when I found all of them!

Mohamed Ibrahim • Dec 7 '22

Awesome, Very useful article

Israel Ortuño • Dec 9 '22

Very great article

Kenji Elzerman • Dec 8 '22

I don't use front-end much in my work, but when I do I hate the Console.log. This article is awesome and learned me a lot!

Al - Naucode • Dec 8 '22

Thank you for the awesome comment!

Seth Dedrov • Dec 8 '22

very useful

m-alptekin • Dec 8 '22

Thanks. I was already using time console.time to have an idea on performance but for others I either had not used or didn’t know about… definitely a very beneficial content.

Al - Naucode • Dec 8 '22

Thank you! Yeah, time is really useful. I also like the assert one.

ismail courr • Dec 8 '22

Great article, Thanks for sharing

giadat1599 • Dec 8 '22

Nice post, those are really useful console loggers.

Al - Naucode • Dec 8 '22

Thanks!

Dao Huy Hoang • Dec 9 '22

Very awesome broo

Nerdy Deeds, LLC • Dec 29 '22

Okay, so, counterpoints:

Your build script/linter should be flagging console.'s before they ever touch your repo.
In those instances when one decides they should remain anyway, One should be able to rely on the developer using their own judgement.
There are copious extensions for nearly every IDE that sweep the code and either auto-comment-out or outright remove every console command within the file. I run one personally that git blames each, and, if I didn't write it personally, comments them all out and then collapses their lines, so they're not even visible to me. I do this, secure in the knowledge that NONE of them - mine OR other devs' - will ever see the light of prod, since:
Barring some VERY specific scenarios, END USERS should NEVER see your console output. If your deployment/minifier/uglifier doesn't scrub them you're (or more likely CICD) is doing something wrong.

Don't misunderstand me: it's a good review of console methods. But I would argue that ANY way you're using console is a no-no IN PRODUCTION, and PRIOR to Prod is a non-issue.

Uploadcare • Dec 28 '22

To be honest, all the methods described in the article were in browsers for ~10 years.

According to our experience, nobody uses them, because when you need just to log, console.log is enough. If it is not enough (e.g. for backend logs), you use some logging libraries like winston: github.com/winstonjs/winston

DB • Dec 9 '22

The best debugging tool is the one you know best. console.log offers nice out-of-the-box formatting and works fine in many situations, making it a far cry from a "big no-no".