I Wanted to Press F5 and Debug JavaScript — So I Built My Own VS Code Debugger

Sometimes software development reaches a point where the tools designed to make your job easier start becoming part of the job.

I ran into that with browser debugging.

I wanted something that should have been simple:

Set a breakpoint. Press F5. Debug my JavaScript.

Instead, I found myself spending too much time thinking about development servers, browser launch configuration, debugger connections, ports, profiles, and the debugging environment itself.

That led to a simple question:

What if browser debugging could go back to convention over configuration?

So I built CloudIDEaaS JavaScript Debugger.

⚡ The Goal: Press F5 and Debug

The philosophy behind CloudIDEaaS is straightforward:

Spend your time debugging your application instead of debugging your debugging environment.

For a straightforward JavaScript or HTML project, I wanted the workflow to look like this:

1. Set a breakpoint.
2. Press F5.
3. Start debugging.

Behind those three steps, CloudIDEaaS can start the local web server, launch Chrome, establish the debugging connection, configure your breakpoints, and then load the application.

The important part is that you don't have to think about most of that.

🔴 Real Debugging Inside VS Code

This isn't intended to replace Chrome DevTools or compete feature-for-feature with every large JavaScript debugging platform.

It's focused on providing the debugging features I use most often directly inside Visual Studio Code:

• 🔴 Source and conditional breakpoints
• 👣 Step over, step into, and step out
• ▶️ Continue and pause
• 🔍 Local variables and object inspection
• 📚 Scopes and call stacks
• 🧮 Expression evaluation
• ⚠️ Exception breakpoint configuration
• 🌐 A built-in local web server

One feature that was particularly important to me was startup breakpoints.

The debugger establishes the connection and configures your breakpoints before loading the application, making it possible to catch JavaScript that executes during startup.

🧠 What's Actually Happening Under the Hood?

Building the debugger also turned into an interesting exploration of how modern debugging actually works.

The architecture looks roughly like this:

Visual Studio Code
        |
        | Debug Adapter Protocol (DAP)
        v
CloudIDEaaS C# Debug Adapter
        |
        | Chrome DevTools Protocol (CDP)
        | WebSocket
        v
      Chrome

Visual Studio Code communicates with the CloudIDEaaS debug adapter using Microsoft's Debug Adapter Protocol (DAP).

The adapter is written in C#/.NET.

On the other side, the adapter communicates with Chrome using the Chrome DevTools Protocol (CDP) over WebSockets.

That means the adapter essentially sits between two debugging worlds:

VS Code ↔ DAP ↔ CloudIDEaaS ↔ CDP ↔ Chrome

When you set a breakpoint in VS Code, the adapter translates that debugging request into the corresponding Chrome debugging operation.

When Chrome pauses, reports a call frame, exposes a variable, or resolves a breakpoint, the adapter translates that information back into something VS Code understands.

🛠️ Why Build Another JavaScript Debugger?

That's a fair question.

VS Code already has excellent JavaScript debugging capabilities, and Chrome DevTools is extremely powerful.

CloudIDEaaS isn't an attempt to pretend those tools don't exist.

The motivation is workflow.

There are plenty of JavaScript projects where I don't want to assemble a modern frontend toolchain just to debug code running in a browser.

That can include:

• Plain JavaScript applications
• HTML/CSS/JavaScript projects
• Traditional web applications
• Legacy applications
• Educational projects
• Small prototypes and experiments

For those projects, I wanted debugging to feel more like the traditional IDE experience:

Set breakpoint → Press F5 → Debug.

⚙️ Convention Over Configuration

That principle became one of the main design goals of the project.

Modern development tools are incredibly powerful, but power often brings configuration.

CloudIDEaaS intentionally takes a narrower approach.

If sensible defaults can eliminate another configuration step, that's generally the direction I want to take.

The project isn't trying to become everything for everyone.

It's trying to make one common development task simpler.

🆓 Free and Open Source

CloudIDEaaS JavaScript Debugger is free and open source under the MIT license.

I'm actively developing it, and feedback is welcome—particularly from developers working with straightforward JavaScript applications, traditional web projects, and older codebases.

If you try it, I'd like to know:

• What kind of JavaScript project are you debugging?
• What part of browser debugging causes you the most friction?
• What would you expect to happen automatically when you press F5?
• What debugging feature would make the biggest difference to your workflow?

🚀 Try It

You can install CloudIDEaaS JavaScript Debugger from the Visual Studio Marketplace:

Install CloudIDEaaS JavaScript Debugger

The source code is available on GitHub:

CloudIDEaaS JavaScript Debugger on GitHub

Set a breakpoint.

Press F5.

And spend your time debugging the application.

`

## 📖 Further Reading

I also wrote about the broader philosophy behind CloudIDEaaS and why reducing developer-tool complexity can sometimes be more valuable than adding another feature:

**[When Developer Tools Become the Problem: Why I Built a Simpler JavaScript Debugger](https://publications.lavedajones.com/vscode-debugger/index.html)**