GitHub migra su sistema de diseño a CSS Modules y recorta un 55 % el render en servidor
Primer deja atrás CSS-in-JS después de convertir todos sus componentes en diciembre de 2024; el resto de la plataforma va por el mismo camino.
GitHub ha terminado de sacar CSS-in-JS de Primer, el sistema de diseño con el que la plataforma construye desde botones hasta migas de pan. Todos sus componentes corren ya sobre CSS Modules, y el cambio dejó dos cifras: un 55 % menos de tiempo para renderizar una página en servidor y un 25 % menos en la inicialización de los componentes de una página. La conversión se cerró en diciembre de 2024 y la compañía trabaja ahora en extenderla al resto de su código.
El problema arranca en 2023, cuando el número de componentes en ciertas páginas empezó a crecer sin freno. Con la solución anterior eso se pagaba en tres sitios a la vez: la primera carga se alargaba porque los estilos se inicializaban en el cliente, el renderizado en servidor se degradaba al desplazarse allí la recolección de estilos, y cada componente añadido encarecía las actualizaciones del conjunto.
Módulos CSS, sin runtime
La salida fue CSS Modules, un formato que deja escribir CSS nativo sin renunciar a parte de la colocación y el encapsulado que daba CSS-in-JS. Cada componente escribe sus estilos en un archivo CSS junto a su código JavaScript, con los nombres de clase locales por defecto, lo que corta colisiones típicas de los selectores globales. Y no hay runtime en cliente ni en servidor: las hojas se agrupan y viajan dentro del HTML de la página.
El precio era alto: el cambio afectaba a todos los componentes de Primer y a todos los que GitHub hubiera escrito con la misma técnica, sin poder romper nada por el camino. El equipo optó por migrar componente a componente. Añadía el archivo nuevo con los estilos traducidos a módulos, metía el componente detrás de un feature flag que alternaba entre versión vieja y nueva, comparaba capturas con los tests de regresión visual que ya existían y desplegaba por fases: su equipo, luego la plantilla, luego todo el mundo. El CSS-in-JS siguió funcionando en paralelo para lo que todavía lo usaba, y cada fase daba señal temprana de si algo se torcía.
El escollo de la prop sx
El obstáculo serio fue sx, la prop con la que se personalizaban los componentes en GitHub. Recibía un objeto inline para ajustar cualquier cosa y resumía lo mejor y lo peor de CSS-in-JS: buen soporte de TypeScript integrado con los tokens de diseño y todo en un mismo sitio, frente a un coste de runtime alto y un escalado malo a medida que crecían los componentes por página. Con sx como estándar de facto durante años, había miles de usos por convertir antes de poder retirar styled-components del producto.
La pieza que lo hizo manejable fue un paquete intermedio, @primer/styled-react, con componentes envoltorio que aceptan sx sobre los ya migrados. Así el código que seguía usando la prop no se quedaba atrás mientras avanzaba la conversión.
Queda trabajo. Retirar CSS-in-JS de todo GitHub depende de cuántos sx se vayan eliminando, y el propio equipo reconoce que la librería del sistema de diseño está limpia mucho antes que el resto del código. Para quien mantiene una base grande con estilos en runtime, el orden de la jugada es lo interesante: primero el sistema de diseño, después el producto, y feature flags en medio para no apostar la web a un big bang.
