Die F1 Anwendung hatte über zwei Jahre ein konsistentes, und unspektakuläres Aussehen. W3.CSS — ein leichtgewichtiges CSS-Framework von W3Schools — tat seinen Dienst zuverlässig. Hellgrauer Hintergrund, weiße Karten, ein bisschen Farbe und Icons in Header-Balken. Sehr Funktional. Und zum Wiederanfang mit der HTML/CSS/JSP Programmiererei wie gemacht für mich.
Das es Zeit war für was Neues, merkte ich als Claude Code auf meinem Entwicklungs-Mac installiert habe, und aufforderte eine „zuletzt hinzugekommen"-Seite für die F1-Web Site im Design von Plex zu machen. Ziemlich gut war der erste Aufschlag. Zu gut um wegzuschauen.
W3.CSS — eine ehrliche Bilanz
W3.CSS hat gute Dienste geleistet. Das Framework ist minimal, braucht kein JavaScript, und die Klassen sind intuitiv. w3-card-4, w3-container, w3-blue — man liest den HTML-Code und weiß sofort, was dabei rauskommt.
Der Haken: W3.CSS ist nicht für komplexe, konsistente Anwendungs-UIs gemacht. Es gibt keine CSS Custom Properties (also keine Variablen), denn im wesentlichen ist W3CSS ein Satz CSS Makros. Schlank und einfach gehalten. (Erinnert ein bisschen an den Unterschied von LaTeX und TeX in den 90iger Jahren).
Als ich die von Claude Code generierte „zuletzt hinzugekommen" JSP sah, war die Zeit für ein Redesign und ein "Design-Theme" gekommen. Ich habe es N3 genannt — wie NextThree, das F1-Site Projekt.
Was N3 sein sollte
Die Anforderungen an das Design ergaben sich schrittweise: Plex-like dunkler Hintergrund, goldener Akzent, eine feste Sidebar links mit Toggle-Funktionen, und — das war wichtig — alles über sog. CSS Custom Properties steuerbar. Wenn man die Farbe des Hintergrunds an einer einzigen Stelle ändert, dann ändert sie sich überall.
Das Farbschema, das dabei entstand:
:root { --bg: #1c1c1c /* Seitenhintergrund */
--sidebar-bg: #111111 /* Sidebar */
--accent: #e5a00d /* Gold — das Erkennungsmerkmal */
--text: #e0e0e0 /* Fließtext */
--text-muted: #888888 /* Sekundärtext */
--card-bg: #252525 /* Karten */
--border: #2e2e2e /* Linien und Rahmen */
}Dazu kam ein Grey Mode — das ist kein zweites Theme, sondern ein Satz Override-Variablen, der dasselbe CSS in ein helles Layout verwandelt. Aktiviert per body.grey-mode, persistiert im localStorage des Browsers.
Und eine Compact Sidebar, die per Klick auf 56px zusammenschrumpft und nur noch Icons zeigt. Auch das: ein Toggle, ein Attribut, eine CSS-Variable. Das mit dem localStorage war neu für mich — aber nicht für Claude Code.
Die neue Driver-Seite im N3 Dark Theme — Sidebar, Tabs, Flagge, Statistiken
Claude Code — der Entwicklungspartner
Hier wird es interessant. Und anders als in den früheren Blog-Einträgen, wo ich von ChatGPT als Code-Generator berichtet habe. Claude Code ist etwas anderes. Es ist kein Fenster im Browser, in das man eine Frage eintippt und eine Antwort zurückbekommt. Claude Code läuft im Terminal, direkt im Projektverzeichnis. Es liest Dateien, schreibt Dateien, führt Build-Befehle aus, committet in Git — und hat dabei den gesamten Kontext des Projekts im Blick. Ich nutze Claude Code aus IntelliJ heraus, und sehe dann das Ergebnis in der IDE direkt.
Der Unterschied zu einem klassischen Code-Assistenten ist konzeptuell: Man führt kein Gespräch über den Code, man entwickelt mit und in dem Code. Claude Code kann eine Frage wie „Welche Methoden in Tools.java werden nirgends mehr aufgerufen?" beantworten — nicht durch Raten, sondern durch tatsächliches Durchsuchen aller JSP- und Java-Dateien im Projekt.
Wie das in der Praxis aussieht
1. Die Design Migration — JSP für JSP
Ein „Big Bang"-Redesign — alles auf einmal — war keine Option. Zu viele Seiten, zu viel Risiko, zu unübersichtlich. Stattdessen haben wir (interessant das ich von "Wir" spreche , oder?) es JSP für JSP gemacht. Das Vorgehen war dabei immer gleich und hat sich schnell als das richtige erwiesen.
Zuerst: Claude Code die alte JSP lesen lassen. Nicht überfliegen — wirklich lesen. Welche Daten kommen aus der Datenbank? Welche Java-Variablen werden im HTML verwendet? Welche URLs werden generiert? Was macht die Seite eigentlich?
Dann: konvertieren. Die W3.CSS-Klassen raus, N3-Struktur rein. page-header, section-divider, das JSPF-Include für die Sidebar, n3Sidebar.js am Ende. Die Daten-Logik bleibt unangetastet — nur die Hülle ändert sich. Das war das Prinzip dabei: nie Datenbanklogik und Darstellung gleichzeitig anfassen.
Und dann: iterieren. Im Browser öffnen, schauen, was nicht stimmt. Abstände anpassen, Schriftgrößen korrigieren, Tabellen-Layouts testen. Dieser Teil ist nicht delegierbar — das visuelle Ergebnis kann nur der Programmierer selbst beurteilen. Claude Code kann das CSS schreiben, aber nicht sehen, ob die Karte zu breit ist oder die Flagge zu nah am Namen klebt. Der Browser ist das letzte Wort.
Mit jeder migrierten Seite wurde das N3-Theme selbst besser. Eine Seite hatte ein Layoutproblem, das eine neue CSS-Klasse erforderte — die kam in n3-driver.css und stand sofort allen anderen Seiten zur Verfügung. Das Theme ist nicht am Anfang entworfen und dann implementiert worden. Es ist durch die Migration iterativ gewachsen.
2. Reenginering statischer Seiten zu jsp
Einige Seiten der WebSite waren nach wie vor statisch - sprich sie wurden vom Program myMemphis mit den Dateien und Daten in den Datenbanken statisch erzeugt. Jedesmal wenn es neue Dateien oder Daten gab, mussten die Programme laufen und die HTML Seiten erzeugen. Im Verlauf der N3 Migration habe ich die verblieben statischen Seiten auf die dynamischen JSPs umgestellt - genauer umstellen lassen, Ein ziemlich gute Case for Claude Code: Die HTML Seiten und existierenden JSPs als Muster - das hat dann schon gereicht um den Code zu erzeugen.
3. Housekeeping — ungenutzte Methoden finden
Nach zwei Jahren Entwicklung hatte sich in Tools.java einiges angesammelt. Methoden, die für das alte W3.CSS-Layout geschrieben worden waren und nun verwaist dasaßen. Ich habe Claude Code gebeten, das Repository durchzusuchen und alle Methoden und Includes zu finden, die nirgends mehr referenziert werden.
Das Ergebnis: 4 Methoden in Tools.java (GetMainHeader, GetMainPhotoHeader, WinsOfCar, formatWins), 5 veraltete JSPF-Includes (_sidebar.jspf, _head.jspf, _driverHeader.jspf, _photoModal.jspf, sidebar.js) — alles Überreste aus der W3.CSS-Ära, längst durch N3-Äquivalente ersetzt. Alles raus. Der Code wurde schlanker und die Verwirrung beim Lesen geringer.
4. JSP-Umbenennung — acht Dateien, alle Referenzen
Das Projekt hatte über die Zeit eine uneinheitliche Namenskonvention für die JSPs entwickelt. Die Team-Seiten hießen CarResults.jsp und CarPhotos.jsp, aber die Fahrer-Seiten hießen DriverCars.jsp und DriverCarResults.jsp. Es gab ResultSeason.jsp und Results.jsp — keine erkennbare Systematik.
Die Lösung: Umbenennen nach "Familie".
- Team*.jsp
- Driver*.jsp
- Season*.jsp.
Acht Dateien. Und alle Aufrufe in allen anderen JSPs, JSPF-Includes, Markdown-Dateien und statischen HTML-Seiten mussten angepasst werden. Das ist genau die Art von Aufgabe, die man früher entweder mit einem aufwändigen Shell-Skript erledigt hat oder — häufiger — einfach vermieden hat, weil das Risiko zu hoch war, eine Referenz zu vergessen.
Claude Code hat das mit git mv für die Dateien selbst und sed für alle Referenzen durchgeführt. Dabei passierte etwas Lehrreiches: Ein sed-Befehl, der mehrere Ersetzungen in einem Durchlauf macht, schoss sich selbst ins Bein. CarResults.jsp wurde zu TeamCarResults.jsp — und dann griff das Muster Results.jsp erneut zu und machte daraus TeamCarSeasonRaceResult.jsp. Ein klassischer Folgefehler. Den habe ich bemerkt (weil visuell sichtbar — Human in the Loop) und Claude Code hat dann erklärt und einen Korrektur-Pass durchgeführt.
5. Header.tmpl — Doku, dann Löschen
Im Projekt gab es eine Datei namens Header.tmpl. Eine mini Template-Engine: zwölf nummerierte HTML-Blöcke für jeden möglichen Navigations-Zustand einer Seite, Java liest den richtigen Block heraus und ersetzt Platzhalter wie ${Team} oder ${PrevCar}. Keine externe Library, kein Framework — handgebaut, elegant in seiner Art.
Ich habe Claude Code gebeten, dieses Konzept zu dokumentieren, bevor wir es löschen. Zum Teil aus Sentimentalität, weil es ganz gute Handarbeit war. Das Ergebnis ist ein vollständiger Archivierungs-Artikel — als Markdown und als HTML-Seite mit Grey-Mode-Toggle — der erklärt, wie es funktioniert hat, warum es durch N3-JSPF-Includes abgelöst wurde, und was beide Ansätze verbindet: das ReadFile2StringExStartEnd-Muster, das im Projekt weiterlebt — für die SQL-Queries in QUERIES.sql.
Die Architektur von N3
Das N3-Theme basiert auf drei gemeinsam genutzten Dateien — n3.css für Variablen, Sidebar und Basis-Layout, n3-driver.css für Karten, Tabellen und Grid-Layouts, und n3Sidebar.js für den interaktiven Teil. Dazu kommen JSPF-Includes:
- _n3Sidebar.jspf — die Sidebar, einmal geschrieben, überall eingebunden
- _n3DriverHeader.jspf — Fahrer-Kopfzeile mit Tabs, Flagge, Siege, WM-Titel
- _n3TeamHeader.jspf — Team-Kopfzeile mit Logo-Band, Team-Farbe, Prev/Next
- _n3ResultHeader.jspf — Saison-Kopfzeile mit Runden-Navigation
Eine neue JSP braucht im Wesentlichen drei Dinge: die CSS-Includes im <head>, ein Request-Attribut (n3ActiveNav) das der Sidebar sagt, welcher Menüpunkt aktiv ist, und n3Sidebar.js am Ende vor </body>. Der Rest — Dark Mode, Compact Toggle, Hamburger-Menü — funktioniert automatisch.
Vorher – Nachher: Fahrer Wagen-Galerie mit Fahrzeug-Karten im W3 und N3 Theme
Grey Mode — dasselbe Theme, anderes Licht
Der Grey Mode ist eines meiner liebsten Features. Es ist kein separates Stylesheet, sondern ein Satz CSS-Overrides, der auf body.grey-mode reagiert:
body.grey-mode {
--bg: #efefef;
--sidebar-bg: #d7d7d7;
--text: #222222;
--card-bg: #ffffff;
--border: #cccccc;
/* --accent bleibt gold — das ist das Bekenntnis zum Branding */
}Derselbe HTML-Code, dieselben CSS-Klassen — aber die Seite sieht vollkommen anders aus. Tagsüber hell, abends dunkel. Der Toggle sitzt in der Sidebar, der Zustand wird im localStorage des Browsers gespeichert. Kein Reload nötig.
Was sich verändert hat — und was geblieben ist.
Das N3-Redesign ist kein Neustart. Die Datenbankabfragen, die Java-Klassen, die Servlet-Logik — alles das ist geblieben. Was sich geändert hat, ist die Präsentationsschicht: von externen CSS-Klassen zu eigenen Variablen, von zusammengestückelten Header-Strings zu sauber gekapselten JSPF-Includes, von hellem Hintergrund zu dark/grey.
Und das Werkzeug hat sich geändert. ChatGPT habe ich für Snippets genutzt und für Inspiration. Claude Code arbeitet auf einer anderen Ebene — es ist im Projekt zuhause. Es kennt die Dateinamen, die Methodensignaturen, die Commit-Historie. Es macht Vorschläge, die zur vorhandenen Struktur passen, und nicht zu einem generischen Java-Projekt, das es sich vorstellt.
Ob das die Zukunft der Softwareentwicklung ist? Vermutlich ein Teil davon. Wie damals mit Turbo C und den ersten IDEs, die einen beim Tippen verbessert haben: das Werkzeug nimmt einem nicht die Arbeit ab, es macht die Arbeit anders. Besser, wenn man es richtig einsetzt. Manchmal überraschend. Und manchmal muss man dem Werkzeug erklären, dass sed nicht mehrere Muster gleichzeitig auf denselben String anwenden soll.
Persönliche Erfahrungen — was ich gelernt habe
Nach einigen Wochen intensiver Arbeit mit Claude Code habe ich ein klareres Bild davon, was dieses Werkzeug verändert — und was es nicht verändert. Drei Dinge stechen heraus.
Den Code lesen. Wirklich lesen.
Das klingt selbstverständlich, ist es aber nicht. Wenn Claude Code eine 200-Zeilen JSP schreibt oder eine Java-Methode refaktoriert, ist die Versuchung groß, das Ergebnis kurz zu überfliegen, im Browser zu prüfen ob es funktioniert — und weiterzumachen. Das ist ein Fehler.
Den entstandenen Code muss man intensiv lesen, weil man sonst nicht versteht, was in der eigenen Anwendung passiert.
Ich habe mir angewöhnt: jede Datei, die Claude Code schreibt oder ändert, lese ich vollständig. Nicht als Misstrauensbeweis — als Lernprozess. Der Code ist nach der Lektüre auch meiner, nicht mehr nur seiner.
Den Fokus behalten — und sich nicht verlieren
Claude Code ist — und das meine ich wörtlich — sehr gesprächig. Es macht Vorschläge, weist auf verwandte Probleme hin, bietet Verbesserungen an, die man gar nicht verlangt hat. Das ist oft hilfreich. Manchmal ist es eine Ablenkung.
Ich bin mehr als einmal in eine Session gegangen mit dem Ziel, eine JSP zu migrieren, und eine Stunde später fand ich mich dabei, eine Methode in Tools.java zu refaktorieren, die nur entfernt mit dem ursprünglichen Ziel zu tun hatte. Das Ergebnis war nicht schlecht — aber es war nicht das, was ich vorhatte.
Die Lösung, die für mich funktioniert: zu Beginn jeder Session in einem Satz festlegen, was das Ziel ist. Und diesen Satz, wenn nötig, laut wiederholen. JETZT migrieren wir TeamGallery.jsp. Punkt. Alles andere kommt auf die Liste für später. Claude Code hilft bei dem, was man ihm gibt — aber es filtert nicht, was davon gerade wirklich dran ist. Das ist Aufgabe des Entwicklers.
Grenzen — visuelles Feedback
Die vielleicht wichtigste Erkenntnis: Claude Code ist blind. Nicht im übertragenen Sinne — buchstäblich. Es kann keine HTML-Seite im Browser sehen. Es kann nicht beurteilen, ob eine Karte zu breit ist, ob ein Text zu nah an den Rand rückt, ob die Farbe eines Hover-Effekts passt oder stört.
Das ist keine Schwäche, die sich irgendwann behebt — es ist eine strukturelle Grenze. CSS ist eine Sprache, deren Ergebnis und Wirkung im Auge des Betrachters liegt, nicht im Code. Man kann ein CSS-File syntaktisch korrekt schreiben, das im Browser schlimm aussieht.. Claude Code kann sagen, dass margin-left: var(--sidebar-width) korrekt ist. Es kann nicht sagen, ob der Inhalt damit gut aussieht.
Jede migrierte Seite habe ich deshalb auf drei Dinge geprüft: Funktion, Optik, dark/grey, schmale Sidebar. Auf dem Desktop, auf dem Handy, auf dem Pad. Ansichten, die Claude Code nicht sehen kann. Diesen Teil des Prozesses kann man nicht delegieren — und sollte es auch nicht wollen. Das visuelle Urteil bleibt das eigene.
Die Dokumentation
Am Ende des Redesigns stand etwas, das ich mir schon lange vorgenommen hatte: eine ordentliche Entwicklerdokumentation. Nicht für andere — für mich selbst. Das N3-Theme-Tutorial ist ein Step-by-Step-Guide für jede neue JSP-Seite. Die Doku zur Header.tmpl ist ein Archivschnipsel für das, was war. Beides gibt es als Markdown und als eigenständige HTML-Seite mit N3-Styling — natürlich mit Grey-Mode-Toggle.
Auch das hat Claude Code in einem Durchgang geschrieben — ehrlicherweise hätte ich das "von Hand" nie so gemacht.