It is much more efficient to place a breakpoint at the spot where you would have put the print statement and then inspect the values of interest in the debugger.
It is a rather false dichotomy to assume that using better tools precludes you from "careful thought".
A debugger is very useful when you trace a piece of code that 1) you
understand well and 2) executes relatively linearly. JavaScript is
pretty terrible at both.
First of all, most JavaScript apps are just a small chunk of code that
sit on frontend frameworks (React etc). This means that using a debugger,
you mostly step through framework's internal code base, of which you have
a vague understanding at best.
Also, an average JavaScript code hops around -- to put it mildly --
crazily, due to the heavy usage of anonymous functions, callbacks and
other very cleaver abstractions.
This is why placing a bunch of console.log beats tracing with a debugger.
What? It jumps around because itβs running in an event loop. Not because JS devs try to do too many clever things. You hope it jumps around often or you might be blocking the loop for too long.
Now that you brought it up this way, I realized that I rarely step through the code. Instead I use break points + inspect like I would a print statement.
It is a rather false dichotomy to assume that using better tools precludes you from "careful thought".