Debugging browser-side JavaScript in Visual Studio Code


Inviting @cleoqc and @mitch.kremm as this might be of interest to them.

One of the issues I encountered while working on this project was trying to debug the JavaScript code running within the browser context as the browser is running full-bore and trying to debug/single-step the script is an exercise in frustration.

Researching this on-line disclosed that Visual Studio Code was working to get debugging support working within VS Code while using Google Chrome.  Unfortunately, this appeared to be a “work in progress”, and the implementation appeared to be iffy at best.

Of course nothing ventured, nothing gained - so I tried it for myself and it was a less than stellar solution - so I continued hacking at it with stone tools and flint knives hoping for an eventual solution to show up.


I eventually reached the point where flint and bone tools were no longer adequate and I absolutely needed to be able to see what was going on “under the hood”, in real-time, and see what variables and values were actually doing.  So!  I bit the bullet and kept digging.

I discovered several important facts:

  1. It is still a “work in progress”, but it has gotten to the point that it is usable by people who are not full time web engineers with Ph.D’s in Rocket Science.

    • A major part of the problem is that the available help spans several different iterations of VS Code as well as updates to Chrome so that one set of articles advise one process and another equally authoritative set of documents advise a different method, with the actual method that works being supplied by an even different set.
  2. The secret is to let Visual Studio Code manage the connection to the browser.  That’s done using a particular configuration file, placed in the .vscode directory in the root directory of your project.
    Viz.: launch.json

    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit:
    "version": "0.2.0",
    "configurations": [
            "type": "pwa-chrome",
            "request": "launch",
            "name": "Launch Chrome using",
            "url": "",
//            "url": "http://localhost:8080",
            "webRoot": "${workspaceFolder}/Joystick_Data_Test.js"

This tells VS Code how to launch the browser and how to bind to the code you want to run.

  1. This allows VS Code to open a browser window on your local system, attach to the server on the robot, bind to the JavaScript, and exert enough control to allow you to manipulate things in near real-time.

  2. Another important point is that VS Code opens a minimalist browser window session that consists primarily of just the visible window context, with no controls.  If Chrome is running, doing anything else, it screws everything up.

    • Supposedly there is a way to tell VS Code to “attach” to an existing session rather than trying to start a new one, but I have not experimented with that yet.

There are some issues:

  1. Browser caching is still a big issue.

    • VS Code still is not able to exert enough control over the inner workings of the browser to absolutely ensure that the browser cache is cleared and the current instance of your code is running.  Sometimes the only way to solve that problem is to stop the debugging session, detach from, (which kills), the “little” browser session that’s running, and then launch the browser itself to clear cache.
    • You clear the cache by opening the main instance of Chrome, open the in-browser dev-tools by pressing F12, right-click on the refresh icon in the upper left, and then select “Empty cache and hard reset”.
  2. Setting, (and releasing), breakpoints is also still problematic.

    • Sometimes this is solved by closing everything, (including VS Code and the running server), and then restarting.
    • Other times it’s solved by clearing cache.
    • Other times it seems to resolve itself.

I suspect that some of these issues are caused by the relative newness of the code, and others may be due to my own lack of knowledge and skill with the tool.

  1. You can pick-and-choose things to monitor by using the “watch” window.  Though apparently designed for “watching” processes, if you open a “new” watch and manually type in the name of a variable, you can monitor the value of the variable as you step through the code.

I will add to this thread as I learn more about how this works.


Amazing amount of work you’re putting in to this.

VS Code is turning in to a real Swiss Army knife* of programming

  • although I’m partial to Leatherman myself…
1 Like

It’s a dirty-rotten job, but somebody’s got to do it!  :wink:

I remember, not long after I got the robot, (three years ago!!), discovering the “remote camera robot” example.  I thought it was a Hot Smokin’ Weapon, except the “nipple” controller was abysmal for controlling the robot.

I figured that since 99.9999. . .999999. . .9999% of the work was already done, simply “wiring a joystick into the code” shouldn’t be THAT difficult - right? <<< (famous last words!)

@cyclicalobsessive mentioned that I had managed to choose one of the most difficult pieces of code to use as my first major project.  He was right.

I think you meant it to format like this:

Some characters are “magic”, (like the “*”), and to have them render as the typed character, (an asterisk), instead of its “magic” character, (a bullet-point), you have to “escape” the character like this: \*.

Viz.:  That last paragraph, (rendered literally), looks like this, and this is actually how I typed it in: (placed in a code-block to preserve textual content)

Some characters are "magic", (like the "\*"), and to have them render as the typed character, (an asterisk), instead of its "magic" character, (a bullet-point), you have to "escape" the character like this: `\*`.

You can have fun with HTML entity codes and a subset of the HTML formatting codes too.  One of these days I’ll have to write an article on the fun things you can do with these codes.