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

Inspecting Animations in DevTools

I stumbled upon the Animation panel in Chrome’s DevTools the other day and almost jumped out of my seat with pure joy. Not only was I completely unaware that such a thing exists, but it was better than what I could’ve hoped: it lets you control and manipulate CSS animations and visualize how everything works under the hood. To access the panel, head to More Tools → Animations in the top right-hand menu when DevTools is open: Many of the tutorials I found about this were pretty complicated, so let’s take a step back and look at a smaller example to begin with: here’s a demo where the background-color of the html element will transition from black to orange on hover: html { cursor: pointer; background-color: #333; transition: background-color 4s ease; } html:hover { background-color: #e38810; } Let’s imagine that we want to nudge that transition time down from 4s. It can get pretty annoying just bumping that number up and down in the element inspector. I typically would’ve opened up DevTools, found the element in the DOM and then ever-so-slowly manipulate it by typing in a value or using the keyboard directional keys. Instead, we can fire up that demo, open DevTools, and switch to the Animation tab which ought to look something like this: By default, Chrome will be “listening” for animations to take place. Once they...

Read More

Chrome DevTools “Local Overrides”

There’s been two really interesting videos released recently that use the “Local Overrides” feature of Chrome DevTools in order to play with web performance without even touching the original source code. Umar Hansa: Improving the performance of Soylent.com with local overrides and font-display Harry Roberts: Using Chrome’s ‘Local Overrides’ to Test Performance Hypotheses The big idea is that you can literally edit CSS and reload the page and your changes stick. Meaning you can use the other performance testing tools inside DevTools to see if your changes had the effect you wanted them to have. Great for showing a client a change without them having to set up a whole dev environment for you. Direct Link to Article — Permalink The post Chrome DevTools “Local Overrides” appeared first on CSS-Tricks....

Read More

Monitoring unused CSS by unleashing the raw power of the DevTools Protocol

From Johnny’s dev blog: The challenge: Calculate the real percentage of unused CSS Our goal is to create a script that will measure the percentage of unused CSS of this page. Notice that the user can interact with the page and navigate using the different tabs. DevTools can be used to measure the amount of unused CSS in the page using the Coverage tab. Notice that the percentage of unused CSS after the page loads is ~55%, but after clicking on each of the tabs, more CSS rules are applied and the percentage drops down to just ~15%. That’s why I’m so skeptical of anything that attempts to measure “unused CSS.” This is an incredibly simple demo (all it does is click some tabs) and the amount of unused CSS changes dramatically. If you are looking for accurate data on how much unused CSS is in your codebase, in an automated fashion, you’ll need to visit every single URL on your site and trigger every possible event on every element and continue doing that until things stop changing. Then do that for every possible state a user could be in—in every possible browser. Here’s another incredibly exotic way I’ve heard of it being done: Wait a random amount of time after the page loads Loop through all the selectors in the CSSOM Put a querySelector on them and see...

Read More
000webhost logo