Ich habe gerade Brad Traversys Udemy-Kurs „Vanilla Web Projects“ abgeschlossen. Der Kurs besteht aus vielen kleinen Projekten, die mit HTML, CSS und Vanilla JavaScript umgesetzt werden.
Was mir daran besonders gefallen hat: CSS und JavaScript werden nicht über ein riesiges Projekt hinweg behandelt, sondern in vielen kleinen Anwendungen miteinander kombiniert. Dadurch entsteht ein sehr unmittelbarer Lernkreislauf: Eine Idee wird erklärt, umgesetzt und kurze Zeit später funktioniert bereits eine kleine Anwendung.
Für mich war der Kurs allerdings nicht nur eine Wiederholung von HTML, CSS und JavaScript. Viel interessanter wurde er an den Stellen, an denen ich angefangen habe, die Lösungen des Kurses selbst zu hinterfragen.
Kleine Projekte statt großer Kapitel
Viele Webentwicklungskurse behandeln HTML, CSS und JavaScript getrennt oder ziehen das Styling eines Projekts über einen großen Teil des Kurses hinweg. Hier entstehen dagegen viele kleine Projekte: ein Form Validator, eine Sitzplatzreservierung, ein Videoplayer, ein Quiz, ein Breakout-Spiel, ein Countdown und schließlich eine Product-Filter-Oberfläche.
Gerade für eine Auffrischung finde ich diesen Ansatz angenehm. Man arbeitet beispielsweise einige Minuten an einer bestimmten JavaScript-Technik und sieht anschließend sofort ein Ergebnis im Browser.
Das verhindert auch ein Problem, das ich aus längeren Kursen kenne: Man verbringt sehr viel Zeit mit einer abstrakten Erklärung und weiß irgendwann nicht mehr, wofür man das gerade eigentlich braucht.
Nicht mehr einfach Code nachbauen
Beim Durcharbeiten ist mir aufgefallen, dass sich meine Art zu lernen inzwischen verändert hat.
Früher war es für mich durchaus normal, bei einem Kurs neben dem Projekt eine Musterlösung liegen zu haben. Wenn ich an einem Fehler nicht weiterkam, konnte ich irgendwann nachsehen und vergleichen. Damals konnte mich ein kleiner Syntaxfehler noch sehr lange beschäftigen.
Heute ist das anders. Ein Fehler führt wesentlich schneller zu einer systematischen Fehlersuche: Browser-Devtools, Fehlermeldung, Stack Trace, Logs, DOM-Inspektion und schrittweises Eingrenzen des Problems gehören inzwischen einfach zum Werkzeugkasten.
Dadurch ist die Musterlösung weniger wichtig geworden. Interessanter ist inzwischen die Frage:
Würde ich diese Lösung selbst so entwerfen?
Das war während des Kurses mehrfach der Fall.
Beim Breakout-Spiel habe ich beispielsweise die Struktur der Brick-Daten hinterfragt. Warum trägt jeder Brick die gleichen Eigenschaften wie Breite, Höhe, Padding und Offset mit sich herum? Warum heißt ein Zustand visible, wenn ein getroffener Brick eigentlich zerstört wird? Und warum werden die beiden Schleifenindizes als i und j bezeichnet, obwohl row und column die Absicht viel deutlicher machen würden?
Nicht jede dieser Entscheidungen ist falsch. Für ein kleines Tutorial-Projekt sind sie durchaus nachvollziehbar. Aber sie sind eben auch nicht die einzig mögliche Lösung.
Genau diese Unterscheidung finde ich beim Lernen inzwischen wichtig: Man sollte verstehen, was ein Code tut, aber auch erkennen, welche Teile davon nur eine Designentscheidung des Autors sind.
Canvas war für mich der interessantere Teil
Die Grundlagen von JavaScript waren für mich überwiegend eine Auffrischung. Interessanter war die Arbeit mit dem Canvas.
Ein Canvas funktioniert anders als das DOM. Ein Button kann einen click-Event auslösen und als DOM-Element direkt angesprochen werden. Ein einzelner Brick in einem Canvas ist dagegen kein eigenes Browser-Element. Er ist nur eine Datenstruktur, deren Position anschließend gezeichnet wird.
Damit kommt ein anderes Programmiermodell ins Spiel:
Zustand aktualisieren
↓
Kollisionen prüfen
↓
Canvas neu zeichnen
↓
nächster Frame
requestAnimationFrame() ist dafür wesentlich wichtiger als klassische DOM-Events. Die Bewegung des Balls oder Paddles wird nicht durch ein einzelnes Browser-Event ausgelöst, sondern innerhalb einer kontinuierlichen Game Loop aktualisiert.
Das war für mich der eigentliche neue Denkbaustein des Projekts.
Tailwind war weniger überzeugend
Das letzte Projekt verwendet Tailwind CSS. Brad bindet Tailwind im Kurs über das CDN ein.
Ich habe stattdessen meine bereits vorhandene npm- und Webpack-Umgebung verwendet und das Projekt mit einer aktuellen Tailwind-Version integriert.
Dabei wurde gleichzeitig deutlich, warum Tailwind für viele Entwickler gewöhnungsbedürftig ist.
Klassen wie
flex flex-col md:flex-row gap-8 items-center
sind zwar kompakt, aber man muss zunächst das komplette Klassensystem im Kopf dekodieren.
Gleichzeitig ist das responsive Verhalten von Tailwind interessant: Die nicht präfixierte Klasse ist die mobile Ausgangsversion, während sm:, md:, lg: usw. Regeln für größere Bildschirmbreiten ergänzen oder überschreiben.
Ein kleiner Fehler wie ein fehlendes md:flex-row kann deshalb bereits dazu führen, dass ein komplettes Layout anders aussieht als erwartet.
Ich verstehe inzwischen besser, warum Tailwind beliebt ist. Trotzdem merke ich auch, dass ich klassisches CSS bei komplexeren Layouts manchmal leichter lesbar finde.
Webpack statt einfach alles über das CDN laden
Gerade das letzte Projekt war für mich deshalb interessant, weil ich es nicht exakt so umgesetzt habe wie im Kurs.
Statt Tailwind einfach über ein CDN einzubinden, habe ich Tailwind in meinen bestehenden Webpack-Workflow integriert.
Damit war plötzlich auch deutlich sichtbarer, was normalerweise hinter einem solchen Build steckt:
Source Code
↓
Webpack
↓
Tailwind / CSS-Verarbeitung
↓
JavaScript- und CSS-Build
↓
Browser oder Apache
Der Unterschied zwischen Entwicklungsserver und fertigem Build wurde dadurch ebenfalls deutlich.
webpack-dev-server liefert im Development-Workflow Dateien aus einem konfigurierten statischen Verzeichnis und verarbeitet die Webpack-Entries. Für die spätere Auslieferung benötigt man dagegen einen Production-Build, dessen erzeugte Dateien Apache oder ein anderer Webserver ausliefert.
Diese Trennung war für mich fast genauso lehrreich wie Tailwind selbst.
Eine interessante Nebenwirkung: Code Completion
Während des Kurses hatte ich zunächst den Eindruck, IntelliJ würde mir die exakten Lösungen von Brad Traversy vorhersagen.
Teilweise wurde mir beim Schreiben plötzlich genau die nächste Funktion vorgeschlagen, die auch in der Musterlösung existierte.
Die Erklärung war letztlich viel unspektakulärer: Ich hatte die Musterlösungen früher in einem Ordner innerhalb des Projekts abgelegt. IntelliJ hatte diesen Code damit selbst als Projektinhalt zur Verfügung.
Nachdem ich den Ordner ausgeschlossen hatte, wurden die Vorschläge deutlich allgemeiner.
Das war eine ganz gute Erinnerung daran, dass moderne IDEs einem beim Lernen sehr viel Arbeit abnehmen können. Gleichzeitig sollte man sich fragen, ob man gerade eine Lösung selbst entwickelt oder nur bestätigt, was die IDE bereits vorgeschlagen hat.
Fazit
Der Kurs war für mich vor allem eine gute Auffrischung von HTML, CSS und Vanilla JavaScript. Die kleinen Projekte machen das Lernen angenehm und sorgen dafür, dass man ständig etwas Funktionierendes in den Händen hält.
Noch wertvoller war für mich allerdings, dass ich den Code nicht mehr einfach nur reproduziert habe. An mehreren Stellen habe ich angefangen, Datenstrukturen, Benennungen und Architekturentscheidungen zu hinterfragen.
Besonders beim Canvas-Spiel und beim Übergang zu Webpack und Tailwind habe ich dadurch mehr gelernt als durch das reine Nachprogrammieren der Beispiele.
Ich würde den Kurs deshalb nicht als vollständige moderne Frontend-Ausbildung betrachten. Dafür sind Themen wie moderne Frameworks, Testing, Accessibility, Tooling und größere Anwendungsarchitekturen natürlich viel umfangreicher.
Als kompakte Sammlung kleiner Vanilla-JavaScript-Projekte und als Auffrischung der Grundlagen hat er für mich aber genau das erfüllt, was ich mir davon versprochen habe.
Und das nächste Projekt werde ich vermutlich wieder selbst strukturieren.
Schreibe einen Kommentar