How to Stop Using Browser Dev Tools and Start Using Your Editor’s Debugger

How to Stop Using Browser Dev Tools and Start Using Your Editor’s Debugger

Thank you Burke Holland for this amazing article!

Over at, the elegant and both vertically and horizontally centered Chris Coyier wrote a post called “How to stop using console.log() and start using your browser’s debugger.”

It’s a good, concise post, and he makes some great points about the advantages of really getting to know and love your browser’s devtools for debugging JavaScript vs relying on console.log.

I’ll be the first to admit that I overuse console.log.

Console.log Anonymous

Hi. My name is Burke and I use console.log everywhere.

It’s been my go-to for so long. And console.log is a vast improvement over alert. I have personally written many an app that was built with “Alert Driven Development”, which, aside from being the developer equivalent of flooring it on a road with speed bumps every 80 feet, is also a pretty awesome acronym.

I try and learn my developer tools and lean on a proper debugging experience. And yet, every time I open the browser developer tools, there is a still small voice in the back of my mind. It whispers to me. And it says…

You don’t really want to do that.

And are you really going to wear that shirt today? You wore it yesterday. And I’m pretty sure the day before too.

Am I alone in feeling this way? Why do I resist the browser dev tools? And why do I have to change my shirt every day?

think I know the answer here.

I think that debugging your JavaScript in the chrome developer tools is not the way our brains want to work. I would like to propose that what we really want is to debug our code in the same place that we write it.

How did we get here

We’ve been leaning on the browser developer tools for debugging our JavaScript for so long that we’ve somewhat forgotten that this is not how it’s supposed to work. Your code should all be in your editor and you shouldn’t have to go somewhere else to work with it.

You’d be hard pressed to give me an example of another language/platform where people write their code in one place and debug it in another. That would be like making a big pot of chili and then making a second pot identical to the first so you can figure out if the first one has enough salt or not.

Browser development is wildly different than most platforms, though. It’s impossible to know which framework you will be using, how your project is going to be set up and what configuration your project needs to run. To make matters worse, JavaScript in 2018 is legitimately complex. We’ve got Webpack, Babel, TypeScript, Source Maps and most of that is configured by your CLI of choice. Your code is not the same when it runs as it is when you write it. Not even close. That makes it impossible to debug it anywhere but the browser.

Or does it?

Most people know that their editor can debug browser applications, they just aren’t sure how to set it up because it doesn’t “just work” out of the box. Fortunately, VS Code provides a lot of smarts and guidance for getting your projects set up to run and debug in VS Code.

Debugging Browser Apps in VS Code

VS Code can debug browser apps with a pretty good deal of flexibility. It uses the Chrome Debugger and the same debug port/protocol as the Chrome Developer tools.

VS Code keeps debug configurations in a .vscode/launch.json file called a “Launch Configuration” file. To create a Launch Configuration file, you need to go to the Debug Explorer in VS Code and click on the gear icon.

Then select the “Chrome” debugger. It comes by default with VS Code. You can install other debuggers from the VS Code Extension Marketplace.

burke 2.png

VS Code then tries to generate a launch configuration that works for your project. Let’s say we have a simple app that has an index.html , site.css and index.jsfile. VS Code generates the following launch config.

    "type": "chrome",    
    "request": "launch",    
    "name": "Launch Chrome against localhost",    
    "url": "http://localhost:8080",    
    "webRoot": "${workspaceFolder}"

This is close enough, but the “url” may be wrong. I launch simple static sites like this with a tool called “Lite Server” which you can install from npm…

npm install -g lite-server

Now you can run the site by just executing lite-server from the same directory where your HTML file is.


By default, lite-server runs the site on port 3000. So we need to update the launch.config.

    "type": "chrome",    
    "request": "launch",   
    "name": "Launch Chrome against localhost",    
    "url": "http://localhost:3000",    
    "webRoot": "${workspaceFolder}"

Now we can click the green button in the VS Code debug explorer and set a breakpoint within VS Code.

burke 3.png

Here we can examine variables, including the local scope, as well as set watches and examine the call stack. Note that variables can also be conditional, just like in Chrome. You can also use “Column breakpoints” just like you can in Chrome.

You can use the VS Code “Debug Console” to execute commands just like you would in the Chrome devtools console.

As an added bonus, if you go to Chrome and open the developer tools, you will see that you are broken in the exact same spot as in VS Code.

If you step over in VS Code, you will step over in Chrome too and vice-versa.

AND. Guess what? You can STILL use console.log. Or even better, VS Code offers something called “Log Points”. They are like breakpoints except they just log out to the Debug Console. This allows you to insert a log statement without actually having to stop, add code, save, recompile with webpack — you know the drill.

Now, this is a contrived example. You probably are not building a website with three files like it’s 1998. Or maybe you are. You do you. Nobody knows what they are doing anyway.

Debugging Angular, React and Vue with VS Code

Most of us are using something like Angular, React or Vue (alphabetical order — relax) and these frameworks (or libraries — take a deep breath) rely on Webpack to transpile, concatenate and minify JavaScript. All debugging has to be done via SourceMaps. This means setting up the VS Code debugger can be a little less straightforward.

Fortunately, the VS Code team has assembled drop-in recipes for all the major JavaScript frameworks…

Angular JavaScript Tutorial in Visual Studio Code
Angular JavaScript tutorial showing IntelliSense, debugging, and code navigation support in the Visual Studio Code…

Live edit and debug your React apps directly from VS Code — without leaving the editor 🔥 🎉🎈
Supercharge your React debugging workflow with VS Code and Chrome

Vue JavaScript Tutorial in Visual Studio Code
Vue JavaScript tutorial showing IntelliSense, debugging, and code navigation support in the Visual Studio Code

All of these launch configurations are relatively simple. It mostly just involves setting the port that your app is running on and what the working directory is, which can be hard to know sometimes so these recipes come in handy.

I did run into some issues with Vue and Source Maps that required a relatively creative setting that I never would have figured out on my own, but even Vue itself has this documented so that you can just copy/paste and remain blissfully unaware of what Webpack is doing and why it needs it’s own protocol and THREE slashes. THREE.

    "type": "chrome",   
    "request": "launch",   
    "name": "vuejs: chrome",   
    "url": "http://localhost:8080",   
    "webRoot": "${workspaceFolder}/src",   
    "breakOnLoad": true,   
    "sourceMapPathOverrides": {     
        "webpack:///./src/*": "${webRoot}/*"   

But now I can write Vue with TypeScript and debug it from within VS Code, which is kind of mind-blowing. It seems like this shouldn’t work, or maybe it just seems too good to be true.

burke 7.gif

Debugging in your editor is what you really want

I’m about 107.4% sure of that and that’s based on SCIENCE.

During most of 2018, I recorded a new VS Code tip video each week for a site called

I created 33 tips over 33 weeks. Some of these tips resonated with people and they got thousands of clicks and views.

But one tip gets far and away more traffic and interest than any of the others.

The tip “Debugging Browser Apps” is 29 seconds long, and all I do in the video is set a breakpoint in a React app, launch it in the browser and debug it in VS Code. More people watch that video than any other video on the site by a factor of about 20x.

What that tells me is that my proposition resonates: People want to be able to debug in their editor.

Debug and be happy

There is nothing wrong with using console.log, but Chris is right — a proper development experience involves learning and using your debugger. I just think it’s even better if you can use that debugger in your editor instead of your browser.

So take a minute today to configure VS Code to debug your application. See if you don’t find yourself using your debugger a whole lot more than you normally would.

I’m off to change my shirt.

Want to keep learning? Check out Burke’s tutorial on creating a MongoDB app with React and Azure Cosmos DB.

The contributors to JavaScript January are passionate engineers, designers and teachers. Emily Freeman is a developer advocate at Kickbox and curates the articles for JavaScript January.