Developer Tools for JavaScript

The browser console is where you read output. The Sources panel is where you debug. Learning to use breakpoints and step through code will save you hours of frustration — and it is not as complicated as it looks.

The DevTools panels for JavaScript

You have already used the Console. Here is the full set of panels relevant to JavaScript development:

Panel	What it shows
Console	Logs, warnings, errors, and your typed input
Sources	Your JavaScript files with breakpoint and stepping controls
Network	Every file the browser requested, including JS files
Elements	The live DOM — useful for seeing JavaScript-driven changes to the page

Open DevTools (Cmd+Option+I on Mac, F12 or Ctrl+Shift+I on Windows) and click the Sources tab.

The Sources panel

The left side of the Sources panel shows a file tree — your HTML, CSS, and JavaScript files organized by origin. Click main.js to open it.

You can read your script here exactly as you wrote it. This is the code the engine is executing.

Setting a breakpoint

A breakpoint tells the engine: pause execution at this exact line and wait. While paused, you can inspect the values of every variable in scope.

To set a breakpoint:

1. Find the line in your main.js where you want to pause
2. Click the line number on the left margin
3. A blue marker appears — that is the breakpoint

Now reload the page. When the engine reaches that line, it pauses and the Sources panel highlights it in blue.

Stepping through code

Once paused at a breakpoint, four controls in the top-right of the Sources panel let you move through code one step at a time:

Control	Keyboard	What it does
Resume	F8	Continue running until the next breakpoint or the end
Step Over	F10	Execute the current line and move to the next one
Step Into	F11	If the current line calls a function, step inside it
Step Out	Shift+F11	Finish the current function and return to the caller

For most debugging, Step Over (F10) is what you need. Move line by line, watching values change.

The Scope panel

While paused at a breakpoint, look at the Scope panel on the right side of Sources. It shows every variable currently in scope and its current value.

As you step through code, watch the Scope panel update. This is how you catch bugs: instead of guessing what a variable contains, you see its exact value at the exact moment the code runs.

The Network panel

Switch to the Network tab and reload the page. Every resource the browser requested appears here — HTML, CSS, JavaScript files, images.

Find main.js in the list. Key things to check:

• Status: 200 — the file loaded successfully
• Status: 404 — the file was not found (wrong path in src attribute)
• Initiator — shows what triggered the request
• Size — the file size

If your script is not running, the Network panel tells you whether it was even requested, and whether the server returned it successfully.

Common JavaScript error messages

Memorize these. You will see them repeatedly.

Uncaught ReferenceError: x is not defined You used a variable name (x) that was never declared. Check spelling and scope.

Uncaught TypeError: Cannot read properties of null (reading 'classList') You called a method on a DOM element that does not exist. The querySelector() returned null — either the selector is wrong, or the script ran before the element was parsed (add defer).

Uncaught TypeError: x is not a function You tried to call something as a function, but x is not a function — it might be undefined, a string, or a number.

Uncaught SyntaxError: Unexpected token A typo in your code. Missing closing bracket, extra comma, unclosed string. The file will not run at all — fix the syntax first.

Every error message includes a file name and line number. Click it to jump directly to the problem.

The debugger statement

You can trigger a breakpoint from within your code using the debugger statement:

function applyTourFilter(category) {
  debugger;  // Pause here every time this function is called
  const tours = document.querySelectorAll('.tour-card');
  // ...
}

When the engine reaches debugger;, it pauses exactly as if you had clicked a breakpoint in the Sources panel — but without needing to open DevTools first. This is useful for debugging code inside event handlers or callbacks that are hard to set breakpoints on manually.

Remove debugger statements before you ship code. They are a development tool only.

Exercise

1. Open your STO site in Chrome with DevTools open.
2. Go to the Sources panel and open main.js.
3. Set a breakpoint on the first console.log() line.
4. Reload the page. Execution pauses at the breakpoint.
5. Look at the Scope panel — you can see the global scope and any variables.
6. Press Step Over (F10) to advance one line. Watch the Scope panel update.
7. Press Resume (F8) to let execution finish.
8. Switch to the Network tab and reload. Confirm main.js appears with status 200.
9. Add debugger; as the first line of main.js, reload, and confirm DevTools pauses there automatically. Remove it when done.

Recap

• The Sources panel lets you set breakpoints, step through code line by line, and inspect variable values in the Scope panel.
• Breakpoints pause execution at a specific line so you can examine state.
• Step Over (F10) advances one line; Step Into (F11) enters a function call; Resume (F8) continues to the next breakpoint.
• The Network panel confirms your JS file loaded (status 200) or diagnoses why it did not (status 404).
• ReferenceError, TypeError, and SyntaxError each have distinct meanings — read the message, find the file and line, fix the specific problem.
• The debugger statement triggers a breakpoint from inside your code.