# GitHub, CSS-in-JS and staying critical about your output

> GitHub removed CSS-in-JS from GitHub.com and rendered pages up to 55% faster. A good reason for developers to stay critical about what they ship.

Published: 2026-10-15 · Facts checked on 2026-10-15
URL: https://sobra.be/en/nostrabramus/github-css-in-js/
Found via: https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/

GitHub [explained on 25 September 2026](https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/) how it removed CSS-in-JS from GitHub.com entirely, and its pages got a lot faster. I agree with the choice. Still, I don't want to turn it into a manifesto against CSS-in-JS. For me it's mostly a reminder that, as developers, we need to stay critical about what we actually ship.

## What GitHub gained with CSS Modules

GitHub first moved the Primer React components from styled-components to CSS Modules. Then came the thousands of loose `sx` props in the codebase. Since June 2026 the whole site runs on CSS Modules.

After the Primer migration, server-side rendering took 55% less time. The `sx` migration added up to 22% per page on top of that. CSS-in-JS creates the styles while the page runs, and that takes time, especially with lots of components. CSS Modules simply ships a stylesheet with the HTML. Two engineers with Copilot agents cleared the last 895 props in three weeks.

## Many ways to write CSS

Plain CSS, SCSS, CSS Modules, CSS-in-JS, utility classes: there are many ways to write CSS. Each solves a different problem, and each has its place. I've used CSS-in-JS in several projects myself, and it works. The cost GitHub saw is in the runtime.

Tailwind is something else again. It [scans your files and writes a static CSS file](https://tailwindcss.com/docs/installation), with no runtime. It's hugely popular and definitely valuable for dashboards and structured platforms. There the trade-off is more about maintenance: you write CSS properties as classes in your HTML. If you don't work in a strongly component-based way, you can end up changing the same button styling in 200 places when it needs to look different.

I like simplicity, and letting each part do what it's good at: HTML for semantics and content, CSS for the visual layer, JavaScript for logic. I'd rather put the complexity in the build, with SCSS, CSS Modules or just PostCSS. What goes to the browser stays as traditional as possible: HTML, CSS and JavaScript. That's how I built [this site](https://sobra.be/en/) too. For me it always pays off, in performance, security and bundle size.

## Staying critical about the output

As developers, we often go very complex very quickly, and sometimes make things easy for ourselves at the expense of the user experience. With AI-written code, that only happens more. I love working with AI, but we need to stay alert. A 30 MB homepage that runs crazy queries live is not the idea.

So look at the developer experience, but just as much at the output and the performance. Stay open-minded, and keep it simple where you can.

## Sources

- [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)