# GitHub, CSS-in-JS en kritisch blijven over je output

> GitHub haalde CSS-in-JS uit GitHub.com en renderde pagina’s tot 55% sneller. Een goede reden om als developer kritisch te blijven over wat je oplevert.

Gepubliceerd: 2026-10-15 · Feiten gecheckt op 2026-10-15
URL: https://sobra.be/nostrabramus/github-css-in-js/
Gevonden via: https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/

GitHub legde [op 25 september 2026 uit](https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/) hoe ze CSS-in-JS volledig uit GitHub.com hebben gehaald, en hun pagina's werden er een pak sneller van. Ik ben het eens met hun keuze. Toch wil ik er geen manifest tegen CSS-in-JS van maken. Voor mij is het vooral een herinnering om als developer kritisch te blijven over wat je uiteindelijk oplevert.

## Wat GitHub won met CSS Modules

GitHub zette eerst de componenten van Primer React om van styled-components naar CSS Modules. Daarna volgden de duizenden losse `sx`-props in de codebase. Sinds juni 2026 draait de hele site op CSS Modules.

Na de Primer-migratie duurde het renderen van een pagina op de server 55% minder lang. De `sx`-migratie leverde per pagina nog eens tot 22% op. CSS-in-JS maakt de stijlen aan terwijl de pagina draait, en dat kost tijd, zeker met veel componenten. CSS Modules levert gewoon een stylesheet mee met de HTML. De laatste 895 props haalden twee ontwikkelaars met Copilot-agents weg in drie weken.

## Veel manieren om CSS te schrijven

Gewone CSS, SCSS, CSS Modules, CSS-in-JS, utility classes: er zijn veel manieren om CSS te schrijven. Ze lossen elk een ander probleem op, en elk heeft zijn plek. Ik heb zelf in verschillende projecten met CSS-in-JS gewerkt, en het werkt. De prijs die GitHub zag, zit in de runtime.

Tailwind is weer iets anders. Het [scant je bestanden en schrijft een statisch CSS-bestand weg](https://tailwindcss.com/docs/installation), zonder runtime. Het is heel populair en zeker waardevol voor dashboards en gestructureerde platformen. Daar zit de afweging eerder in het onderhoud: je schrijft CSS-properties als classes in je HTML. Werk je niet heel component-based, dan pas je dezelfde buttonstijl zo op 200 plekken aan wanneer die er anders moet uitzien.

Zelf hou ik van eenvoud, en van ieders sterkte: HTML voor semantiek en inhoud, CSS voor de weergave, JavaScript voor logica. De complexiteit zet ik liefst in de build, met SCSS, CSS Modules of gewoon PostCSS. Wat naar de browser gaat, blijft zo traditioneel mogelijk HTML, CSS en JavaScript. Op [deze site](https://sobra.be/) doe ik het ook zo. Dat loont voor mij altijd, in performance, in security en in bundle size.

## Kritisch blijven over de output

Als developers gaan we vaak heel snel heel complex, en maken we het onszelf soms makkelijk ten koste van de user experience. Met code die door AI geschreven is, komt dat nog meer op ons af. Ik werk graag met AI, maar we moeten waakzaam blijven. Een homepage van 30 MB die live zotte queries uitvoert, is niet de bedoeling.

Kijk dus naar de dev experience, maar evengoed naar de output en de performance. Blijf open minded, en hou het simpel waar het kan.

## Bronnen

- [Improving site performance by shipping more CSS (The GitHub Blog)](https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/)
- [Installing Tailwind CSS with Vite (Tailwind CSS docs)](https://tailwindcss.com/docs/installation)