How to Debug JavaScript Right Inside Your Chrome Browser

Do you still use console log to debug your JavaScript code?

As a part of my first internship, I was working on a web-based application. Like any other modern web application, the application that I was working on used JavaScript on the Frontend. Being a less experienced JS developer, I was having a tough time finding a bug in my code.

This is when I request a senior developer for assistance. Finding a ton of console.log in my code, the senior developer gave me a piece of advice that changed my JS development workflow. This story conveys the same advice.

Logging to Debug

To debug a piece of code, it is common practice to print variables and messages. A developer can understand the code flow and verify that variables are receiving expected values by using these messages. The presence or absence of these messages also indicates whether or not a specific region of the code is executed. This method of debugging is undeniably effective, and many developers use it to debug code in the early stages of their careers.

But as a developer continues to grow, it is common to face limitations in debugging the code via this method. Managing a large number of messages is one of the biggest challenges. The ability to view different parts of variable is often required while debugging a code.

Sometimes you may only need to see a field of an object to debug the code while the other time you may need to view the entire object. Making these changes in the debug messages requires us to re-run the program. A re-run of the program is sometimes inconvenient and often not possible.

Thus using messages to debug the code might solve the purpose but as our debugging need grows we need better and more potent ways of debugging our programs.

Chrome Developer Tools

So seeing me struggle to debug a JS code running in a browser, the senior developer asked me if I know how to use Chrome Dev Tools. Completely unaware of Dev Tools until that point in time, the senior developer introduced me to debugging tools provided by Chrome Browser.

There are a number of benefits that developer tools provide above the normal logging method of debugging. Some of these are -

1. Using a debugger provides the exact current state of the application. Contrast this to printing messages on the console which loads the state lazily.
2. Code execution can be traced at each step without populating code with log messages.
3. Code execution and real-time changes can be traced together.

How to access Chrome Dev Tools

The debugger for JS code in the Chrome browser can be found under developer tools. Press F12 to open the developer tools. Once on the developer tools, select Sources panel. Here is what you would see:

Consider it as if you are running your favorite IDE right inside your browser. You can go through your files and inspect them. The toggler button, on the top left, opens the tab with files.

Tutorial on How to use Chrome Debugging Tools

Begin with hitting the following URL inside your browser - https://javascript.info/article/debugging-chrome/debugging/index.html. Follow the procedure described above to open the Sources panel in Chrome dev tools.

Open the file panel by clicking on the toggler button. This will display the files in the workspace. Double click on the file hello.js to open it in the file viewer. This is what you should be looking at -

The Sources panel is divided into three sections:

1. The HTML, JavaScript, CSS, and other files, including images attached to the page, are listed in the File Navigator pane. Chrome extensions may also appear here.
2. The source code is displayed in the Code Editor pane.
3. The JavaScript Debugging pane is used for debugging; we'll go over it shortly.

We can create breakpoints in the code right inside the code editor available in the sources panel. These can then be used to debug the code and trace code execution.

Let us now try creating some break points in the hello.js file. Click on line 4, right where the number is written. You should see a blue bar appearing on the top of the line number. Try creating a breakpoint at line number 8. The editor should now look something like this.

Now refresh the webpage and notice the execution stopping at line number 4. Focus on the informational section of the debugger.

The informational section allows us to examine the current code state:

1. Watch – shows current values for any expressions.

   You can click the plus + and input an expression. The debugger will show its value, automatically recalculating it in the process of execution.

2. Call Stack – shows the nested calls chain.

   At the current moment, the debugger is inside hello() call, called by a script in index.html (no function there, so it’s called “anonymous”).

   If you click on a stack item (e.g. “anonymous”), the debugger jumps to the corresponding code, and all its variables can be examined as well.

3. Scope – Shows the current variables.

   Local shows local function variables. You can also see their values highlighted right over the source.

   Global has global variables (out of any functions).

   There’s also this keyword there that we didn’t study yet, but we’ll do that soon.

Let us continue the code execution by clicking on the resume button (blue colored play button). Clicking on this button instructs the debugger to continue execution until the next break point. In our case, you should see the code execution stopping at line 8.

We can use the call stack collapsable to see the execution trace. Verify that we are at line 8 of the hello.js file inside the function say(). The row below it shows that the call to the say() the function is made from line 4 of hello.js file inside hello() function.

The execution of the code can also be controlled through various options available besides the resume button.

Here is a brief description of each of them (in order from left to right, starting from second option) -

• “Step over”: run the next command, but don’t go into a function
• “Step into”: If the line does not contain a function it behaves the same as “step over” but if it does the debugger will enter the called function and continue line-by-line debugging there.
• “Step out”: continue the execution till the end of the current function
• “Step”: run the next command

Final words

The use of debuggers can make a developer’s life much easy. When compared to warriors, a developer who knows about debuggers is a soldier on horseback, but a developer who does not know about debuggers is like running on foot on the battlefield. If you are still not using debuggers, you should start doing them today since this will make your work far better.

In the end, do follow me on Twitter and stay connected for more articles like this. Hit the like button if you like what you are reading.