In defense of console.log()…
Lately I’ve been seeing a ton of articles commenting about how console.log is terrible, no one should use it, and that there are better alternatives. For an extended period I’ve been indeed convinced of this indeed, and for the most part, console.log has shortcomings that other console methods adhere better to. But I don’t see too big of a problem using console.log. Hear me out though.
I know that by saying that I’ve probably attracted a huge number of pitchforks, and warranted as well. For this reason, I’d like to address the shortcomings and flaws of console.log. My goal with this article is to prevent people from feeling like resorting to console.log is frowned upon.
Can be tempting to log everything
Console.log gives values straight as they are in the console. I think this is probably the biggest thing, because it’s so easy to log strings, data, text, error messages, cases, etc. and by relying on .log for everything everything can get really complicated.
For more permanent logs, this is important to fix. Say you have unreachable cases, or fetch handling errors, manipulation errors, non-existing string, or error cases, you should probably log those as console.errors, especially if you want those errors to exist permanently.
In defense of .log, if you want to test cases, I don’t see why console.log isn’t fine. Say I’m testing a loading state, error state, and success state. I want to see what the data state is. I’ll log the data, regardless of what I get with console.log(data). From there I can get an insight of what I’m gonna get in certain cases that I’m testing, and build my solutions for those cases.
Context is crucial, but can be unclear/omitted
I feel like this is a big one. Again if you’re relying on logs to track things, often times you need to resort to adding strings or some kind of identifier to track your logging trail better. This might be a slight fix, but by using other methods you could probably see more info, such as with the trace method.
I think this is probably the reason why I’d suggest people look through all the possible methods and experiment with them first to see what they’d get using them, because a lot of methods are better to track steps or logs or whatever than console.log.
That said, if people feel more comfortable reading logs while they’re developing, I don’t see why people shouldn’t do it. After all, coding is all about legibility, and if developers read console.logs better than the rest, then might as well keep doing it.
I think for this specific case, however, even I recommend looking at other methods, especially if those logs are going to stay in your application, just to improve legibility.
Weak information
Console.logs often times omit, misrepresent, or confuse traces or stacks or information. If you want to see data, there are other ways to view the data that you get. Chrome is a browser that tracks a ton of things going on in the browser that are a lot more representative.
Just as an example, if you’re tracking an API call and you want to see what data you get, you could console.log a promise value, but you could also look for the call in the network tab.
Here is my first defense for console.logs. Again, as a temporary solution, console.logging results from an api call gives you a place where you can isolate specific data in this scenario away from the network tab. I’ve had experiences with a large application where a lot of API calls were being made, from sources like hotjar, fullstory, etc. mixed in with the data calls, and it made it difficult to track where the call’s output is that you’re looking for. Obviously once you spot the location of what you’re looking for a few times you’ll recognize it more often, but why bother getting used to it when you can isolate it in a log briefly just to see what you’re getting.
In this incident, I believe logs are fine for briefly checking what you’re getting. Again other methods might describe it better, but I still see no issue with logging data.
What I believe the problem is
Honestly, I see a ton of tutorials, docs, and courses that explicitly demonstrate the use of console.log to track progress, view split cases, and observe information. This causes people to forget other methods exist, and they then don’t bother learning other methods that might actually benefit these use cases better.
That said, a lot of articles out there bash the use of log in an effort to get people to use other tools or console methods. While I’m all for it, I believe calling console.log weak or broken or terrible is incredibly misleading. I love using console.log to just test out things. I do understand the issue with leaving them in, however.
Conclusion
I guess I’m a little troubled with seeing an email with every medium article bashing against my old friend console.log. Console.log outputs stuff to the console, not limiting the stuff it could log. The thing is that the console has other methods that are more specific as to what information it outputs and how it’s outputted.
My opinion is to use whatever you want during development, but when you’re done with the information, you should allocate information where it’s most appropriate. Let data stick in the network tab, provides warnings using console.warn, errors using console.error, and generic console messages using log/info. During development, when you’re doing something yourself, check the other methods out, but do whatever you like, but when other people are involved with a feature, consider legibility for them.
TL;DR, tools exist to be used, if you like your tool, why not keep using it, right? Would love to hear opinions from others, but this is my 2 cents on the whole thing I guess.
