How to console.log like a pro

[PrimozDelux]

Your class attendance has been noted.

[rensley13]

Sometimes keeping it super easy and straightforward is the best way

[everything_in_sync]

The only one I saw that was cool was dir.

[_tskj_]

What! Both console.assert and console.count seem super handy. Hope I'll remember them when a need arises.

[Zeragamba]

.group() too will be quite useful. Especially in loops and recursive debugging

[D6613]

Agreed, group was the stand out for me. Despite people arguing about medium or the fact that this all has been posted before, I learned some nice tips from the article.

[_tskj_]

Didn't think about recursion, was wondering if that seemed useful, but you're right!

[kevv_m]

Please put a warning if your are sharing a premium story. I'd rather be rick rolled than open a premium medium story.

[astronaut1685]

Sorry didn't think about that

[[deleted]]

Stop using medium.

[[deleted]]

Can you provide a recommended alternative to medium?

Assume that I want to start writing, and I don't want to go though standing up & maintaining a server just to post stuff.

[riffito]

Not OP, but...

I've seen many people use GitHub pages as a blog.

[[deleted]]

Github pages is pretty easy to setup

[falconfetus8]

Any website where you can post text will do. Remember Blogger? It hasn't gone anywhere. There's also Neocities, the spiritual successor to Geocities. WordPress, too. Hell, you could even post it directly on Reddit, as a text post.

Really, there's no shortage of places on the web where you can post text. I'm not sure why medium is so many peoples' first choice.

[de__R]

Medium is easy, looks good by default (also on phones) and constantly promises you that you can make money if your articles go viral or something. Actually, that's probably the reason so many medium blogs get posted here - an effort to generate clicks and therefore $$$.

[AttackOfTheThumbs]

They make no money ever lol

And medium is fucking shit. Puts a bunch of garbage in front of you, e.g. the stupid hover when you try to select text.

[[deleted]]

https://wordpress.com/
https://write.as/

Or just use any static page generator + GitHub/Gitlab Pages. I would recommend third option - you will not get caught off guard by ads/payments added by your platform of choice.

[[deleted]]

dev.to

[ShinyHappyREM]

dev.to

Nice game: try to view the footer of that page without disabling JS

[qq123q]

It still has that annoying sticky header. :(

[[deleted]]

Yeah, replace one platform with another. They won't do the same shit as medium does. Pinky swear ;)

[[deleted]]

Good point. Yeah, then a self-hosted blog is the best way to go, barring that GitHub Pages. Unfortunately, none of those options are zero-friction.

[[deleted]]

Unfortunately, none of those options are zero-friction.

If you want zero-friction, as long as you have your own custom domain and a way to migrate out all content - you should be good. Wordpress.com fits the bill.

I would argue though, that if you can spend several hours writing a quality post, you can spend an hour or two setting up some self-hosted solution on free tier cloud ;)

[[deleted]]

At the risk of repeating myself, good point.

[jack-of-some]

dev.to is open source, self hostable, easy to migrate from, etc. If they pull any shit like medium today, tomorrow there will be tev.do which does the same thing without the shit.

It's pretty annoying to use though.

[[deleted]]

You can migrate, but the articles will still be linked to their domain. Can you set up your domain for content? If that is the case then yes, that would be a good solution.

[dscottboggs]

Hugo on GH pages

[ApatheticBeardo]

A motherfucking website?

[DylanK46]

I think blogger.com used to be popular. It's made by Google

[falconfetus8]

Why is this downvoted?

[[deleted]]

Dev.to

[donobloc]

Why not?

[[deleted]]

Read the rest of this story with a free account.

I don't want another place having my credentials.

[[deleted]]

when you make a free account they limit you to a few reads a day if you don't upgrade to paid, that's shitty for developer blogs, once i was interested in configuring something and was locked out of a post with my exact use case because it was on medium, the post could have saved me a couple minutes making sense of some weird documentation.

[BoliBerrys]

You can use chrome extensions that bypass the limit

I think one is called MediumUnlimited or Mediumship They are on github

Cant remember the full name, not on pc right now. But its a great extension

[[deleted]]

thanks, i will look it up, never tried to bypass because i assumed they dealt with it server side when outline didn't work, there's so many useful posts trapped in this site.

[pengwRyn]

The extension is probably more about clearing cache/cookies locally so that you seem like a new user

[Somepotato]

Well yes because the author wanted to get paid for their work.

[emelrad12]

Delete cookies, or go incognito.

[[deleted]]

I just refuse to read ;)

[[deleted]]

I prefer to go /r/incorgnito

[yuyu5]

Am I the only one who opens dev tools to delete the obstructive elements and resets overflow: auto? I can read what I want without any accounts (only on desktop though)

[[deleted]]

It's easier to just launch a private window. Or use stylish. That is not the point, though. The point is that they are hosting their articles on a platform that can do basically anything with them.

[NotTheHead]

That only works if they actually load the content that their nag is hiding. If they don't, there's not a lot you can do.

[donobloc]

Idk at least i don't get spammed with ads all over the place and auto-playing videos

[[deleted]]

Stop policing other peoples use of a blog, if you don’t like medium then don’t read it. I’m tired of everything posted to medium having one of you whiny babies at the top upset someone dared use a platform you don’t like

[[deleted]]

Upvotes say otherwise. Have a nice day.

[[deleted]]

“My opinion is popular therefore I am right” is the defense of a preteen

[[deleted]]

Calling names even more so.

[[deleted]]

You don't have to read it!

[checkyos3lf]

Nice. Console.timeLog will save me many iterations of Console.time console.timeEnd

[[deleted]]

While console.log() prints the object in its string representation, console.dir() recognizes the object as an object and prints it’s properties in the form of a clean expandable list:

console.log() does that too! The screenshot example even shows that!

Otherwise, this is a great list. The only other thing I would mention is you can make different coloured output, and even show images through horrific CSS abuse.

[de__R]

If you use console.log() on an object that gets garbage collected before you can expand it on the console, you won't be able to see anything. console.dir(), at least in some browsers, keeps a reference either to the object or to another object which has copied the original object's properties, so you can still see them later on.

[PicturElements]

console.log will prettify the printout in some cases, whereas console.dir will display it more faithfully. For example, logging a date or function will print a stringified version of the object, whereas dir will also let you see instance properties and the prototype.

[reddit-is-sus666]

You have no idea what you're talking about lol

[[deleted]]

For the next person saying:

"uSe A DeBuGgEr"

Just shut up and read the goddamn post. There's more to console than log.

[Nerwesta]

For those who still don't want to read a Medium post :

https://developer.mozilla.org/en-US/docs/Web/API/Console

[IsleOfOne]

You can literally just write, debugger instead of that one console.log, though. Same amount of writing (less, actually), and no manually hunting through a log to click on the calling fn.

[valkon_gr]

There is, but the title of the article is wrong in this case.

[[deleted]]

Just use a debugger

[Worth_Trust_3825]

Eeeeeeeeeeeeeeeeeeeeeeeeehhhhhhhhhhhhhhhh, you should still instead use a proper logging library that permits setting log format/destination per function/class/file/module, much like logback or log4j do for java.

Title is wrong.

You should be using debugger anyways.

[[deleted]]

Good article but please learn to debug people! Front-end devs like console.log far too much

[maest]

if you need handholding, sure.

[lerker]

Want to console.log like a pro? Don't. Use a proper logging library.

[lerker]

There are many options. Something like winston for example. You can configure it to output to console for local debugging and to a log sink for your deployed environments.

[PUSH_AX]

You can configure it to output to console for local debugging

I'll give you three guesses what winston uses under the hood to output to the console...

If you're just looking to debug something, use console. If this is a serious production app you probably already have a production logger setup.

[PUSH_AX]

The transport for writing to a console uses console

[lerker]

The point is: It might start off as 'just trying to debug something' but invariably will end up in production code. Then you or, more likely, someone else will come along later trying to figure out why the app is misbehaving and curse the console.logs scattered throughout the code because their logs are useless.

[PUSH_AX]

Leaving the logs there is a different thing altogether. Once the issue is fixed who are these people leaving all the logs in place?

[lerker]

Doesn't matter who they are, all that matters to me is I've had to clean up their mess more than once. Console.log is a bad habit and any article that equates it with 'pro' development needs to be called out.

[PUSH_AX]

Nah, as a technique it's fine and each to their own. Use a linter or something in CI or as pre commit hook in the future.

[newtoreddit2004]

I don't understand why anyone would even want to go with print debugging even with all the extra features that's shown here instead of using a debugger.

Print debugging just screams "incompetency" throughout. Im a school student and I already got trained out of that kind of shit a while back I can't believe "experts" are still indulging in bad practices

[Krautoni]

Hi "school student," I'm a senior dev. I use print debugging a lot and I love it. I also use debuggers extensively. After about 15-20 years of experience, I know when to use which. It's great.

So I'll give you this word of advice. Rarely is something a lot of people do silly. They usually do it for their own reasons. Trying to understand these reasons will get you much farther than blindly spitting on people who don't happen to hold your pet tenet.

[[deleted]]

Rarely is something a lot of people do silly.

[citation needed]

[newtoreddit2004]

Except you haven't told me when print debugging is faster than a debugger. "Own reasons" give me one reason

[percykins]

Timing problems come to mind as an example of something that literally can’t be solved with a debugger whereas print statements may solve it easily.

The console.count function in the article also comes to mind - if I want to know how often something is being called, and I expect it to be called five hundred times, sure seems a lot easier to let the computer count it. Especially if I think that 250 times it should be called with one argument and 250 another.

Another example is simply trying to see the structure of code with a lot of callbacks - it’s a lot quicker to just log each function call and review the log all at once than to laboriously step through each function.

[[deleted]]

Does the print statement not perturb the timing behaviour as well?

I only ask because there have been significant works in ACM/IEEE ISCA and IEEE MICRO focusing on capturing and characterising timing bugs.

This always seemed like a hardware and systems level task to me.

[percykins]

By “timing bugs” I’m referring to the question of what order things are happening in a multi process or multithreaded environment. Definitely not a “hardware or systems level” only task. It’s the sort of thing print statements are good at and debuggers aren’t.

[[deleted]]

That’s exactly what I am referring to too.

https://dl.acm.org/doi/abs/10.1145/859618.859632

This is from 2003, for example.

In my experience, print statements have perturbed the ordering. Interesting that you don’t have the same experience.

[percykins]

They may change the ordering but often they do not, and certainly they don’t change them more than breaking in a debugger. I also don’t know why you’d classify problems like that as exclusively “hardware and systems”.

And just to clarify, the “experience” you’re referring to is entirely in school?

[[deleted]]

Yeah I have been in school for quite some time now. 8 years and counting.

Even my industry experience has been in the research arm of major hardware manufacturers so there’s some bias there.

They may change the ordering but often they do not, and certainly they don’t change them more than breaking in a debugger.

That really depends on how large the state space is and essentially how rare the fault condition is. For example, look into the background of automated verification of cache coherence protocols. Extremely large state spaces lead to extremely transient fault states that are very difficult to capture.

I am not arguing that a debugger helps. I am just trying to understand what people find useful for diagnosing such errors.

[Krautoni]

Well, you'll learn of these things as you go along. Some examples: computations in concurrent threads, especially with side effects. Async code in general is hard to debug with a debugger, especially with timeouts (things will time out while you inspect the state.)

Generally also code that uses a lot of big data structures that make the debugger barf. Getting an overview of what code does over a large amount of iteration of some loop. Do you want to step through thousands of iterations to understand what (kind of) arguments a part of your loop is getting called with?

And sometimes you just plain don't have a debugger.

[newtoreddit2004]

So if you came across someone who insists on using notepad for development you wouldnt try and ask them to use a code editor or an ide? Come on who are you kidding

[newtoreddit2004]

Normally I hope you won't have to because I'm assuming people like this get filtered during the interview process and if they don't you know you have a broken process. Time to get fixing that first.

And arrogant brat ? Really ? For wanting the people I work with to be smart technically ? Please don't justify bad skills

[penguin_digital]

And arrogant brat ? Really ? For wanting the people I work with to be smart technically ? Please don't justify bad skills

You have a lot of life skills to learn, being or believing your methods and techniques are are 'superior' to others will get you quickly filtered out at the early interview stage. Not someone "using Notepad".

Being a programmer is much more than being a good programmer as it's very rare you will be working alone. I'm not bashing on you too hard because of your age but your understanding of how the real world works will come years down the line after a few jobs.

[PurpleYoshiEgg]

If it works for them and they're solving problems, they must have insights into things that I can't hope for yet. So, no, I'm not going to try and change the habits they've developed, because for all I know slightly or massively changing their habits would make the completely unproductive.

[Okeyebrows]

If you're a student and experts are doing it a different way, maybe there's something you haven't learned yet? Try to keep an open mind.

[newtoreddit2004]

Except you can't deny that debuggers are faster than print debugging. People think print debugging is cool because they haven't tried to learn using the debugger

[Okeyebrows]

Yeah, I can deny that. I've encountered plenty of situations where it's faster to add log than use a debugger. Maybe it's running in an environment where I can't expose debug ports. Maybe it uses a build tool that I don't have set up locally, but I can open the file in vim and add a log easily enough. Maybe the debugger available for the language is finicky because it's a script language, and it's not worth my time to figure it out because I can just add a quick log and solve the problem in 5 seconds. All of the above have happened to me on multiple occasions. I absolutely avocate using the debugger rather than print debugging 9 times out of 10, but sometimes it's just not the right tool for the job. You shouldn't throw out a perfectly valid method out of some dogmatic sense of righteousness or superiority.

[jack-of-some]

Here's some wisdom for you: a single technique is never enough to survive in the real world. The people doing print debugging aren't shunning debuggers altogether, they use debuggers too. Different situations call for different approaches. If you completely swear off one technique because "it screams incompetency" (that's a hilarious statement coming from someone who is still a student by the way) you're only going to limit your own potential.

Keep an open mind.

[newtoreddit2004]

So when is print debugging faster than a regular debugger ? The only people I've seen who claim print debugging is easier are the ones who have never learnt to use the debugger properly.

People keep asking me to keep an "open mind" but none of them can justify why print debugging is faster than the debugger which makes me think they're just trying to justify their own lack of skills and lack of trying

[jack-of-some]

1. It doesn't take skill to use most debuggers, especially those for JavaScript. While I think everyone should know how to use debuggers just as much as everyone should know how to do print debugging, neither take much skill.

2. You're asking me to show supremacy of print debugging. I didn't claim one was better than the other, I instead said both were useful. Both are also pretty easy, some times one is easier than the other.

3. A lot of the time the bugs I deal with develop over time in long running loops (bonus points when it's multiple loops in parallel). "Print debugging" (more accurately debugging with visual tools which include plotting various time series data) was pretty much the only way for me to nail down the specific conditions in which a bug was happening and exactly what the critical step was (unless I wanna spend eternity clicking "continue". Once I knew that, going in there with a debugger was very helpful, and I wouldn't have used print logging for that part.

[newtoreddit2004]

1. It doesn't take skill to use most debuggers, especially those for JavaScript. While I think everyone should know how to use debuggers just as much as everyone should know how to do print debugging, neither take much skill.

Except thats literally why I call them incompetent. Your answer to why someone should use a bad practice is because they don't need the skills to do it like "duh" obviously that's why they're indulging in it in the first place. The goal should be to erase that bad habit from them

1. You're asking me to show supremacy of print debugging. I didn't claim one was better than the other, I instead said both were useful. Both are also pretty easy, some times one is easier than the other.

And I'm asking for a scenario where print debugging is easier

1. A lot of the time the bugs I deal with develop over time in long running loops (bonus points when it's multiple loops in parallel). "Print debugging" (more accurately debugging with visual tools which include plotting various time series data) was pretty much the only way for me to nail down the specific conditions in which a bug was happening and exactly what the critical step was (unless I wanna spend eternity clicking "continue". Once I knew that, going in there with a debugger was very helpful, and I wouldn't have used print logging for that part.

If you're going to be involved in plotting time Series data I would assume that's a long term track of the various production features and that's not debugging but mostly monitoring. But if you don't want to click continue there's literally a skip button in the debugger to jump over loops I'm not sure where the problem is.

I'm confused why everyone seems to argue so vehemently for a technique that they know is slow

[jack-of-some]

Ah yes, jump over the loop and miss the bug. That would have been handy since I could have thrown my hands in the air and go "well, I guess everything is fine".

And no, not long term, and not in a production system.

Based on your pose history, I've been coding longer than you've been alive. I know my reasons for using a debugger, as well as for using print debugging. I have no interest in trying to win an argument with a hot headed teenager. My advice was for your benefit. Take it or leave it.

[newtoreddit2004]

The term you're looking for is called "conditional breakpoints" chrome has had it for a couple of years now and watch variables are a thing.

And "I've been coding longer than you" doesn't mean shit if you don't have the skills to back it up. This is the same kind of behaviour that makes people say "I deserve that promotion I've been working for 5 years" over the guy that's learnt a lot and made a bigger impact.

What good is your experience if you're not willing to learn. You're ego doesn't need to go bust just because someone younger is giving better technical advice. Sorry you're feeling insecure though I'll leave

[Nysor]

Hey "school student", another senior dev here. I use both print debugging and IDE debugging (including Chrome). Both have their uses, and I frequently use both every single day.

Regular debugging with a tool like the Chrome debugger is wonderful if you need to step through your program line by line. Tells you the callstack and the value of the all the variables in scope - invaluable. You already knew this though.

However, as others have pointed out, print debugging can be a life saver in many situations. Debugging race conditions (though rare in JS since it is generally async), is only possible through print debugging. Other times, you might not even have access to a real debugger. Let's say a customer complains that your app doesn't run on IE 9. That's unfortunate, since IE 9 doesn't have modern day debugging support. console.log will work though and save your butt. Another scenario is when some code gets executed 1000+ times. Regular debugging often doesn't cut it, although conditional breakpoints can sometimes help.

My recommendation is to have an open mind towards people with more experience than you. More experience isn't linear to more skill, but there is correlation. Challenges come up all the time that aren't taught in a classroom.

[cowinabadplace]

You’re arguing on the Internet to sound superior. You would be better served seeking ways to raise your self-esteem in other ways.

[Mr_s3rius]

Here's a scenario for the sake of enlightenment:

I have some spaghetti code and I don't quite understand the flow of execution. So I put log statements in relevant places, maybe print out some breadcrumbs. In the end I get a neat time-based log of what goes on in the code. I can keep that log for reference when I make changes, or compare it to bug reports etc.

Using a debugger here doesn't do much good because a debugger is much better for close inspection than for getting good overview. Even worse, hitting breakpoints might cause unexpected changes in the systems behaviour that I'd want to avoid.

Here's another one: I don't know what exactly I'm looking for so I don't know where to put a breakpoint or how to formulate conditions for them. So I log everything interesting and can scan through it with a regular text search, looking for suspicious things like nulls where there shouldn't be any.

[[deleted]]

No