Debug JavaScript like a pro with DevTools and VSCode

Errors are unavoidable in every code or program, and if you are a developer, you’ll likely spend countless hours finding and fixing them.

Sometimes, an error can be so simple that you wonder how it was even possible to miss. It may even keep you up at night and ruin your appetite, only for you to later discover that what broke your code was a missing comma (,).

Finding and fixing errors is a skill developers must develop. This skill of identifying, analysing and fixing errors is called debugging, and there are various means and tools to assist developers in this process.

In this article, we’ll discuss ways to debug JavaScript code using Developer Tools and VS Code.

The purpose of debugging is to identify and fix errors. These errors, codenamed “bugs,” can disrupt the normal flow of a program. Finding and fixing them ensures that the code functions as intended.

The process of debugging is crucial in software development; beyond ensuring that the code runs smoothly, it also affects code quality, security, and user experience.

Errors occur in code for so many reasons, such as;

• Human oversight, which is a common mistake, such as forgetting to import, adding a semicolon, calling the wrong variable name, and more.

• Stress from trying to fix issues.

• Distractions from the environment.

• Error from a third-party entity that made unexpected changes or updates.

• Lack of proper skill, writing code just to make it work without following proper methods.

There are different stages involved in debugging, including;

Introducing Errors: This stage allows developers to intentionally create errors or bugs within the code. By deliberately introducing errors, developers can observe the outcome or effects errors produce, helping them make better choices. It can also help developers gain critical and problem-solving skills.

Find and Fix the Bug: This involves identifying the source of the bug by thoroughly reviewing the code. This can be done using debugging tools such as console.log, which helps displays errors. After examining how different components interact under certain conditions, the next step is to troubleshoot and fix the issue, then re-run the code to ensure the bug has been resolved.

Test Code: After the bug is fixed, certain tests can be carried out to ensure it has been properly resolved. These may include system or integration tests to verify that the module containing the fixed bug works as intended.

Documentation: Documentation is essential, as developers need to record details such as the error encountered, the process of fixing, the root cause of the bug, and any other information relevant for future reference.

When you inspect a web page on Chrome browser, you see different tabs, including;

• Console: Shows errors, warnings, and custom messages for testing, tracking outputs, and debugging.

• Sources: Allows you to view and edit source files, set breakpoints to find and fix bugs.

• Performance: Allows you to analyse how your web page runs, including load times and speed.

• Memory: Monitors memory use and how much each page consumes.

• Application: Shows data stored by your site, such as local storage, session storage, and helps you manage the application's data

• Privacy and security: Involve third-party interactions such as tracking APIs and issues related to HTTPS.

• Cookies: Displays and verifies cookies saved by the site.

• Network: Records and analyses network requests, displays response time status, payload, etc.

• Lighthouse: Audits the entire application performance, e.g., SEO, accessibility, etc.

Let’s go through some examples of how to debug JavaScript code using the Console, Sources, Network, and Performance tabs.

Console.log

If you haven’t used console.log, then you haven’t truly met JavaScript. console.log is like the “Hello World!” of programming.

console.log is a JavaScript function that displays information in the browser's developer console or other JavaScript environment. It helps developers with debugging code because it logs messages that reveal what's happening in the program, making it easier to trace where an error occurred and understand its cause.

Let’s look at an example to see how this works. In this example, we’ll simulate an error to show how console.log makes it easier to debug certain issues

In the image, we have written a function that concatenates X and Y, then converts them to a string. We intentionally set undefined as the value of Y to show what the console displays when a variable is assigned an undefined value.

From the error on the screen, you can see that it’s a TypeError. This means JavaScript cannot read properties of undefined. The reference index.js:7 tells you the file name and exact line number where the error occurred.

The image below is what the result produces without an error introduced.

Sources Panel

The sources panel allows you to view, edit, and debug source files such as JavaScript and CSS. For example, if you want to debug JavaScript code, you can set a breakpoint that pauses code execution, allowing you to inspect and go through your code line by line to see where things changed or issues occurred.

This provides a temporary way to edit and test JavaScript and CSS code directly in the browser without modifying the actual source code.

The sources have three main parts for debugging: The file navigator, code editor, and debugger sections.

• File Navigator: The File Navigator is where your site's file is located.

• Code Editor: The Code Editor is where JavaScript source code is located.

• Debugger Section: The Debugger section includes debugger controls where you can add breakpoints, monitor the call stack, and scope.

To open a source file, you can use Ctrl + P on Windows (or Cmd + P on Mac) to quickly search for and open the file you want to debug.

Once you locate the file and press Enter, the source file will open, as shown in the image below:

In the source panel, you can see all your project files. It allows you to step through your code as it runs and identify areas where errors might occur. You can also set a breakpoint, which is a specific point in the code where you want the code execution to pause, allowing you to inspect and determine what might be the cause of an issue.

Let’s see a quick example of how this works;

If we are debugging our code from the source panel using break breakpoint, this is what it’d look like;

In our code, when the button is clicked, we want x and y to be concatenated and then converted to a string. In the example, we added a breakpoint where we use console.log to display the result when the function runs.

The Blue label indicates that a breakpoint has been set. When you click the button that triggers the string conversion, the debugger pauses the execution and highlights the variables involved, showing where the error might be occurring. With this information, you can quickly identify and fix the issue.

The scope panel in the sources section displays all the variables currently in the scope when the debugger pauses. In this example, we see the local scope, which means that they were declared inside the function where the execution is paused.

Network Panel

The Network panel tracks network activity, including HTTP requests and responses. It can be used to check whether an API call was successful, as well as to inspect request payloads(data) and responses.

Let’s see what debugging in the network tab looks like. In the example below, we are making a simple API call. When we click the “Click Me” button, different jokes are displayed.

Let’s modify the URL and see how we can use the Network tab for debugging

From the Network tab, we can see the type of error that occurred. In this example, we removed a letter from the URL, and the network tab shows the API call's status as 404, 404 meaning that the requested internet address could not be found. This tells us something is wrong with the URL.

The Initiator column shows where the request is coming from, that is, the code or file that triggered the request. When you click on index.js:7, it takes you directly to the line of code where the request was made. This makes debugging easier cause you can quickly trace the origin of the problem.

Performance

The performance tab shows how long different tasks take to execute, such as network requests or page rendering. It helps you identify whether a site renders slowly or is unresponsive.

In the image, you'll see Interaction to Next Paint (INP). This is a performance metric that measures how responsive the web page is. It basically tells you how long it takes the browser to render visual feedback after the user interacts with the web page, in this case, when the user clicks on the button.

The result shows that it took 416 milliseconds for the browser to visually respond. 416 means there was a slight delay; in other words, the fetch request took some time to get the data from the API, which is why the performance rating indicates that it needs improvement.

Here’s a clearer view of the performance guide:

From the score guide, you can determine how to improve responsiveness, for instance adding a loading spinner to show something is happening on the page or something is loading, which improves user experience.

Note: To debug your code, you can choose the position of where you want the debugger to appear or how you want to view the issue.

When you click on the three dots, you’ll see the Dock side options and choose whichever position you prefer. You may want the debugger on the side or the bottom of your page.

Also note that every browser displays the Dev Tools differently. On Chrome, it is called Dock Side; on browsers like Edge, it's called Dock location.

Visual Studio Code (VSCode), an Integrated Development Environment (IDE), has built-in support for debugging JavaScript, TypeScript, and Node.js applications.

Debugging in VSCode is also similar to DevTools. If you haven't configured debugging in VSCode yet, you'll find a symbol in the side panel that looks like the image below.

When you click on it, you’ll see a tab with different options. Click on Run and Debug, which will display another set of options like the image below;

Our application is running on Chrome, so we will select the option WebApp (Chrome), and it will create a launch.json file that tells VS Code how to run and debug your code.

In the launch.json file, you need to change the default URL to match the location where your code is running. For example, if your local server is running on port 5500, you would replace 8080 with 5500.

When you click on the play button at the top of the panel, VS Code will open up your URL in the Chrome browser.

From the debug console at the bottom of the page, if there’s an error in your code, it will be displayed like the image below.

In the example, we misspelled the API URL, which resulted in a TypeError. This means the request failed to fetch, and the console shows that the error occurred while trying to access the API.

Let's also add a breakpoint in the index.js file

When we click the line where we want to add the breakpoint, a red dot appears.

In the example, after clicking the button in our web page to display the jokes, nothing appears immediately because when the fetch response returns, the debugger pauses. This happens because JavaScript stops running at the line where the breakpoint is set, so the browser temporarily halts the code.

From the variables section, we can see that the API call is successful. To allow JavaScript to continue running, we click the Continue button on the debug toolbar at the top of the editor, and the joke will be displayed on the page.

We are only seeing one joke because we added the breakpoint inside the loop, so the execution was paused during the first iteration. To display all jokes, we need to move the breakpoint to the end of the loop, that is, after it finishes, and click continue to see all jokes. Note that console.log allows us to see the point after the loop ends.

The reason why developers use breakpoints to inspect variables at the exact point of execution, understand the flow of code line by line just to see how it behaves, catch errors early to prevent the code from crashing, and test the logic to see that it works, for example, calling an API.

The toolbar

Several actions can be performed using the toolbar

• Continue: resumes execution until t hits another breakpoint.

• Step Over: runs the current line and remains in the same scope.

• Step Into: goes onside the next function call.

• Step Out: Finish the current function, and return.

• Restart Debugging: restarts the debugger.

The Call Stack

The call stack shows the flow of execution. It shows you how the code reached its current state. In the image, we see that the code is running inside an asynchronous function.

• Debugging is one of the primary responsibilities of a developer; you have to simulate bugs/fix them.

• Understand how different components work together. Since parts of projects are interconnected, a change in one area may affect another.

• Use resources and discuss with peers to help you see through problems and spot things you may have missed on your own.

• Don't overexert yourself. Sometimes, taking short breaks clears your head and improves productivity

• Use the right tools; there are resources online to help you understand how things work.

• Also, learning to debug other people's code will help improve your problem-solving skills and understand various coding styles.

Programming and debugging go hand in hand. You'll spend a good amount of your working hours figuring out why something isn’t working or how to make it work better.

DevTools are essential because they show you what you need to see, or at least point you in the right direction, helping you reduce the time and effort spent identifying where and why something went wrong. VSCode also includes a built-in debugging feature that you can configure to see how your code runs in real time.