GitHub hat CSS-in-JS von seiner Website verbannt und gestaltet die Oberfläche seit Juni 2026 vollständig mit CSS Modules. Mit den umgebauten Grundkomponenten brauchte der Server 55 % weniger Zeit, um eine Seite zu rendern. Die letzten 895 Altfälle im Code erledigten zwei Entwickler mit Copilot-Agenten in drei Wochen.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenInhalt 5 Abschnitte
„Für neue Projekte würde ich weder styled-components noch die meisten anderen CSS-in-JS-Lösungen empfehlen“, schrieb Evan Jacobs, Hauptentwickler von styled-components, im März 2025.[2] Auf dieser Bibliothek baute damals ein großer Teil der GitHub-Oberfläche auf. Den Ausstieg schildern die Primer-Entwickler Josh Black und Marie Lucca im GitHub-Blog.[1]
Das Wichtigste in Kürze
- GitHub liefert alle Stile seit Juni 2026 als statische CSS-Dateien aus, styled-components ist aus dem Code verschwunden.
- Mit den umgebauten Primer-Komponenten sank die Server-Renderzeit einer Seite um 55 %, das Initialisieren der Komponenten dauerte 25 % kürzer.
- Felddaten zur Ladezeit bei echten Nutzern, etwa Core Web Vitals, veröffentlicht GitHub nicht.
Warum wird CSS-in-JS auf großen Seiten langsam?
Bei CSS-in-JS entstehen die Stile erst beim Rendern. Die Bibliothek wertet JavaScript-Objekte aus, erzeugt daraus CSS-Regeln und fügt sie als style-Element in die Seite ein. Seit 2023 wuchs bei GitHub die Zahl der Komponenten pro Seite so stark, dass Seitenaufbau, Server-Rendering und Stil-Updates langsamer wurden.[1]
Wie viel Verwaltung dahintersteckt, zeigt die Next.js-Dokumentation. Laufzeit-Bibliotheken brauchen dort eine eigene Registry, die jede Regel beim Rendern einsammelt, und laufen nur in Client Components.[3] Am teuersten war bei GitHub die sx-Prop, deren Stilobjekte die Bibliothek bei jedem Rendern neu verarbeitete.
CSS Modules drehen das Prinzip um. Die Stile liegen als gewöhnliche CSS-Datei neben der Komponente, ein Build-Schritt macht die Klassennamen lokal eindeutig und bündelt alles zu statischen Stylesheets. Beim Seitenaufruf muss kein Styling-Code mehr laufen.
Wie baute GitHub um, ohne die Plattform zu gefährden?
Das Primer-Team stellte Komponente für Komponente um. Jede neue Fassung hing an einem Feature-Flag und ging erst an die eigene Belegschaft, dann an alle Nutzer; visuelle Regressionstests prüften, ob alte und neue Variante gleich aussahen. Im Dezember 2024 war das Designsystem Primer komplett umgestellt.[1]
Der Produktcode blieb die größere Baustelle. Acht Entwickler migrierten im Wechsel 6.419 sx-Props in sechs Monaten, unterstützt von einem VS-Code-Plug-in und einem Codemod. Die restlichen 895 räumten im April 2026 zwei Entwickler mit Copilot-Coding-Agenten in drei Wochen ab.[1] Ob diese Restfälle leichter waren, verrät GitHub nicht.
Der Umbau im Zeitverlauf
Ist CSS-in-JS damit am Ende?
Jacobs begründete den Wartungsmodus von styled-components damit, dass die Context-API in React Server Components fehlt und sich das Ökosystem von CSS-in-JS abgewandt hat, während Tailwind boomt.[2]
Die Idee, Stile direkt neben der Komponente zu schreiben, lebt ohne Laufzeit weiter. Die Werkzeuge vanilla-extract und Panda CSS erzeugen ihre Stylesheets beim Build statt im Browser.[4][5] Beide stehen auf der Liste der Bibliotheken, die Next.js im App Router unterstützt.[3]
Stile, die erst beim Rendern entstehen, kosten bei jedem Seitenaufruf Rechenzeit. GitHub brauchte drei Jahre, um diese Dauerrechnung aus dem Code zu streichen.
Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Unternehmen mit React-Frontend jetzt prüfen?
Ladezeit und Reaktionsfähigkeit fließen über die Core Web Vitals in Googles Ranking ein, seit dem Mai-Update als gemeinsamer Gesamtwert. GitHubs Zahlen zeigen, wo Laufzeit-CSS Zeit kostet: beim Server-Rendering und beim Initialisieren im Browser.
- Prüfen Sie in der package.json, ob styled-components, Emotion oder eine ähnliche Laufzeit-Bibliothek steckt.
- Messen Sie Server-Renderzeit und Interaction to Next Paint vor dem Umbau, etwa mit einem Werkzeug aus unserem Vergleich der Website-Monitoring-Tools.
- Bauen Sie gerne nach GitHubs Muster um: schrittweise, hinter Feature-Flags und mit visuellen Regressionstests.
- Lassen Sie Coding-Agenten die mechanische Umstellung erledigen und jede Änderung von Menschen prüfen, denn KI-Code ist billig erzeugt und teuer im Unterhalt.
Neue Projekte starten besser ohne Styling-Laufzeit, denn schnelle Software berechnet ihre Stile einmal beim Build statt bei jedem Seitenaufruf.
Quellen
5 Quellen anzeigenQuellen ausblenden
- GitHub BlogImproving site performance by shipping more CSS, Josh Black und Marie Lucca
- styled-components auf Open CollectiveThank you, Evan Jacobs
- Next.js-DokumentationHow to use CSS-in-JS libraries
- vanilla-extractZero-runtime Stylesheets-in-TypeScript
- Panda CSSProjektseite
Mehr Newshunger?
- Die letzte Zeile im responsiven CSS-Raster füllen
- Maschinenlesbares Designsystem: Erst Code Connect macht KI im Frontend produktiv
- Design Tokens: Warum die semantische Ebene über Ihr Design-System entscheidet
- CSS text-fit: Der Browser skaliert die Schrift jetzt selbst auf Containerbreite
- Sie haben kein Design-System, sondern eine Komponenten-Bibliothek
- State of CSS 2026: Nur 28 Prozent des CSS kommen von der KI
- CSS Grid Lanes: Das native Masonry-Layout kommt ohne JavaScript
