Rethinking React Styling for the RSC Era

Hola a todos, espero que estén teniendo un tiempo increíble hasta ahora en React Advanced. Bienvenidos a Repensar el Estilo de React para la Era RSC. Soy Bree, defensora senior de desarrolladores en Atlassian, y estoy muy emocionada de estar aquí con todos ustedes hoy. Siempre tengo mucha curiosidad, así que háganme saber en el chat a continuación cuál es su método favorito para estilizar aplicaciones de React, porque no sé si todos han estado en los chats grupales últimamente, pero estilizar componentes de React se ha vuelto un poco picante. React 19 ha salido, Tailwind se ha reinventado, el CSS nativo está en su era de esplendor, e incluso el mantenedor principal de styled components dijo que tal vez es hora de seguir adelante.

Así que hoy vamos a desentrañar lo que realmente está sucediendo con el estilo en 2025, qué se mantiene en pie, qué se está desmoronando y cómo elegir un enfoque de estilo que no te haga llorar en tus revisiones de código como solía hacer yo. Parece que cada par de años tenemos que tener la charla, ¿verdad? Nos sentimos muy cómodos con las herramientas, elegimos nuestros métodos favoritos, tenemos nuestros flujos de trabajo que se sienten realmente bien y realmente suaves, y luego algo viene y da vuelta a la mesa entera. Ahora, en los últimos años, ese algo han sido los componentes del servidor de React, pero no realmente se siente como si solo hubiera dado vuelta a la mesa. Se siente como si hubiera redefinido cómo realmente deberíamos estar estilizando nuestras aplicaciones.

Así que durante los próximos 20 minutos, vamos a desenredar este lío y hablar sobre cómo tomar decisiones inteligentes y a prueba de futuro para estilizar tus proyectos. Porque a finales de 2025, hay una nueva prueba de fuego para cada biblioteca de estilo, y honestamente, es bastante simple. La pregunta es, ¿puedes generar CSS estático sin tiempo de ejecución en tiempo de compilación? Si tu solución de estilo necesita un tiempo de ejecución de JavaScript en el cliente para inyectar archivos, está fundamentalmente en desacuerdo con la característica de servidor primero que React está construyendo. Así que este único requisito ha causado honestamente un gran cambio en nuestro ecosistema. Ha forzado algunas migraciones, ha elevado una nueva clase de contendientes. Así que hoy, vamos a hablar sobre las tres filosofías dominantes, y vamos a ponerlas a prueba.

Vamos a hablar sobre el alcance de CSS con CSS modules, frameworks de utilidad primero con Tailwind, y también el nuevo CSS y JS en tiempo de compilación. Vamos a sumergirnos.

Primero, tenemos que reconocer el elefante en la habitación, el paradigma que definió una era del desarrollo de React, runtime, CSS y JS. A principios de este año, el mantenedor de styled components anunció oficialmente que estaba en modo de mantenimiento y que ya no lo recomendaban para nuevos proyectos. Esto realmente no fue una sorpresa para nadie, pero sí se sintió como un gran evento.

Así que fue un reconocimiento público de la realidad técnica de que runtime, CSS y JS, y los componentes del servidor honestamente simplemente no se mezclan. Entonces, ¿por qué la incompatibilidad? Todo se reduce a un simple hecho. Los componentes del servidor no pueden acceder al contexto de React. Así que si pensamos por un segundo realmente rápido sobre cómo funcionan frameworks como styled components o cómo emotion funciona, básicamente envuelves tu aplicación dentro de un theme provider, que utiliza el contexto para pasar tu tema por el árbol.

Luego, en tu componente, la biblioteca utiliza ese contexto de tema más un runtime de JavaScript para generar dinámicamente e inyectar una etiqueta de estilo en el encabezado del documento. Pero los componentes del servidor se renderizan exclusivamente en el servidor. Su código nunca se envía al navegador. No tienen acceso a conceptos del lado del cliente como el contexto.

No pueden ejecutar el JavaScript necesario para inyectar los estilos. Para hacer que los componentes de estilo funcionen, tienes que envolverlo en un use client boundary, lo cual saca toda esa parte del árbol del modelo RSC, lo que de alguna manera derrota el propósito. Así que la reacción de la comunidad a esta noticia ha sido un poco de tristeza, mucha frustración, especialmente para aquellos con grandes bases de código heredado, y un sentido colectivo de alivio de muchas personas también.

Así que esto ha iniciado lo que siento que es una especie de gran migración. Algunos equipos están tratando de averiguar cuál será su estrategia de salida. Y a medida que abandonan el mundo del styling en tiempo de ejecución, se están moviendo en dos direcciones muy diferentes pero igualmente válidas. No es realmente solo una migración técnica en este punto. También es una filosófica sobre cómo realmente queremos abordar la construcción de software en 2025.

Así que una de las opciones es regresar al CSS nativo, porque en 2025, CSS como independiente es increíblemente poderoso. Así que en años anteriores, hemos confiado en cosas como preprocesadores, como SAS para características que ahora son estándar en casi todos los navegadores principales. Tenemos cosas como el anidamiento de CSS, que está totalmente soportado, permitiéndonos escribir estilos más limpios y organizados sin un preprocesador. Tenemos nuevas pseudo clases como el has, que fue una muy esperada, y el is, que nos da un control sin precedentes para simplificar estilos complejos.

Y la plataforma está evolucionando más rápido que nunca, con nuevas capacidades como animaciones impulsadas por desplazamiento y consultas de contenedor, y básicamente cosas que nos dan más acceso a controles de styling nativos. Así que aquí es donde CSS modules tiende a brillar. En su núcleo, es una herramienta de tiempo de compilación realmente simple que resuelve el mayor problema con CSS a escala, que es el espacio de nombres global. Toma un archivo CSS regular y hace que cada nombre de clase tenga un alcance local por defecto, previniendo colisiones de estilos. Así que no hay nueva sintaxis que aprender. Si ya conoces CSS, entonces conoces CSS modules. Y para muchos de nosotros, esto se siente como una apuesta segura y a prueba de futuro que evita dependencias de proveedores.

Ahora, por otro lado, tenemos personas que buscan la productividad programática. Y estas son personas que están completamente comprometidas con herramientas como Tailwind CSS. Ahora, a un alto nivel, Tailwind es un framework utility-first. Así que en lugar de escribir CSS personalizado, básicamente construyes tus diseños componiendo clases de utilidad de un solo uso directamente dentro de tu markup. Estas van a ser clases como Flex para tu fondo y para tu padding también. La gente tiende a gravitar hacia él por una variedad de razones diferentes, pero solo vamos a hablar de un par de ellas súper rápido. La primera es su velocidad. Puedes prototipar y construir interfaces de usuario realmente complejas increíblemente rápido sin tener que salir de tu JSX o inventar tus propios nuevos nombres de clase. La segunda cosa es la consistencia. Refuerza el sistema de diseño a través de sus escalas predefinidas para color, para espaciado, para tipografía, lo cual es realmente importante para equipos más grandes y la colaboración también. Y lo más importante para la era RSC, tiene un costo cero en tiempo de ejecución. Así que esta es una herramienta de compilación que va a escanear tus archivos y generar un archivo CSS altamente optimizado que solo contiene los estilos que realmente vas a usar.

Así que tenemos estas dos filosofías opuestas. Tenemos la simplicidad del CSS nativo frente a la productividad de un framework utility-first, además de una nueva ola de herramientas que intentan darnos ambos. Entonces, ¿cómo se sostienen realmente? Bien, ahora que hemos sentado las bases y visto cómo el panorama del styling está comenzando a cambiar, pongamos realmente estas herramientas en práctica y veamos cómo se sostienen. Nuestro caso de prueba es una tarjeta de producto en vivo. Es un componente híbrido realista. La imagen del contenedor y el título se renderizan en el servidor como componentes del servidor, pero el botón de agregar al carrito necesita estado. Así que es un componente interactivo del cliente. Este límite servidor-cliente es donde los viejos hábitos de styling tienden a descomponerse. Vamos a evaluar nuestros tres enfoques principales a través de cuatro demandas críticas de una arquitectura moderna server-first. Comencemos con CSS y JS y veamos cómo podría fallar algunas de las pruebas que actualmente tenemos. La primera es la renderización del lado del servidor y la hidratación.

La pregunta guía va a ser, ¿cómo genera esto el HTML inicial y qué sucede en el cliente? Con bibliotecas de tiempo de ejecución, el servidor tiene que hacer mucho trabajo para extraer los estilos e inyectarlos. Pero el verdadero problema es que todo su modelo de tematización y estilo está construido sobre el contexto de React. Y como establecimos anteriormente, los componentes de servidor de React no tienen una forma de acceder al contexto. Así que la única manera de hacer que los componentes estilizados funcionen es envolverlos nuevamente en esa directiva de uso del cliente , lo que te excluye de todo el modelo RSC. Así que nuestra primera prueba va a fallar.

¿Qué pasa con la UI en streaming? Entonces, si esta tarjeta se transmite después de una carga inicial, ¿obtenemos el destello de contenido sin estilo? La respuesta es sí, y es una de las mayores debilidades de CSS y JS. Así que el HTML transmitido para la tarjeta puede llegar y renderizarse en el navegador antes de que el JavaScript que contiene la lógica de estilo haya sido descargado, analizado y ejecutado. Esto significa que podría haber un retraso notable cuando el componente está en pantalla y está completamente sin estilo, y puede crear una experiencia de usuario discordante.

Hablemos de la tematización escalable. La pregunta es, ¿cómo aplicamos un tema de venta, por ejemplo, a nuestra tarjeta, asegurando que tanto las partes del servidor como del cliente estén estilizadas de manera consistente? Así que el botón renderizado por el cliente puede acceder a los estilos, pero la parte del servidor no puede. Esto va a hacer realmente difícil mantener la consistencia del tema a través de los límites del servidor y del cliente. Y hablemos también del rendimiento en tiempo de ejecución. ¿Cuál es el costo de ejecutar esto realmente en el dispositivo del usuario? Así que el costo puede ser bastante significativo. Tienes que enviar un tiempo de ejecución de JavaScript al cliente, lo que aumenta el tamaño del paquete. Esto significa que probablemente habrá un retraso en el tiempo para interactuar. Tenemos pruebas concretas de este costo porque en realidad hay un fork reciente de la biblioteca de style components llamada style components last resort, que implementó optimizaciones de React 18 que la biblioteca original nunca hizo. Y en realidad resultó en un renderizado inicial un 40% más rápido para equipos como linear. Esto fue una sobrecarga realmente masiva. Y es realmente interesante ver que pudieron optimizarlo.

Ahora hablemos de Tailwind CSS. Para UI en streaming, esto es en realidad una gran fortaleza. El archivo CSS estático que contiene todas las utilidades necesarias se carga al principio con la estructura inicial de la página. Así que cuando la página se transmite y nuestra tarjeta llega, el navegador ya tiene acceso a las reglas CSS para cada nombre de clase en el marcado. Así que el componente se renderiza instantáneamente y correctamente, completamente estilizado.

En términos de tematización escalable, el estándar moderno para tematización son las propiedades CSS nativas y Tailwind versión cuatro tiene la nueva directiva de tema que compila tus tokens de diseño directamente en variables CSS. Debido a que esta es una característica nativa del navegador, se aplican normalmente y son accesibles para todo el HTML, ya sea que se rendericen en el servidor o en el cliente. Así que la tematización a través del límite servidor-cliente se vuelve mucho más fluida.

Y en términos de rendimiento en tiempo de ejecución, el costo del lado del cliente es básicamente cero. Todo el trabajo pesado, el análisis del código, la generación del CSS y su optimización ocurre en tiempo de compilación. Así que el navegador solo recibe un archivo CSS estático y el HTML con los nombres de clase, que es la forma más eficiente de renderizar estilos. Así que arquitectónicamente, esta puede ser una muy buena elección, pero tampoco quiero ignorar muchas de las críticas vocales que recibe.

Creo que una de las críticas más famosas es el comentario de la sopa de divs, que tu JSX puede volverse realmente verboso o empezar a sentirse un poco desordenado y casi como una regresión a los estilos en línea. Así que también más allá de eso, la sopa de nombres de clase, hay una resistencia filosófica también. Y hay un fuerte sentimiento de que usar Tailwind anima a los desarrolladores a desaprender los fundamentos de la plataforma CSS por una abstracción propietaria. Y esa abstracción lleva a preocupaciones sobre cosas como el bloqueo del proveedor. Así que cuando una herramienta está tan profundamente incrustada en tu marcado, migrar lejos de ella por cualquier razón si tienes que hacerlo en el futuro va a ser una tarea enorme.

Entonces, ¿cómo hacen miles de equipos para usar Tailwind a escala para reconciliar esto? Resuelven esto con el punto de dolor más inmediato, el marcado desordenado con una abstracción más disciplinada. Así que el patrón moderno y escalable no es usar la directiva apply, sino que es abrazar la arquitectura basada en componentes y usar bibliotecas dedicadas, cosas como Tailwind variants o class names que te proporcionan seguridad de tipos, una API estructurada para definir tus variantes de componentes que se mapean a combinaciones específicas de clases de utilidad. Esto funciona porque obtienes el poder de las utilidades para la implementación, pero el código de aplicación también se vuelve más limpio y declarativo.

Ahora, aunque esto no resuelve el debate filosófico sobre si obliga a los desarrolladores a desaprender buenos hábitos de CSS o tal vez no aprenderlos en absoluto, si los desarrolladores están comenzando con Tailwind, sí proporciona un patrón robusto probado en producción para gestionar su complejidad. Ahora hablemos de CSS nativo y módulos CSS. Algo que he estado disfrutando mucho recientemente, y siento que podría ser un sucesor moderno, es Panda CSS. Así que esto es, creo, la promesa de lo mejor de ambos mundos. Es la experiencia del desarrollador de CSS y JS con el rendimiento de CSS estático. Así que hagamos la prueba de la que hemos hablado un poco antes. En términos de SSR e hidratación, Panda también es una herramienta de tiempo de compilación y utiliza análisis estático para analizar tu JavaScript o tu TypeScript y luego encontrar definiciones de estilo en las llamadas de estilo o los props de JSX y extraerlos en un archivo CSS estático.

Así que el código inicial del componente se transforma para referenciar los nombres de clase generados. Este es básicamente el mismo principio que Tailwind, solo que con una entrada de autoría diferente. Así que siento que esto pasaría nuestra prueba. Para la transmisión de UI, al igual que Tailwind, genera un archivo CSS estático que se carga al principio para que los componentes transmitidos se rendericen instantáneamente y estén completamente estilizados.

En términos de tematización escalable, el sistema de tokens seguros de tipo de Panda se define en un Panda.config.ts, un poco similar a una configuración de Tailwind, si estás familiarizado con eso. Y también genera propiedades CSS personalizadas. Así que esto significa que tiene el mismo beneficio crítico de que la tematización funciona sin problemas a través de los límites del servidor y el cliente porque es una característica nativa de la plataforma. Y en términos de rendimiento en tiempo de ejecución, nuevamente, esto no tiene costo para nosotros. Así que Panda pasa todas las pruebas por las mismas razones arquitectónicas que Tailwind. Y demuestra que la elección entre soluciones modernas no siempre se trata exactamente de compensaciones de rendimiento, sino que también tiene mucho que ver con la experiencia de autoría y lo que tú y tu equipo prefieren.

También tiene una API de Variants muy poderosa, que llaman recetas, que están integradas directamente. Así que esto te da el mismo estilo estructurado que podrías obtener de algo como Tailwind Variants, pero como una característica principal y de primera mano de Panda como biblioteca en sí misma. Esto lo convierte en una solución atractiva o tal vez todo en uno para equipos que quieren escribir sus estilos en TypeScript junto con su lógica de componentes. Entonces, ¿dónde nos deja eso? Nuestra prueba de estrés dejó claro que la era del estilo en tiempo de ejecución para aplicaciones server-first ha terminado.

Pero eso sería una salida fácil dejarlo ahí. La elección ya no se trata necesariamente de compensaciones de rendimiento, y realmente es más sobre las necesidades específicas de tu proyecto y cuál es la filosofía de tu equipo. Así que pongámoslo todo junto. Este es uno de los marcos de decisión para 2025. Primero y ante todo, veamos esa fila superior, el rendimiento de RSC. La conclusión clave es que el rendimiento no es necesariamente nuestra mayor preocupación ahora. Y el debate es más sobre la experiencia del desarrollador y el ajuste del proyecto. Así que hablemos de lo que a la gente realmente le gusta y no le gusta de cada uno.

Con Tailwind, a la gente le encanta su velocidad y productividad incomparables. Puedes construir tus UIs realmente rápido, y refuerza un sistema de diseño consistente a través de tu equipo. Así que el ecosistema también es realmente, realmente grande. Pero en el lado negativo, a la gente le disgusta la sopa de nombres de clase y el desorden que puede dar con tu JSX. Y hay preocupaciones filosóficas reales sobre desaprender CSS y el bloqueo a largo plazo del proveedor que puede crear. Y luego tenemos Panda CSS, que representa nuestro campo de tiempo de compilación. Lo que a la gente le encanta es que ofrece la experiencia de CSS y JS con estilos ubicados en el código variantes poderosas, pero sin un costo de tiempo de ejecución.

La seguridad de tipos también es una gran ventaja para el mantenimiento. Pero lo que más disgusta es que es otra herramienta. Agrega complejidad de configuración y una curva de aprendizaje a tu proyecto. Y el ecosistema todavía está creciendo rápidamente, pero también es aún más nuevo. Y finalmente, los módulos CSS. A la gente le encanta su simplicidad. Es solo CSS. Y eso es todo. Obtienes una separación limpia de preocupaciones, y no hay absolutamente ningún bloqueo de proveedor allí, lo que se siente muy seguro en un ecosistema de rápido movimiento. Las desventajas, obviamente, pueden sentirse realmente torpes y muy verbosos para el estilo dinámico. La tematización carece de la robusta seguridad de tipos de las otras soluciones, y definitivamente es más lento en términos de creación rápida de prototipos.

La tematización carece de la robusta seguridad de tipos de las otras soluciones, y definitivamente es más lenta en términos de creación rápida de prototipos. Así que eso nos lleva a la pregunta final y más práctica, ¿cuál es el proyecto ideal, realmente, para cada uno? Para decirlo rápidamente, elige Tailwind si estás buscando un MVP o cualquier proyecto donde tu velocidad sea una prioridad absoluta. Puede que quieras optar por algo como Pandas CSS si estás construyendo un sistema de diseño con bibliotecas de componentes complejas o tu equipo está culturalmente comprometido con el estilo de autoría de CSS y JS, o elige módulos CSS para proyectos donde la estabilidad a largo plazo y minimizar las dependencias son mucho más importantes que tu desarrollo inicial.

Nos hemos movido decisivamente a un mundo donde la lógica de estilo ahora ocurre o se resuelve en tiempo de compilación. Así que la elección para un nuevo proyecto en 2025 se reduce más a una cuestión filosófica. ¿Prefieres los flujos de trabajo centrados en HTML primero de utilidad de cosas como Tailwind? ¿Prefieres las herramientas de estilo de JavaScript con seguridad de tipos como Pandas CSS? ¿O realmente solo quieres la simplicidad fundamental de los módulos CSS? Al final del día, el estilo en React no es solo una decisión técnica, es una decisión de producto, es una decisión de equipo, y lo más importante, es una decisión tuya.

Así que lo que elijas, asegúrate de que sirva a tu equipo, asegúrate de que sirva a tus aplicaciones, y hacia dónde se dirige realmente el front-end. Así es como construimos aplicaciones que son agradables de mantener, escalan bien con nuestros equipos, y que aún se ven realmente bien. Así que si quieres saber más sobre el estado actual de CSS y lo que la gente realmente está usando hoy, te recomiendo encarecidamente que consultes la encuesta State of CSS 2025. He estado revisando los últimos días y comparándolo con los resultados del año pasado, y es tan interesante cuánto puede cambiar en poco tiempo. Y con eso, quiero decir muchas gracias por estar aquí. Gracias al equipo de React Advanced por tenerme. Estaré en el chat y en el Discord, así que me encantaría pasar el rato y hablar un poco más sobre estas diferentes soluciones de estilo y entender lo que todos ustedes están usando actualmente. Dejaré un código QR donde podemos conectarnos, y también un poco más de información sobre algunas de las cosas en el mundo del estilo que he visto recientemente que también pueden ayudarte mucho. Muchas gracias.