Dejando atrás el CSS en JS en tiempo de ejecución: componentes del servidor y estilos en tiempo de compilación
Por qué el CSS-in-JS en tiempo de ejecución choca con los Componentes del Servidor de React y los objetivos de rendimiento, cómo se comparan Tailwind, CSS Modules y las bibliotecas sin tiempo de ejecución, y cómo migrar de forma segura.
Fuentes: Why CSS-in-JS Is Dying in 2026: Performance, Server Components, and What to Use Instead
Durante varios años, las bibliotecas CSS-in-JS en tiempo de ejecución como styled-components y Emotion fueron la forma principal de dar estilo a los componentes React: estilos limitados a un componente, valores determinados por propiedades y sin colisiones de nombres de clases globales. Desde entonces, el ecosistema ha pasado a utilizar estilos generados en tiempo de compilación, impulsado principalmente por consideraciones de rendimiento y por los React Server Components. Este artículo explica qué cambió, compara las principales alternativas y ofrece una regla práctica para decidir cuándo migrar una base de código existente y cuándo dejarla tal como está.
Muchos equipos, grandes y pequeños, ya han dejado de utilizar el estilo en tiempo de ejecución para nuevos proyectos, y las razones son importantes antes de elegir un enfoque.
El costo de generar estilos en el navegador
Las bibliotecas CSS-in-JS en tiempo de ejecución generan CSS mientras tu aplicación está en funcionamiento. A medida que se renderizan los componentes, la biblioteca convierte las definiciones de estilo (incluidos todos los valores que dependen de las propiedades) en reglas CSS, genera nombres de clases e inyecta etiquetas <style> en el documento. Esa tarea se ejecuta en el hilo principal, en el dispositivo del usuario. Los estudios de rendimiento publicados que lo comparan con CSS estático han indicado retrasos en el renderizado del 20 al 50 por ciento; el impacto real depende en gran medida de la aplicación, por lo que considere tales cifras como una señal para medir sus propias páginas en lugar de como un valor universal.
El problema subyacente es de tipo arquitectónico y no un error en alguna biblioteca en particular: el cálculo de estilos se realiza en el navegador en lugar de en el momento de la compilación. Eso significa que el propio motor de estilos se incluye en tu paquete de JavaScript, lo cual hace que el navegador tenga que analizar y ejecutar más código antes de que la página se vuelva interactiva, además de que la inserción de estilos compite con el proceso de renderizado por los recursos del sistema.
Por qué los Componentes Servidor expusieron este punto débil
Los React Server Components (RSC) se renderizan en el servidor y envían su salida al navegador sin incluir el código del componente como JavaScript cliente. El CSS-in-JS en tiempo de ejecución depende de un entorno de JavaScript que rastrea e inyecta estilos durante el renderizado, y se basa en el contexto de React, algo que los Componentes Servidor no soportan. Esto lo pone en conflicto con el modelo centrado en el servidor utilizado por frameworks como Next.js App Router.
En la práctica, utilizar styled-components o Emotion con Components de servidor implica marcar las partes estilizadas del árbol como Components de cliente con la directiva 'use client', generalmente junto con una configuración adicional para recopilar los estilos durante el renderizado en servidor. Cuando se utilizan primitivas estilizadas en todas partes, una gran parte del árbol de componentes termina en el cliente. Eso anula gran parte de lo que ofrecen los Components de servidor, es decir, menos JavaScript enviado al navegador y menos trabajo allí, únicamente para mantener funcional la biblioteca de estilos. Para muchos equipos, ese compromiso no ha valido la pena.
Las alternativas en tiempo de compilación
El CSS-in-JS en tiempo de ejecución alcanzó su punto máximo aproximadamente entre 2018 y 2023. Hoy en día existen varias opciones maduras que evitan el costo en tiempo de ejecución, cada una adaptada a las preferencias distintas de los equipos.
Tailwind CSS como opción predeterminada común
Tailwind CSS se ha convertido en el punto de partida habitual para nuevos proyectos React y Next.js. Se componen las clases utilitarias directamente en el marcado, y la fase de compilación emite únicamente el CSS de las clases que realmente se utilizan. No existe un motor de estilizado en tiempo de ejecución, lo que mantiene la hoja de estilo pequeña; además, al tratarse de CSS puro, funciona en los Componentes Servidor sin necesidad de ningún tratamiento especial.
Módulos CSS para equipos que prefieren CSS puro
Si prefiere escribir CSS tradicional en lugar de clases utilitarias, los Módulos CSS le ofrecen nombres de clase con ámbito local sin coste en tiempo de ejecución. La mayoría de los bundlers y cadenas de herramientas de framework los soportan por defecto, por lo que su adopción generalmente no requiere ninguna configuración.
CSS-in-JS sin coste en tiempo de ejecución para el modelo de creación familiar
Bibliotecas como Panda CSS y Vanilla Extract permiten seguir escribiendo estilos en JavaScript o TypeScript, de forma similar a como se hacía con styled-components, pero extraen todo hacia CSS estático durante el proceso de compilación. Se mantiene la experiencia de creación y la seguridad tipológica, sin sobrecarga en tiempo de ejecución, además de una compatibilidad total con los Server Components. El principal ajuste es que los estilos deben ser analizables de forma estática, por lo que los valores que cambian en tiempo de ejecución suelen expresarse a través de variantes o propiedades personalizadas de CSS en lugar de props arbitrarios. Los patrones para convertir valores de JavaScript en variables de CSS se tratan en nuestra guía sobre propiedades personalizadas de CSS en tiempo de ejecución.
Cómo decidir cuándo migrar
Proyectos nuevos
Para un proyecto nuevo, hoy en día hay pocos motivos para elegir CSS-in-JS en tiempo de ejecución. Una opción razonable por defecto:
- Tailwind CSS para la mayoría de los proyectos.
- CSS Modules si el equipo prefiere hojas de estilo convencionales.
- Una biblioteca CSS-in-JS sin tiempo de ejecución si deseas seguir escribiendo estilos en TypeScript sin tener que pagar por un entorno de ejecución.
Proyectos existentes
En el caso de una aplicación ya construida con styled-components o Emotion, no hay necesidad de apresurarse. Ambas bibliotecas siguen funcionando bien en aplicaciones renderizadas en el cliente. La migración merece ser planificada cuando se pretende adoptar Server Components o cuando el análisis muestra que los estilos representan una parte significativa del costo de renderizado.
Cuando realice la migración, hágala de forma incremental, componente por componente, pasando a Tailwind o CSS Modules. Los componentes simples y las primitivas compartidas como los botones son buenos objetivos iniciales. Ambos sistemas pueden coexistir durante la transición, pero debe prestar atención a la especificidad y al orden de los estilos mientras los estilos antiguos y nuevos coexistan.
Conclusión
- El CSS-in-JS en tiempo de ejecución resolvió problemas reales, pero calcula los estilos en el cliente, lo que aumenta el tamaño del paquete y consume tiempo en el hilo principal.
- Los componentes servidores hacen que ese costo sea más evidente, ya que las bibliotecas dependen del JavaScript del cliente y envían los árboles estilizados de vuelta al cliente.
- Tailwind CSS, CSS Modules y bibliotecas sin tiempo de ejecución como Panda CSS y Vanilla Extract generan CSS estático en el momento de la compilación y funcionan perfectamente con los componentes servidores.
Lecturas relacionadas
- Comprendiendo los Componentes de Cache y el Precarga Parcial en Next.js 16.3 — Explica cómo la función de Navegaciones Instantáneas de Next.js 16.3 utiliza cáscaras de ruta compartidas y decisiones explícitas de transmisión para que las aplicaciones renderizadas en el servidor parezcan instantáneas.
- React Server Components: La Arquitectura Detrás del Renderizado con Cero Bundle — Entienda las razones detrás de los Componentes de Servidor de React, desde el tamaño del bundle y los problemas relacionados con su procesamiento hasta el límite entre servidor y cliente y las cargas de los RSC.