Wenn du alles in eine .html-Datei packst, scrollst du bald ewig nach dem richtigen Code – drei separate Dateien sind der bessere Start. Ein zweiter häufiger Fehler: IDs dürfen nur einmal pro Seite vorkommen und gehören zum JavaScript-Zugriff, Klassen sind dein Werkzeug für Styling und wiederverwendbare Selektoren.
Alles in einer Datei: Praktisch, aber kein guter Start
Der häufigste erste Schritt beim Lernen: HTML, CSS und JavaScript landen alle in einer einzigen .html-Datei. Das funktioniert, aber schon bei einem Projekt dieser Größe scrollst du ewig, um etwas zu finden.
Besser sind drei separate Dateien. Die CSS-Datei verlinkst du mit einem <link>-Tag im <head>, das JavaScript fügst du mit einem <script>-Tag am Ende des <body> ein. So bleibt jede Datei überschaubar, und du weißt sofort, wo du suchen musst.
IDs und Klassen: Wann du welche nimmst
In der eingereichten App hat fast jedes HTML-Element eine eigene ID. Das Problem: IDs sind einzigartig – sie dürfen nur einmal pro Seite vorkommen. Du verwendest sie dann, wenn du ein Element gezielt im JavaScript ansprechen willst, zum Beispiel mit getElementById().
Für das Styling über CSS nimmst du besser Klassen. Eine Klasse .card-title kannst du an zehn verschiedenen Elementen nutzen. Eine ID #card-title nur an einem – damit verlierst du Wiederverwendbarkeit, für die du sonst nichts tun müsstest.
Dazu kommt ein konkretes HTML-Problem: Labels müssen mit dem zugehörigen Input-Feld verknüpft sein. Das for-Attribut am <label> muss mit der id des <input> übereinstimmen. Dann kann man auch auf den Label-Text klicken, um das Feld zu aktivieren oder eine Checkbox anzuhaken. Das ist kein optionales Extra, das ist korrektes HTML.
CSS: Responsive ist mehr als eine Breite
Eine hardcodierte width: 600px macht eine App nicht responsiv. Auf einem kleinen Bildschirm wird das zusammengequetscht oder bricht aus dem Layout heraus.
Die sauberere Lösung sind Media Queries: Für kleine Bildschirme setzt du width: 100%, ab einer bestimmten Breite begrenzt du auf einen Fixwert und zentrierst mit margin: auto. So funktioniert das auf jedem Gerät ohne Hacks.
Zwei weitere CSS-Punkte, die in der App auffallen:
- Abstände: Werte wie 40px, 60px, 20px, 24px und 13px tauchen wild durcheinander auf. Diese “Magic Numbers” ohne erkennbares System machen den Code unübersichtlich. Halte dich lieber an ein festes Raster, zum Beispiel Vielfache von 4 oder 8.
- Farben: Wiederholende Primärfarben gehören in CSS-Variablen. Also
--color-primary: #3b82f6;im:root-Block, und dann überallvar(--color-primary)statt der Hex-Farbe. Das spart Zeit und verhindert, dass du irgendwann fünf leicht verschiedene Blautöne im Code hast.
JavaScript: Moderne Syntax und echte Absicherung
Im JavaScript-Teil fällt var sofort auf. Das ist veraltet – heute nimmst du let für Variablen, die sich ändern, und const für alles, was nach der ersten Zuweisung konstant bleibt. DOM-Elemente, die du mit getElementById() holst, änderst du später nicht mehr. Also: const.
Statt klassischer for-Schleifen mit Kurzbezeichnern wie t gibt es heute in JavaScript eingebaute Methoden: forEach() für einfaches Durchlaufen, map() für Transformationen, filter() für das Herausfiltern von Elementen. Kürzer, lesbarer, moderner.
Statt Stringverkettung mit + nimmst du Template Literals – also Backticks statt Anführungszeichen und ${variablenname} direkt im Text. Das ist besonders bei HTML-Strings deutlich übersichtlicher.
Dann noch ein konkreter Bug: Die Validierung prüft, ob das Eingabefeld leer ist, aber ein einzelnes Leerzeichen kommt durch. Die Lösung ist .trim() vor dem Längencheck: title.trim().length < 1 fängt auch Leerzeichen-Eingaben ab.
Positiv: Die App escaped HTML-Sonderzeichen, bevor sie in den DOM eingefügt werden. Das verhindert, dass jemand <script>-Tags oder Links als To-Do eingibt, die dann tatsächlich ausgeführt werden. Dieser XSS-Schutz ist wichtig und war hier gut gelöst.
Last but not least: Die To-Dos verschwinden beim Neuladen. Für eine echte To-Do-Liste brauchst du Persistenz. Mit localStorage ist das in wenigen Zeilen gelöst – beim Hinzufügen speicherst du, beim Laden liest du aus. Kein Server, direkt im Browser.
Wenn du solche Themen strukturiert lernen willst – von HTML-Grundlagen bis zu sauberem, wartbarem JavaScript mit echtem Feedback zu deinem Code – schau dir unseren Fullstack Web Developer Kurs an.
Häufige Fragen
Was ist ein Code Review und warum ist es wichtig?
Ein Code Review ist eine strukturierte Durchsicht von Code durch eine erfahrene Person. Es geht nicht darum, ob das Programm läuft, sondern ob der Code lesbar, wartbar und korrekt geschrieben ist. Für Lernende ist das besonders wertvoll, weil schlechte Gewohnheiten sonst unbemerkt mitgeschleppt werden – manchmal über Jahre.
Muss ich als Anfänger sofort alles richtig machen?
Nein. Fehler wie hardcodierte Breiten, zu viele IDs oder fehlende Validierung sind normal am Anfang. Wichtig ist, dass du verstehst, warum etwas nicht ideal ist – und wie du es besser machst. Wer regelmäßig Feedback bekommt, verbessert sich deutlich schneller als jemand, der alleine vor sich hin programmiert.
Was ist der Unterschied zwischen let, const und var?
var ist veraltet und sollte heute nicht mehr verwendet werden. let nimmst du für Variablen, die sich im Programmablauf ändern. const für alles, was nach der ersten Zuweisung gleich bleibt – zum Beispiel DOM-Elemente oder Konfigurationswerte. Der Unterschied wirkt klein, macht deinen Code aber klarer und verhindert bestimmte Fehlerquellen von vornherein.