Debugging JavaScript in Google Chrome and Visual Studio Code

Celý článek

Learning to debug is an essential skill for taking the next step as a developer. It's important to understand and leverage the vast array of tools that exist for a given languge. Unfortunately, debugging might not seem as obvious when working with JavaScript outside of a full-fledged IDE. At least not initially. Let's take a look at getting started debugging JavaScript in the Google Chrome Dev Tools as well as my favorite text editor for Web Development, Visual Studio Code.

Watch on YouTube

https://youtu.be/AX7uybwukkk

TLDR - Debugging JavaScript in Chrome?

• Open the 'Sources' tab
• Inspect code
• Set breakpoints, inspect variables, etc.

TLDR - Debugging JavaScript in Visual Studio Code?

• Download the Debugger for Chrome extension
• Create Debug configuration
• Launch Debug configuration
• Set breakpoints, inspect variables, etc.

Setup

For this article, I'm giong to be debugging an application called 'Quick Chat'.

While it is not required for you to run the same application, you can easily follow this video series to build the application yourself or clone the source code if you choose.

Whatever project you decide to run, you'll need to start it up. You can serve your applicatin from Node, like I'm doing, or from the Live Server extension for a simple static site. If you're new to the Live Server extension, check out this getting started video.

With my project, I've added a tiny bug that fails to register who the user is after they've logged in. Technically speaking, I'm incorrectly grabbing the user's username by referencing usernameInput.text instead of usernameInput.value. If I made this mistake in real life, my first instinct is to use console.log() to print out the DOM element reference (bad James....BAD JAMES), which isn't all that help as you can see. If this is you're first instinct also, don't worry, that's why you're here!!

Debugging Basics

Let's start with the basics. The idea of debugging is being able to (conditionally) trigger what are called breakpoints to pause the execution of your code. This provides you, the developer, the opportunity to look at the state of your application by inspecting variables for example. You can even take it a step further and 'watch' variables of your choosing, so that whenever your application gets paused, you can inspect them specifically. After triggering a breakpoint, you will typically have the following options.

• continue execution of your program
• step through your code line by line
• step out of the current function that you are in
• step into the next function call.

You'll additionally have access to view the call stack. In other words, as functions call other functions in your program, you can inspect the history of those function calls.

Debugging in Google Chrome

To get started with debugging in Chrome, add a debugger statement to the application as I have below in the loginBtn click event handler.

When this statement is reached, your application will be paused and the debug tools will automatically be activated. Noticed how the application is greyed out to signify that it has been stopped. Notice also how the Sources tab in the Chrom Dev Tools has popped up open proudly.

Let's breakdown what we're seeing.

Source Code

The first thing you might notice is what appears to be a copy of your code. This is the code that the browser has loaded and is running as your application. You can also see that the debugger line is higlighted a blue color to let us know that this is where our application has been paused.

Chrome gives you the ability to view this code for a reason. With the code in front of you, you can now set breakpoints. A breakpoint is intentional stopping or pausing place in a program. The debugger statement we used above functions as a breakpoint, but isn't necessarily picked up by Chrome as one.

Breakpoint - intentional stopping or pausing place in a program

To add a breakpoint, click in the gutter, or empty space, to the left of the line numbers. As your do, notice that Chrome now adds this breakpoint to the list of breakpoints further down.

Scope

In the scope tab, you have the ability to inspect variables in your application. You'll notice there is a local section (local scope to the function where the breakpoint is), a global section (the global scope), and a scripts section. In the scripts section, you can view variables within the scope of the current script.

This is where a significant amount of your debugging time will be spent. This is a much more efficient replacement for writing out many console.log() statements.

Watch

As I mentioned earlier, in addition to viewing variables in the scope tab, you can also define variables that you want to look into specifically. By adding a variable to the watch tab, each time you hit a breakpoint, you can quickly find the value of that variable (which may be undefined depending on where you are in the code). Hit the add icon and enter the name of the variable you want to watch to track, in this case, usernameInput.

Step Functions, Call Stack, and Breakpoints List

The last section, located in the bottom left of the Sources tab in my configuration, will allow you to view the list of breakpoints, call stack, etc.

In the call stack above, there is one function listed which is the event handler for my login button. This function is listed because it is the only function that has been called so far. As functions call more functions, that chain will be updated appropriately.

Notice also the arrow buttons at the top of this screenshot. These correspond to the functions referenced above for continuing execution of your code or stepping through it line by line or by function. I would recommend testing these buttons for a bit to get used to how you navigate the execution of your code.

Lastly, there are different kinds of breakpoints that can be set. Let's take a look at creating a conditional breakpoint, one that will only get triggered if a certain condition is met. For example, let's say we want to break on the login button callback only when the user attempted to login without entering a username. We can do this, by right-clicking in the gutter and choosing conditional breakpoint with the following condition, usernameInput.text === ''.

In the case of debugging Quick Chat, if you press the login button without entering a username, this breakpoint will be triggered. Otherwise code will continue to execute as normal.

Note that there are even more breakpoint options available that are not covered here.

Debugging in VS Code

The Chrome Developer Tools are some of the best in the business. As you've seen so far, they offer a great experience to debug your application with lots of functionality. However, Visual Studio Code has worked really hard to match that debugging functionality in a more seamless way. In my mind, I absolutely love VS Code and want to spend as much time there, and not in other tools, as possible. This includes debugging.

I absolutely love VS Code and want to spend as much time there, and not in other tools, as possible. This includes debugging.

To get started debugging in VS Code, you will need to install the Debugger for Chrome extension.

Let's take a quick look at the Debug tab in the sidebar (on the left side of your editor by default). Open the debug tab by clicking on the icon that... well looks like a bug. With this pane open, you should recognize very similar tools to what we saw in Chrome... variables, watch, call stack, and breakpoints.

The majority of the functionality that you get in Chrome Dev Tools is available right here inside of VS Code.

Now that we've seen the Debug tab, we need to create a launch configuration that tells VS Code how to debug your application. VS Code stores debug configurations in a file called launch.json inside of a folder .vscode. To have VS Code create this file for us, click on the 'No Configurations' dropdown and choose 'Add Configuration'.

VS Code stores debug configurations in a file called launch.json inside of a folder .vscode.

Then choose 'Chrome' in this case.

Then, choose the 'Chrome: Launch' configuration from the popup dropdown list.

The specific configuration that we created will automatically attach to the application at the defined port. We need to make one small change to this configuration to correctly point to the source code for the app. The source code is located in the public directory, which is why I have updated the 'webRoot' property.

**Keep in mind that your application must already be running locally at a certain port for this to work.

With the configuration defined, you can now start your debug session by clicking the green play button. Your application should pop up in a Chrome window as shown. Also, notice the debug menu bar that popped up in the background inside of VS Code. With this debug toolbar, you can pause, restart, continue, and use step functions to navigate your code and interact with the debugger.

With this debug toolbar, you can pause, restart, continue, and use step functions to navigate your code and interact with the debugger.

With debugging connected, you can set a breakpoint in the code, just like we did in Chrome. Click in the 'gutter' next to the line number. I'm keeping my breakpoint in the same location as before, just inside the login event callback.

Now, when trying to login without entering a username, the breakpoint should trigger swiching the contect back to VS Code for further investigation.

From here, the functionality that we discussed in Chrome maps over directly to VS Code. If you want to add a conditional breakpoint, right-click in the gutter and choose 'conditional breakpoint' with some condition. If you want to watch a variable, click to add a new one, and type the name of the variable to watch. If you want to explore variables, go to the variables tab and explore away!

Recap

As I said ealier, to take that next step as a developer means more than just writing better code. It means taking advantage of the ecosystem of tools that your language lives in. Debugging is one of those topics that takes some time and effort to get started with, but ultimately, the benefit will vastly outweigh the cost.

My recommendation is to spend some time debugging with both Chrome and VS Code, and see what you like best. If you have any questions or comments, find me on twitter, @jamesqquick.