GitHub, le CSS-in-JS et rester critique sur ce qu’on livre

GitHub a expliqué le 25 septembre 2026 comment il a entièrement retiré le CSS-in-JS de GitHub.com, et ses pages sont devenues nettement plus rapides. Je suis d’accord avec ce choix. Je ne veux pas pour autant en faire un manifeste contre le CSS-in-JS. Pour moi, c’est surtout un rappel : en tant que développeurs, nous devons rester critiques sur ce que nous livrons.

Ce que GitHub a gagné avec les CSS Modules

GitHub a d’abord migré les composants Primer React de styled-components vers des CSS Modules. Ensuite sont venues les milliers de props sx éparpillées dans le code. Depuis juin 2026, tout le site tourne sur des CSS Modules.

Après la migration de Primer, le rendu côté serveur a pris 55 % de temps en moins. La migration des sx a ajouté jusqu’à 22 % de gain selon les pages. Le CSS-in-JS crée les styles pendant l’exécution de la page, ce qui prend du temps, surtout avec beaucoup de composants. Les CSS Modules livrent une feuille de style avec le HTML. Deux développeurs, aidés d’agents Copilot, ont supprimé les 895 dernières props en trois semaines.

Beaucoup de façons d’écrire du CSS

CSS classique, SCSS, CSS Modules, CSS-in-JS, classes utilitaires : il existe beaucoup de façons d’écrire du CSS. Chacune résout un problème différent, et chacune a sa place. J’ai moi-même travaillé avec du CSS-in-JS dans plusieurs projets, et ça marche. Le coût que GitHub a constaté se trouve dans le runtime.

Tailwind, c’est encore autre chose. Il analyse vos fichiers et écrit un fichier CSS statique, sans runtime. Il est très populaire et utile pour des tableaux de bord et des plateformes structurées. Le compromis porte plutôt sur la maintenance : vous écrivez des propriétés CSS sous forme de classes dans votre HTML. Si vous ne travaillez pas de façon très orientée composants, vous risquez de modifier le même style de bouton à 200 endroits quand son apparence doit changer.

J’aime la simplicité, et que chaque langage fasse ce qu’il fait de mieux : le HTML pour la sémantique et le contenu, le CSS pour le rendu visuel, le JavaScript pour la logique. Je préfère mettre la complexité dans le build, avec du SCSS, des CSS Modules ou simplement PostCSS. Ce qui part vers le navigateur reste du HTML, du CSS et du JavaScript aussi classiques que possible. C’est aussi comme ça que j’ai construit ce site. Pour moi, ça paie toujours, en performance, en sécurité et en taille de bundle.

Rester critique sur ce qu’on livre

En tant que développeurs, nous allons souvent très vite vers beaucoup de complexité, et nous nous facilitons parfois la vie au détriment de l’expérience utilisateur. Avec le code écrit par l’IA, ça arrive encore plus. J’aime travailler avec l’IA, mais nous devons rester vigilants. Une page d’accueil de 30 Mo qui lance des requêtes délirantes en direct, ce n’est pas le but.

Regardez donc l’expérience développeur, mais tout autant ce que vous livrez et la performance. Restez ouvert, et gardez les choses simples quand c’est possible.