I don't think you can make a prescriptive argument about how someone should use dev-tools over console.log without covering conditional breakpoints (right click on the breakpoint to edit expression) then the breakpoint will only stop the execution when it matches.
Logging to debug is often used to evaluate the state of things that rapidly change, which you wouldn't be able to use a breakpoint alone for, but with conditional breakpoints it's quite easy to debug these kinds of situations.
I use a combination of all of these debug tools depending on the task.
which you wouldn't be able to use a breakpoint alone for
devtools provide you with "logpoint" and also you may create breakpoint with condition like console.log(someData),false. So breakpoint is self-sufficient tool for debuggin
I don't think you can make a prescriptive argument about how someone should use dev-tools over console.log without covering conditional breakpoints (right click on the breakpoint to edit expression) then the breakpoint will only stop the execution when it matches.
Logging to debug is often used to evaluate the state of things that rapidly change, which you wouldn't be able to use a breakpoint alone for, but with conditional breakpoints it's quite easy to debug these kinds of situations.
I use a combination of all of these debug tools depending on the task.
Thanks for reading Brant!
I love your points. Conditional breakpoint is a great tool indeed, but I felt that it was a bit too advance for this introductory article.
For those who want to a dig a little deeper into the advance features for each breakpoint types, check out this guide by Google.