Debugging in JavaScript: Browser DevTools
JavaScript-Debugging hat eine Besonderheit: dein „Debugger" ist meistens schon im Browser eingebaut. Chrome DevTools, Firefox DevTools, Edge DevTools – jeder moderne Browser bringt einen vollwertigen Debugger mit. Du brauchst keine separate IDE wie bei Java mit IntelliJ. F12 drücken – fertig.
Diese Lektion zeigt vor allem Chrome DevTools (Industriestandard), die anderen Browser sind sehr ähnlich. Plus: für Node.js-Backends gibt's mit node --inspect einen Debug-Modus der sich mit Chrome DevTools verbinden lässt – derselbe Debugger für Frontend und Backend.
1) DevTools öffnen
Drei Wege:
- F12 drücken (auf den meisten Browsern)
- Strg+Shift+I bzw. ⌘+Option+I auf Mac
- Rechtsklick auf der Seite → „Untersuchen" / „Inspect"
DevTools öffnet sich am rechten oder unteren Rand. Oben gibt es Tabs für die verschiedenen Tools – am wichtigsten für Debugging:
- Console: JavaScript-Konsole, sieht
console.log()-Ausgaben und Fehler - Sources: der eigentliche Debugger mit Breakpoints und Variablen
- Network: HTTP-Requests untersuchen (siehe L9)
- Elements: HTML/CSS inspizieren (für UI-Bugs, mehr in K42)
- Application: LocalStorage, Cookies, Service Worker
- Performance: Profiler für Performance-Probleme
2) Die Console
Die Console ist der einfachste Einstieg: hier landen alle console.log(), console.warn(), console.error()-Aufrufe. Plus alle JavaScript-Fehler. Und du kannst direkt JavaScript-Code eingeben und ausführen – wie ein REPL.
Die Console zeigt:
- log (grau): normale Ausgabe von
console.log() - warn (gelb): Warnungen mit
console.warn() - error (rot): Fehler und Exceptions
- info (blau): Informationsmeldungen
Rechts neben jeder Zeile siehst du den Source-Link – klick drauf und du springst direkt zu der Code-Zeile die den Output erzeugt hat. Sehr praktisch um zu sehen wo welcher Log herkommt.
Im Eingabefeld unten kannst du beliebigen JavaScript-Code eingeben und sofort ausführen. users.length, document.querySelector('.btn').click() – alles geht. Praktisch um Live-Werte in der Webseite zu prüfen ohne den Code zu ändern.
3) Console.log: mehr als nur log
Die Console-API hat über zwanzig Methoden – die meisten Entwickler kennen nur drei. Hier die nützlichsten:
console.table() ist eine echte Geheimwaffe: bei Arrays von Objekten zeigt es eine sortierbare Tabelle. console.table(users) bei einem User-Array gibt dir eine Liste mit allen Spalten – fast wie ein Excel-Sheet. Pro-Tipp: zweiter Parameter ist Spalten-Auswahl: console.table(users, ['name', 'email']).4) Sources-Panel: der eigentliche Debugger
Hier passiert das Debugging. Im Sources-Tab siehst du:
- Links: Dateibaum mit allen geladenen Scripts
- Mitte: Code-Editor mit Breakpoints und Stepping
- Rechts: Variables, Watches, Call Stack, Breakpoints
Um zu debuggen: navigiere zur gewünschten Datei links (oder Strg+P für Quick-Open). Klick auf eine Zeilennummer setzt einen Breakpoint (blauer Pfeil-Marker erscheint). Lade die Seite neu mit F5 – beim Erreichen der Zeile pausiert das Programm:
discount berechnet: bei Schritt 5 ist klar dass price * percent / 100 mit price=50 und percent=0.20 ergibt 0.1 statt 10 – die percent war hier als Dezimalbruch (0.20 = 20%) gemeint, sollte aber als ganze Prozentzahl benutzt werden. Anders gesagt: / 100 ist überflüssig wenn percent schon dezimal ist.5) Spezielle Breakpoint-Arten
Chrome DevTools hat einige spezielle Breakpoint-Typen die in Frontend-Entwicklung extrem nützlich sind:
- Conditional Breakpoint: Rechtsklick auf Breakpoint → „Edit Breakpoint" → JavaScript-Expression eingeben.
i === 100oderuser.role === 'admin'. Stoppt nur wenn wahr. - Logpoint: Rechtsklick → „Add logpoint". Statt anzuhalten wird ein Wert in die Console gedruckt. Wie
console.log(), aber ohne Code-Änderung. - XHR/Fetch Breakpoint: in der Sources-Sidebar → „XHR/fetch Breakpoints" → URL-Pattern eingeben. Stoppt sobald eine HTTP-Request an diese URL geht. Gold wert für API-Bugs.
- DOM Breakpoint: im Elements-Tab → Rechtsklick auf ein HTML-Element → „Break on..." → „subtree modifications" / „attribute modifications" / „node removal". Stoppt sobald jemand das Element ändert. Killer-Feature um zu finden welcher Code ein Element manipuliert!
- Event Listener Breakpoint: in der Sidebar → „Event Listener Breakpoints" → wähle Event-Typ (z.B. „click"). Stoppt sobald irgendwo ein Click passiert.
- Exception Breakpoint: Pause-Icon → „Pause on exceptions". Stoppt automatisch bei jedem JavaScript-Fehler. Pause on caught exceptions stoppt auch bei try/catch-gefangenen.
Die DOM-Breakpoints sind ein DevTools-Highlight: in React/Vue-Apps mit komplexem Re-Rendering verlierst du oft den Überblick wer was ändert. DOM-BP findet das in Sekunden.
6) Debugger-Statement im Code
Ähnlich wie breakpoint() in Python: in JavaScript gibt es das debugger;-Schlüsselwort. Schreib es ins Skript, öffne DevTools (sehr wichtig: DevTools muss offen sein, sonst tut die Anweisung nichts), lade die Seite neu – das Programm stoppt an der Stelle:
Wenn DevTools nicht offen ist: die debugger-Anweisung tut nichts. Praktisch – aber: nicht commiten! Linter wie ESLint warnen vor no-debugger. Anders als bei breakpoint() in Python crasht's Production-Code nicht, aber spawnt Verwirrung.
7) Stepping-Shortcuts
DevTools-Shortcuts (für Chrome/Edge):
| Aktion | Shortcut |
|---|---|
| Resume / Continue | F8 |
| Step Over (Zeile) | F10 |
| Step Into (Funktion) | F11 |
| Step Out (raus aus Funktion) | Shift+F11 |
| Step (intelligent) | F9 |
| Toggle Breakpoint | Strg+B (in Code) |
| Quick-Open Datei | Strg+P |
| Pause/Resume | F8 |
Step Into Async: bei await-Aufrufen steigt der Debugger automatisch in die Promise-Resolution rein – funktioniert seit DevTools 80+ nahtlos für async/await-Code. Frühe Versionen hatten damit Probleme.
8) Source Maps – debugge das was du geschrieben hast
Moderne JavaScript-Welt nutzt Build-Tools: TypeScript → JavaScript, ES2024 → ES5 für ältere Browser, Webpack/Vite bündelt 1000 Dateien in eine. Der Browser sieht dann optimierten, minifizierten Code – nicht deinen lesbaren Source. Debugging wäre unmöglich.
Die Lösung: Source Maps. Eine separate Datei (app.js.map) mappt jede Zeile im minifizierten JS zurück auf die Original-Quelle. DevTools lädt das automatisch und zeigt dir den TypeScript- oder Original-Code, auch wenn die Seite ein anderes Skript ausführt.
In den meisten Build-Tools sind Source Maps in Dev-Mode standardmäßig an. Aktiviere sie in DevTools: Settings (Zahnrad) → „Sources" → „Enable JavaScript source maps". Für Production: meist deaktiviert oder „Hidden Source Maps" (nur für Error-Tracking-Tools wie Sentry).
9) Network-Tab: API-Bugs
Für API-Bugs ist der Network-Tab entscheidend. Er listet alle HTTP-Requests die deine Seite macht: was wurde geschickt (Headers, Body), was kam zurück (Status, Body), wie lange hat's gedauert. Bei Fehlern mit „funktioniert nicht synchron" – fast immer ist es ein API-Problem das hier sichtbar wird.
Mehr zur Network-Tab-Analyse in L9 Netzwerk & API debuggen.
10) Node.js: Backend-JavaScript debuggen
Wenn du JavaScript serverseitig mit Node.js entwickelst, kannst du dich mit Chrome DevTools verbinden:
--inspect lässt einen Debug-Port offen, --inspect-brk stoppt zusätzlich bei der ersten Zeile (gut für Server die direkt eine Anfrage bearbeiten). In Chrome zu chrome://inspect navigieren – die Node-Instanz erscheint als „Remote Target". Klick auf „inspect" und du bekommst die DevTools, die mit deinem Node-Server verbunden sind. Identische Bedienung wie für Frontend-JS.
Alternativ: VS Code hat einen direkt eingebauten Node-Debugger – meistens komfortabler weil du im selben Tool entwickelst. Konfiguration in der launch.json.
11) Firefox und Edge
Firefox DevTools (F12) und Edge DevTools (basiert auf Chromium, fast identisch zu Chrome) haben die gleichen Konzepte mit kleinen UI-Unterschieden. Firefox hat einen kleinen Vorteil bei Web-Console-Features – z.B. zeigt console.log(domElement) klickbare DOM-Highlights. Chrome dafür bessere Memory-Profilers. Im Alltag sind sie fast austauschbar.
Safari hat „Web Inspector" mit ähnlichen Features, etwas anderem Look. Für die Entwicklung von iOS-Web-Apps unverzichtbar weil nur Safari iOS-Bugs zeigt.
12) Performance & Memory
Über reines Bug-Hunting hinaus: der Performance-Tab hilft bei langsamen Seiten. Drücke „Record", interagiere mit der Seite, stoppe – DevTools zeigt eine Zeitachse aller JavaScript-Aufrufe, Layout-Berechnungen, Paint-Operationen. So findest du den Engpass.
Der Memory-Tab ist für Memory-Leaks: nimm einen Heap-Snapshot, mache ein paar Aktionen, nimm zweiten Snapshot – vergleiche was nicht freigegeben wurde. Klassische Bug-Sorte in Single-Page-Apps die nie neu geladen werden.
Zusammenfassung
JavaScript-Debugging via Browser DevTools (F12 öffnen). Wichtige Tabs: Console (console.log + Errors + JS-REPL), Sources (Debugger mit Breakpoints), Network (HTTP-Requests), Elements (HTML/CSS). Console hat 20+ Methoden – console.table(), console.group(), console.trace() sind unterschätzte Killerfeatures. Sources-Tab: Datei links, Code mit Breakpoints in der Mitte, Variables+Call Stack rechts. Spezial-Breakpoints: Conditional, Logpoint, XHR/Fetch (bei API-Call), DOM (bei Element-Änderung), Event Listener (bei Event), Exception. Im Code: debugger;-Anweisung als Inline-Breakpoint (nur wenn DevTools offen). Shortcuts: F8 Resume, F10 Step Over, F11 Step Into, Shift+F11 Step Out, Ctrl+P Quick-Open. Source Maps machen TypeScript/minifizierten Code debugbar im Original. Network-Tab für API-Bugs (siehe L9). Node.js Backend-Debug: node --inspect + Chrome chrome://inspect, oder direkt in VS Code. Performance/Memory-Tabs für Speed- und Leak-Bugs. Konzepte gleichen den Debugger-Grundlagen aus L3 – nur mit besonders ausgereiften DOM-Breakpoints.