Debug and Fix Errors

Why debugging matters

You've learned HTML, components, JavaScript, and CSS. You can build things, style them, and organize your code. But here's the reality of working with code: things break. Constantly. Not because you're doing something wrong — but because that's just how development works. Typos happen, imports get forgotten, a bracket goes missing, a property name is misspelled. Everyone deals with this, from beginners to people who've been coding for decades.

The skill that matters isn't avoiding errors — it's knowing how to find and fix them quickly. That's what debugging is. It's not about memorizing solutions. It's about knowing where to look.

DevTools

Your most powerful tool for debugging is DevTools — the built-in development tools that come with every modern browser. You can open them by right-clicking on any page and selecting "Inspect," or by pressing ⌘ + Option + I. DevTools gives you direct access to see and edit the HTML structure, the CSS styles, the JavaScript console, and much more.

The Elements tab (also called Inspector) shows you the HTML structure of the page. You can click the selector icon, hover over any element, and see its exact HTML and all the CSS rules applied to it. This is invaluable for answering questions like "Why does this heading look like this?" or "Which CSS rule is overriding my styles?" You can even edit HTML and CSS directly in DevTools to experiment — though these changes are temporary and disappear when you refresh.

Reading the console

The console is where you'll see errors, warnings, and messages. JavaScript error messages appear in red and usually tell you exactly what went wrong and where — including the file name and line number. Learning to read these messages is one of the most practical skills in web development. An error like "Cannot read property 'name' of undefined" tells you that you're trying to access .name on something that doesn't exist. The line number tells you where to look.

It's worth understanding that there are actually two different consoles. The terminal console (where you run npm run dev) shows build errors — syntax errors, TypeScript type errors, missing imports, things that prevent the project from compiling. The browser console (in DevTools) shows runtime errors — things that go wrong when the code actually runs in the browser. Sometimes the same issue shows up in both places.

Silent failures

Some problems are silent failures — they don't produce any error messages at all. An invalid CSS value (like color: blueish) gets silently ignored by the browser. A typo in a CSS class name means the styles just never apply. An unknown HTML tag gets rendered but doesn't do what you expect. These are trickier to catch because there's no red error screaming at you. This is where DevTools inspection becomes essential — you can check whether your styles are actually being applied and whether the HTML structure is what you expect.

A systematic approach

When something goes wrong, the systematic approach is: first, identify what's not working and what you expected to happen. Second, check for errors in both the terminal and browser console. Third, isolate the problem — what changed since it last worked? Fourth, form a hypothesis about what's wrong and test it with a small change. Fifth, verify the fix and make sure you didn't break anything else.

A few strategies that work well in practice: comment out code to isolate the issue (if the error disappears, you know where the problem is). Simplify complex code to its most basic form and add complexity back gradually. Use console.log() to print values and understand what's actually happening in your code. And check the obvious things first — is the dev server running? Did you save the file? Are you editing the right file? Did you import the component?

Using AI to debug

Debugging is also where AI tools can genuinely help. You can paste an error message into an AI assistant and ask it to explain what's wrong. The key is to provide context — not just "it doesn't work" but the exact error, the file and line number, and the relevant code. The more specific you are, the more useful the AI's response will be. But always understand the suggested fix before applying it — debugging is about learning how things work, not just making errors go away.

This might be the most practical exercise in the entire course. The skills you build here — reading error messages, using DevTools, systematic problem-solving — will save you more time than almost anything else you learn. Every developer, no matter how experienced, spends a significant chunk of their time debugging. Getting good at it early makes everything else easier.