5 Chrome DevTools killer features that will change your life

Or Posener
Wix Engineering
Published in
6 min readJul 29, 2019

Whether you are a front-end or a full-stack developer, your main tool for debugging your client code (or someone else’s client code) would usually be the chrome DevTools environment. Knowing that environment can opt your work and save precious time.

After checking these features out on my own, which apparently made my life as a front-end developer much easier, I’ve noticed that many beloved members of the web development community are unfamiliar with them.

Photo by Brad Neathery on Unsplash

For the following section, I’ll assume you’re already familiar with DevTools, and at least know the basics.

So… let’s open DevTools and dive straight into it!

1. DOM Break-Point:

After some time debugging with chrome DevTools you kind of get used to the idea that in order to find out why something that should not happen keeps on happening, you have to crawl your way in the sources tab to find the source of the problem. Well, there’s another way.

DOM breakpoints are set by right clicking a DOM element via the Elements tab (or using the element selector), and choosing the different Break on options from the dropdown menu:

  • Subtree modifications — will pause when one of the child nodes is modified (added, removed, had its content changed).
  • Attribute modifications — will pause when one of the attributes of the current node is changed.
  • Node removal — will pause when the current node is removed.

In this example I wanted to understand why the message disappeared when I clicked the button, so I’ve selected the Break on -> attribute modifications option, since I’ve noticed that the display attribute is changed when the button is clicked.

Now, clicking the button again, forces the script execution to pause right after the attribute was changed, and the Sources tab is opened on the relevant line of code!

2. Log Points:

Sometimes you wish to log some information on deployed code in production without pausing the script. I found myself modifying code sections and even deploying console.log for debug purposes only. Since chrome 73, there is no reason to do that anymore, assuming you want to view the logs locally.

To place a LogPoint, just go to your code in the Sources tab, right click on the line number on which you wish to produce the log, and click Add logpoint.

Type in the content of the log (you could aggregate values with text just as simple as that) and hit the enter key.

Now, when I click the calculate button, you can see the desired log in the console!

3. Freezing:

Lately I found myself trying to debug DOM Elements which were changing due to mouse hovers, clicks and etc… It’s kind of annoying if you’re not doing it right. There are some ways to simulate these actions while inspecting through the debugger, but the easiest way is by “freezing” the browser at the right time.

In order to “freeze” the browser, we will need to first open devTools, and then use F8 (fn + F8 on osx) to pause script execution whenever you want.

The debugger will pause, and you’ll be able to inspect the elements on the screen in their current state, Simple as that!

4. DOM elements as Global Variables:

Chrome DevTools supplies some really nice interfaces that enable you to interact with DOM elements via the console. Since chrome 71, one of these tools is the Global Variables.

To assign a Global Variable to an element, right click that element from the Elements tab, and select the Store as global variable option.

The variable will be assigned in the console to a variable named ”tempX”, use it to interact with the element.

You can achieve a similar result by using the $0 variable, which will take the form of the currently selected DOM element (via the element selection tool, or from the Elements tab).

And by the way, you can select the parent element using $1, $2

5. Network Overrides:

Production code can be hard to manipulate, and take a long time to check. Current web technologies usually require you to rebuild your project and deploy it to a development environment of some sort.

You can use Network Overrides to change your code online before rebuilding and wasting your time on a solution that you are not sure is going to work!

In Sources tab, select the Overrides sub-tab and Select a folder on your machine in which overrides will be saved.

Select the file you wish to override in the Network tab.

The Sources tab will be opened once again. Now you can edit your file, Chrome will make sure to use the local override version instead of the code provided from the network!

The override will stay attached until you manually disable it, so make sure to uncheck the Enable Local Overrides box in the Network -> Overrides section.

Let's sum it up

These were 5 features in Chrome DevTools that have changed my life, and as what said above might not be all breaking news for you, if you learned one thing today, it did its job. Maybe the next time you’re in trouble, they will pop to your head and you’ll be able to show-off your friends with these neat tricks you’ve learned.

If you want to stay up to date with the latest features and updates for google chrome DevTools, you can give a glance at the What’s New section, which automatically appears when you open DevTools after an update!

I also recommend a visit at What’s new in DevTools, for a deeper overview of the latest news in Chrome DevTools.

Feel free to leave comments and make sure to follow up if want to read more!

--

--