Select Page

Category: DevTools

How to stop using console.log() and start using your browser’s debugger

Whenever I see someone really effectively debug JavaScript in the browser, they use the DevTools tooling to do it. Setting breakpoints and hopping over them and such. That, as opposed to sprinkling console.log() (and friends) statements all around your code. Parag Zaveri wrote about the transition and it has clearly resonated with lots of folks! (7.5k claps on Medium as I write). I know I have hangups about it… Part of debugging is not just inspecting code once as-is; it’s inspecting stuff, making changes and then continuing to debug. If I spend a bunch of time setting up breakpoints, will they still be there after I’ve changed my code and refreshed? Answer: DevTools appears to do a pretty good job with that. Looking at the console to see some output is one thing, but mucking about in the Sources panel is another. My code there might be transpiled, combined, and not quite look like my authored code, making things harder to find. Plus it’s a bit cramped in there, visually. But yet! It’s so powerful. Setting a breakpoint (just by clicking a line number) means that I don’t have to litter my own code with extra junk, nor do I have to choose what to log. Every variable in local and global scope is available for me to look at that breakpoint. I learned in Parag’s article that you...

Read More

What do we call browser’s native development tools?

You know, that panel of tools that allows you to do stuff like inspect the DOM and see network requests. How do the companies that make them refer to them? Chrome calls them DevTools. Edge calls them DevTools. Firefox calls them Developer Tools. Safari calls it the Web Inspector. I think it’s somewhat safe to generically refer to them as DevTools. Safari is the only browser that doesn’t use that term, but I imagine even die-hard Safari users will know what you mean. The post What do we call browser’s native development tools? appeared first on CSS-Tricks....

Read More