Titelbild: Warum ich Breakpoint Preview gebaut habe
Zurück zum Blog
Frontend · · 4 min read

Warum ich Breakpoint Preview gebaut habe

Kurze Geschichte über Tab-Wechsel beim responsiven Bauen und ein CLI, das alle Viewports gleichzeitig zeigt.

dxtoolingopen-source

Irgendwann saß ich da mit zwei Monitoren, vier Browser-Fenstern und der vagen Hoffnung, dass die Mobile-Variante schon irgendwie passen würde. Daneben DevTools im Responsive-Mode, einmal kurz auf 375 stellen, dann zurück auf Desktop, dann nochmal auf 768, dann gemerkt, dass ich im falschen Tab bin. So baut man keine responsiven Sites. So baut man Tab-Wechsel.

Das Nervige daran ist nicht die Zeit pro Wechsel. Es ist die Reibung im Kopf. Jedes Mal wenn ich von Desktop auf Mobile springe, verliere ich den Faden, was ich gerade vergleichen wollte. Daraus ist breakpoint-preview geworden.

Was es macht

Ein CLI, das deine laufende Seite gleichzeitig in mehreren Viewport-Breiten nebeneinander rendert. Default sind 375, 768, 1024 und 1440. Eine URL eingeben, alle vier reagieren. Hot Reload läuft durch wie gewohnt, weil das Tool einen kleinen Proxy vor dein Dev-Server hängt und die WebSocket-Verbindungen einfach durchreicht.

375px
Mobile
768px
Tablet
1024px
Laptop
1440px
Desktop
Vier Viewports gleichzeitig, eine URL, ein Browser-Tab.

Jedes Viewport hat eine eigene URL-Bar, du kannst also einen einzelnen Frame auf eine andere Route schicken, um eine spezifische Mobile-View zu prüfen, während Desktop auf der Übersicht bleibt. Scroll-Sync ist optional, einzelne Viewports lassen sich ausblenden und der State bleibt über Reloads erhalten.

Wie ich es nutze

Beim Bauen lasse ich es im zweiten Fenster offen, während die DevTools im Haupt-Tab Desktop bleiben. Sobald ich an einer Card oder einem Layout arbeite, sehe ich beim Speichern direkt, ob Tablet bricht oder Mobile zu eng wird, ohne aktiv hinzugucken.

Bei Bug-Reports von Designer:innen oder Kund:innen (“kannst du das mal in Mobile checken”) spare ich mir das Hin-und-her zwischen den Größen. Ich öffne das Tool, scrolle einmal durch, sehe alle vier Breakpoints in einem Blick.

Für AI-Agents liegt eine SKILL.md im Repo, sodass Claude Code oder Codex das Tool selbst starten und durch Viewports navigieren können, wenn sie an responsivem Code arbeiten. Funktioniert mit jedem Framework, das einen Dev-Server hat: Vite, Next, SvelteKit, Astro, Remix, plain HTML. Letzter Schritt vor dem Push: einmal npx breakpoint-preview http://localhost:5173, durchscrollen, fertig.

Wie es funktioniert

Unter der Haube ein lokaler Proxy, der alle Requests an deinen Dev-Server forwarded. Das macht alle Viewports same-origin, was Scroll-Sync und Per-Viewport-URLs erst möglich macht. WebSocket-Verbindungen für HMR werden transparent durchgereicht. Keine Extension, keine Config-Datei, keine Dependencies außer Node selbst. Mit --app Flag öffnet es als Standalone-Window ohne Browser-Chrome, dann fühlt es sich an wie eine eigene App.

Was hängenbleibt

Was mir nach dem Bauen geblieben ist, ist nicht das Tool selbst, sondern wie viel Tab-Switching ich vorher als normalen Teil der Arbeit hingenommen hatte. Sobald die vier Frames nebeneinander stehen, fällt einem auf, wie oft man eigentlich in den Mobile-View springt, ohne es zu merken. Seitdem teste ich responsiv beiläufig statt am Ende, und das ändert mehr am Endergebnis als jede einzelne Mobile-Korrektur.

Mehr lesen

Weitere Artikel rund um Frontend, Design und Technologie.

Zurück zum Blog
Datenschutz-Hinweis

Diese Website verwendet ausschließlich technisch notwendige Cookies. Es werden keine Analyse- oder Marketing-Cookies eingesetzt. Datenschutzerklärung