25. März 2026
In Code Reviews tauchen immer dieselben Responsive-Fehler auf. Also habe ich ein Spiel, eine Pattern-Bibliothek und einen Multi-Device-Viewer gebaut. Hier ist das Framework dahinter.
4 Min. Lesezeit
Ich reviewe immer wieder dieselben Responsive-Bugs. Ein max-width: 768px, das mit einem min-width: 768px kollidiert. Ein useMediaQuery-Aufruf, der beim ersten Render das falsche Layout anzeigt. Ein Hero-Bild, das 2 MB auf einem Handy ladt. Die Entwickler, die diesen Code schreiben, sind keine Anfanger. Sie hatten nur nie einen Ort, um ein Gefuhl dafur zu entwickeln, wie "resilient" im Vergleich zu "fragil" aussieht.
Diese Frustration hat zu Can't Resize gefuhrt.
Anfang des Jahres habe ich Can't Maintain gestartet, ein Spiel uber React Component API Design. Uber 5.000 Entwickler haben es gespielt. Beim Beobachten, wie sie gelernt haben, ist mir etwas aufgefallen: Die Kombination aus einer schnellen interaktiven Challenge und einer Referenzbibliothek mit guten und schlechten Beispielen ist erstaunlich effektiv. Die Leute spielen das Spiel, liegen ein paar Mal falsch und lesen dann die Erklarungen. Das Spiel erzeugt die Neugier. Die Bibliothek stillt sie.
Also habe ich dasselbe Framework beibehalten und auf ein anderes Problem angewandt.
Can't Resize ist nicht nur ein Spiel. Es sind drei Dinge, die zusammenarbeiten.
Der Viewer ermoglicht es, jede URL gleichzeitig auf Handys, Tablets und Desktops anzuzeigen. Scrolle, klicke und navigiere in einem Viewport und alle anderen folgen. Es funktioniert mit localhost. Man sieht seine Responsive-Bugs in Echtzeit, statt standig die Chrome DevTools hin und her zu schalten.
Play bietet 10 Code-Challenges Seite an Seite. Ein Snippet ist fragil, das andere resilient. Man wahlt, welches besser ist. Das Spiel trackt den Score, unterstutzt tagliche und wochentliche Seeds, damit das Team mit demselben Set gegeneinander antreten kann, und verlinkt jede Antwort zuruck zur Pattern-Bibliothek.
Learn ist die Referenzbibliothek. 128 Patterns in 16 Kategorien: Media Queries, Container Queries, Fluid Typography, Viewport Units, Flexbox, Grid, Responsive Spacing, Overflow Handling, Breakpoint Hooks, Responsive Props, Conditional Rendering, Responsive Images, MUI Responsive, Tailwind Responsive, haufige Fehler und Testing-Strategien. Jedes Pattern zeigt den Code, den man vermeiden sollte, den Code, den man bevorzugen sollte, und erklart warum.
Dokumentation erklart, wie man eine API benutzt. Sie sagt nicht, welcher von zwei gultigen Ansatzen in sechs Monaten Probleme macht. Das "vermeiden vs. bevorzugen"-Format erzwingt einen Vergleich. Man sieht beide Optionen, bildet sich eine Meinung und liest dann, warum eine besser ist. So entsteht Intuition.
Hier ein Beispiel. Was ist besser?
tsx// Option Afunction Features() {const isMobile = useMediaQuery("(max-width: 600px)");return (<Stack direction={isMobile ? "column" : "row"}><FeatureCard /></Stack>);}// Option Bfunction Features() {return (<Stack direction={{ xs: "column", sm: "row" }}><FeatureCard /></Stack>);}
Wer B gewahlt hat, liegt richtig. MUIs responsive Prop-Objekte werden zu CSS Media Queries kompiliert. Kein Hook, kein Re-Render, kein SSR-Flash. Option A gibt beim Server-Side Rendering standardmassig false zuruck. Mobile Nutzer sehen also fur einen Sekundenbruchteil das Desktop-Layout, bevor React hydratisiert und es korrigiert.
Das ist die Art Fehler, die man auf einer Docs-Seite lesen und sofort wieder vergessen kann. Aber wenn man ihn in einem Spiel falsch beantwortet und dann die Erklarung liest, bleibt er hangen.
Eine Sache, die mir bei Can't Maintain aufgefallen ist: Eine flache Liste von Kategorien kann uberwaltigend wirken. Deshalb hat Can't Resize einen "Hier starten"-Bereich auf der Learn-Seite, der funf Kategorien in einer bestimmten Reihenfolge empfiehlt: Media Queries, Flexbox Patterns, Grid Patterns, Responsive Props und Common Mistakes. Einsteiger bekommen einen klaren Weg, ohne dass fur Fortgeschrittene etwas versteckt wird.
Jede Kategoriebeschreibung enthalt ausserdem einen "Das brauchst du, wenn..."-Trigger. Statt nur zu sagen, was die Kategorie abdeckt, beschreibt sie das reale Szenario, in dem man es brauchen wird. "Das brauchst du, wenn eine Full-Screen Hero-Section hinter der mobilen Browser-Toolbar verschwindet." Diese Art von Verankerung macht das Abstrakte konkret.
Can't Resize ist das zweite Projekt in der "Can't"-Serie. Can't Maintain behandelt React Component API Design. Can't Resize behandelt Responsive Design Patterns. Jede Seite verlinkt zu den anderen, damit Spieler, die eines mogen, den Rest entdecken konnen. Gleiches Format, anderes Thema.
Das Muster ist beabsichtigt: ein Spiel, um Intuition aufzubauen, eine Referenzbibliothek, um das Verstandnis zu vertiefen, und ein Werkzeug, um das Gelernte anzuwenden. Wenn es ein Frontend-Thema gibt, bei dem Entwickler immer wieder dieselben vermeidbaren Fehler machen, ist es ein Kandidat fur das nachste Projekt.
Das Ganze ist Open Source, kostenlos und braucht keine Registrierung.
Wenn das Team weiterhin max-width: 768px schreibt oder alles in useMediaQuery verpackt, schick ihnen den Link. Drei Minuten im Spiel bringen mehr als ein weiterer Code-Review-Kommentar.
