Developer Tools secrets that shouldn’t be secrets

1. Console is much more than `log()`!

There is no doubt that, besides the Elements tool, Console is the most used part of the browser developer tools. Specificially, people love to debug by putting a `console.log()` in their code to learn what’s going on. There are a few problems with that, and there are better ways to debug scripts, but as this is what people do, let’s talk how to make that experience better.

What is that you’re logging?

The next problem with using `console.log()` is that we seem to only log values and forget to add where they come from. For example, when you use the following code, you get a list of numbers, but you don’t know what is what.

console.log(width)
console.log(height)
console.log({width})
console.log({height})

Adding to your console vocabulary

Errors and assertions in Console

Tracing where something came from

Grouping console messages

If you have a lot to log, you can use `console.group(‘name’)` and `console.groupEnd(‘name’)` to wrap the messages in collapsible and expandable messages in the Console. You can even define if the groups should be expanded or collapsed by default.

Displaying and filtering lots of information in the console as tables

If you want to display a lot of of information as a log, it can become daunting to read the information. The `console.table()` method displays array-like data as a table in the console, and you can filter what you want to display by giving it an array of the properties you want to see.

Blinging it up: $() and $$()

The console comes with a lot of convenience methods you can use called the Console Utilities . Two very useful ones are `$()` and `$$()` which are replacements for `document.querySelector()` and `document.querySelectorAll()` respectively. These not only return the nodeList you expect, but also cast the results to arrays, which means you can use `map()` and `filter()` on the results directly. The following code would grab all the links of the current document and return an Array with objects that contain only the `href` and `innerText` properties of each link as `url` and `text` properties.

$$('a').map(a => {
return {url: a.href, text: a.innerText}
})

2. You can log without source access — live expressions and logpoints

The normal way to add a `console.log()` is to put it inside your code at the place you want to get the information. But you can also get insights into code you can’t access and change. Live expressions are a great way to log information without changing your code. They are also incredible to log values that change constantly without flooding the console and thus slowing down your product. You can see the difference in the following screencast:

3. You can log outside the browser — VS Code debugger

When you start a debugging session in Visual Studio Code, you can spawn a browser instance and the Debug Console becomes the Console you are used to from the browser developer tools. I blogged about this in July in detail, so you can read up there how to do that . There is also more in the official documentation.

4. You can inject code into any site — snippets and overrides.

Snippets are a way in Developer Tools to run a script against the current web site. You can use the Console Utilities in these scripts and it is a great way to write and store complex DOM manipulation scripts you normally execute in the Console. You can run your scripts in the window context of the current document either from the snippets editor or from the command menu. In the latter case, start your command with an ! and type the name of the snippet you want to run.

5. You can inspect and debug much more than you know!

You may know the Chromium developer tools from browsers like Google Chrome, Brave or Microsoft Edge, but they are available in a lot more environments. Any app that’s based on Electron can have them enabled and you can use the Tools to peek under the hood and see how the product was done. This works, for example, in GitHub Desktop, Visual Studio Code, or you can even debug the Developer Tools of the browser using Developer Tools!

6. Some dirty secrets…

Working intimately with developer tools and getting feedback and usage information taught me a few dirty secrets. The first one is that whilst we are all super excited about all the amazing features of developer tools, users only use a very small percentage of them. Many things heralded as the best thing since sliced bread in presentations and video tutorials are hardly every opened, let alone used. I thought this was about a lack of documentation and we spent a massive amount of time to update the DevTools documentation to ensure everything in them is described and explained, but that wasn’t it. Documentation is something people seem to go to as a last resort when they are stuck and Google/Stack Overflow/Social channels didn’t yield any results.

Developer tools have become complex and are overwhelming — a few ideas how to fix that

It might be that the plain fact is that the Developer Tools of browsers grew organically over the years and can be incredibly overwhelming to look at. And that bothers me and I think we should do better. Here’s my mantra when it comes to tools for developers:

There is still a disconnect between authoring code and debugging the outcome

Whilst it is amazing what tools provide us these days there is still a disconnect between authoring and debugging. Most of the time we write our code, create the app and then go to the browser to see what doesn’t work. We then use the browser developer tools to tweak and fix these issues. And then comes the big issue we still need to fix: how do you get the changes you created using the browser developer tools back into your code? Most of the time, the answer is “copy and paste or try to remember what needs changing”.

7. You’re the audience and the clients of Developer Tools!

As a developer, you are the main audience for Developer Tools. We are open to your feedback and many of the recent changes to the tools are direct results from demands from outside developers. We try to make this as easy as possible by providing in-context ways to contact us directly. For example, the Visual Studio Code extension has prominent links and buttons for you to report issues and request features.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store