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 in my code, the senior developer gave me a piece of advice that changed my JS development workflow. This story conveys the same advice. console.log 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. Chrome dev tools is a special UI in developer tools that makes debugging much easier. It also allows tracing the code step by step to see what exactly is going on. There are a number of benefits that developer tools provide above the normal logging method of debugging. Some of these are - Using a debugger provides the exact current state of the application. Contrast this to printing messages on the console which loads the state lazily. Code execution can be traced at each step without populating code with log messages. 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 to open the developer tools. Once on the developer tools, select panel. Here is what you would see: F12 Sources 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 - . Follow the procedure described above to open the panel in Chrome dev tools. https://javascript.info/article/debugging-chrome/debugging/index.html Sources Open the file panel by clicking on the toggler button. This will display the files in the workspace. Double click on the file to open it in the file viewer. This is what you should be looking at - hello.js The Sources panel is divided into three sections: 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. The source code is displayed in the Code Editor pane. 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. A breakpoint is a line of code that causes the debugger to pause JavaScript execution. Let us now try creating some break points in the 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. hello.js 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: – shows current values for any expressions. Watch You can click the plus and input an expression. The debugger will show its value, automatically recalculating it in the process of execution. + – shows the nested calls chain. Call Stack At the current moment, the debugger is inside call, called by a script in (no function there, so it’s called “anonymous”). hello() index.html 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. – Shows the current variables. Scope shows local function variables. You can also see their values highlighted right over the source. Local has global variables (out of any functions). Global There’s also keyword there that we didn’t study yet, but we’ll do that soon. this 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 file inside the function . The row below it shows that the call to the the function is made from line 4 of file inside function. hello.js say() say() hello.js hello() 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) - : run the next command, but “Step over” don’t go into a function : 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 into” : continue the execution till the end of the current function “Step out” : run the next command “Step” 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.
