While there is nothing necessarily wrong with debugging by way printing console.out all over the place it does have its short comings. A few key ones for me are:

1. It can be difficult to manage when the debug is inside a loop or a timed event (eg setInterval or requestAnimationFrame). There can end up being so much output that it becomes essentially useless
2. You lose the code context. Once you have started putting in a number lines of logging you have to remember where they correspond to in the code. Descriptive logging helps but as we will see it is not worth the overhead when better options are available.
3. You run the risk of including the logging in a production build. Let's face it - we have all had / seen this happen. In some cases this can even have a performance impact on the production build

If you are using VS Code there is a great debugger tool that hooks in with Chrome to facilate real-time debugging of your code. This includes setting break points and stepping in and out of sections of code.

To get started download and install the Debugger for Chrome VS Code extension

VS Code will create a .vscode/launch.json file in your project home. A typical launch.json for Chrome debugging will look something like this

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Chrome",
            "type": "chrome",
            "request": "launch",
            "url": "http://localhost:3000",
            "webRoot": "${workspaceRoot}/src"
        }
    ]
}

Here webRoot points to where files are saved on the local disk. It maps something like http://localhost:3000/bundle.js to an actual file on the disk.

I do most of my development on WSL (Windows Subsystem for Linux) and there is a slight issue here due to the difference in how paths are referenced. Inside WSL the path to the project would be something like /mnt/c/Users/Andrew/ws/project/ but this won't resolve to a Window path in VS Code (ie C:\Users\Andrew\ws\project).

The result was the below annoying error in VSCode:

Unverified breakpoint, Breakpoint ignored because generated code not found (source map problem?).

Essentially this means that VSCode is not able to map the source files listed in Chrome to actual source files on the disk.

To get around this I configured sourceMapPathOverrides in launch.json to essentially alias the Unix paths to the Windows paths:

{
  "version": "0.2.0",
  "configurations": [{
    "name": "Chrome",
    "type": "chrome",
    "request": "launch",
    "url": "http://localhost:3000",
    "webRoot": "${workspaceRoot}/src",
    "sourceMapPathOverrides": {
      "/mnt/c/Users/Andrew/ws/project/src/*": "${workspaceFolder}/src/*"
    }
  }]
}

Make sure that this points at wherever your source code is (or source maps).

Now that that is taken care of we just need to complete the configuration in VSCode. To do this go to the debug pane and select 'Add Configuration..' from the dropdown. Select 'Chrome'

Then select the 'Configure' icon:

This will open up your launch.json, you can configure it as above and add any extra parameters from the plugin's documentation

Once complete you should be able to open your app in debug mode by hitting F5 or the 'Play' button in the debug pane in VSCode.

Try setting some break-points, this can be done by clicking to the left of the line numbers. Once the code in Chrome reaches that line number the execution will stop an allow you to inspect the values of variables in scope and also see the call stack at that point in time.

Happy debugging!