Estilizado y SASSy: Eligiendo la Solución de Estilo de React Correcta

Hola a todos. Mi nombre es Bri, y soy una defensora desarrolladora senior en Atlassian. Mi cara es realmente grande allá arriba. Pero está bien. Realmente me encanta hacer las cosas un poco lindas, y me gusta hablar en Internet. Bienvenidos a Styled and Sassy, eligiendo la solución de estilo de React adecuada. Esta es una de mis charlas favoritas porque la gente siempre tiene opiniones realmente, realmente, realmente fuertes cuando se trata de estilos. Así que levanten la mano, ¿quién tiene un método favorito para estilizar aplicaciones React o aplicaciones web? ¿Es ese CSS nativo? Dejen la mano levantada si lo es. Menos de lo que pensaba. Bien. ¿Es Tailwind? Bien. ¿Son módulos CSS? ¿Es un sistema de diseño de biblioteca de marco diferente? Bien. ¿Alguien realmente no tiene uno favorito y simplemente usa lo que su trabajo les dice que tienen que usar? Lo imaginé. Lo imaginé.

Una cosa que no está ahí arriba es porque me gusta hablar en Internet, también me gusta ver un poco de drama, y siempre hay algo en el mundo del estilo. Así que no sé si han visto los chats grupales últimamente, pero estilizar componentes de React se ha vuelto un poco más desordenado de lo que solía ser. Con React 19 lanzándose, Tailwind reinventándose con la cuarta versión, y CSS nativo estando en su era de auge, incluso el mantenedor de styled components, que es una biblioteca muy popular de CSS en JS, diciendo que es hora de seguir adelante, las cosas se han sacudido un poco. Así que hoy lo que vamos a hacer es desentrañar lo que está sucediendo con el mundo del estilo en React aquí en 2025. Vamos a ver qué se mantiene, qué se está desmoronando, y cómo elegir un enfoque de estilo que no te haga llorar en tus revisiones de código, como a mí.

Así que antes de comenzar, solo quería echar un vistazo a lo que realmente está sucediendo hoy, y no solo lo que los desarrolladores están usando, lo que realmente están diciendo. Así que vamos a echar un vistazo rápido a algunos de los resultados de la última encuesta del estado de CSS 2025. Si nunca la has visto o no has hecho una encuesta tú mismo, te recomiendo encarecidamente que lo hagas. Toma un café, tal vez un poco de palomitas, porque hay información realmente excelente allí. Así que lo primero es que Tailwind está muy cómodamente en la sección de frameworks, con el 51% de los votantes en esa categoría diciendo que lo han usado antes. Ahora, lo que hay que recordar aquí es que esto no es un voto de sentimiento. Esto no significa que les gusta, que no les gusta. Esto es solo decir que lo han usado antes. A continuación, tenemos un 29% de los encuestados diciendo que han usado una biblioteca de CSS en JS antes. Y de ese 29%, el 28% de los votantes todavía quieren usar módulos CSS, lo que realmente demuestra que CSS nativo y vanilla sigue siendo una preferencia. Y luego el segundo subcampeón va a ser styled components, que es otra biblioteca de CSS en JS.

subcampeón va a ser styled components, que es otra biblioteca de CSS en JS. Y luego solo por diversión, quería echar un vistazo a Sass también. Lo divertido es que este sigue siendo definitivamente el líder de la categoría de pre y post procesadores, pero está en un 61%, lo cual es en realidad un 6% menos que el año pasado.

Así que podemos ver que las cosas están comenzando a cambiar en el ecosistema. Así que a lo largo de esta encuesta, estamos viendo que hay bastantes filosofías de estilo diferentes. Tenemos utility first, tenemos scope CSS, y tenemos CSS en JS. Así que estos son los resultados por los números, pero ¿qué están diciendo realmente los desarrolladores?

Echemos un vistazo a los comentarios, porque esos son la mejor parte. Así que tenemos algunas personas que prefieren la simplicidad del CSS nativo como herramienta, aunque tal vez algunas personas fueron un poco picantes con sus opiniones. Pero con lo mucho que ha mejorado el CSS nativo, especialmente en los últimos años, en algunos casos, tiene sentido recurrir a lo que conocemos y amamos. Ahora, también tenemos personas que están usando herramientas como Tailwind, tal vez lo usan para cosas como prototipos o para sus proyectos de hobby porque la velocidad se mueve realmente, realmente rápido. Por otro lado, también podemos ver, y estoy bastante seguro de que incluso personas en esta sala tal vez tienen un sentimiento un poco diferente cuando se trata de Tailwind. Y luego también vimos que la encuesta de este año tuvo un sentimiento bastante negativo hacia CSS en JS, no una biblioteca específica, sino como un patrón en su conjunto. Gran parte de los comentarios fueron preocupaciones con SSR, simplemente no gustar el patrón y problemas de rendimiento.

Así que antes de echar un vistazo al futuro, quiero echar un vistazo rápido a esos tres paradigmas que básicamente estaban dominando la parte superior de las listas allí. El primero va a ser CSS modules. Esa es realmente nuestra apuesta segura, ¿verdad? Porque es CSS, CSS normal, nada loco. Simplemente está delimitado. Da solución al problema del espacio de nombres global, como que ya no tenemos que preocuparnos por eso. Y es muy predeciblemente seguro para SSR o renderizado del lado del servidor.

Así que esa base comienza a cambiar en su mayor parte cuando empezamos a pensar en cosas como la escala, compartir tokens de diseño a través de grandes equipos o tener que usar un preprocesador manual. Así que a menudo terminas con aislamiento de alcance pero fragmentación de diseño porque todos van a tener una forma diferente de hacerlo. El siguiente creo que o lo amamos o lo odiamos, y ese es Tailwind. Me gusta usarlo por razones de velocidad y especialmente cuando estoy usando como IA. La IA es mucho mejor generando código con Tailwind en comparación con CSS nativo.

Pero este va a ser nuestro marco de trabajo utility-first donde tu HTML básicamente describe tu UI. Básicamente te permite imponer un sistema de diseño a nivel de compilador. Puedes moverte rápido porque no tienes que nombrar específicamente todo. Y con Tailwind antes, el archivo de configuración que estaba con JavaScript ahora se ha ido. No se ha ido. Aún puedes usarlo. Pero también puedes usar CSS nativamente lo cual lo hace mucho más ligero y mucho más rápido. Las cosas comienzan a cambiar cuando pensamos en el acoplamiento aquí. Así que tu marcado se convierte en tu hoja de estilo y esto puede ser realmente, realmente desordenado muy rápidamente, lo cual es una de las mayores críticas del marco. Si no tienes buenos patrones o buena higiene de estilo, esto puede volverse realmente desordenado muy rápido.

Por ejemplo, si tienes que cambiar el estado de un botón en cierta lógica. Y por último tenemos el paradigma dinámico. Ese va a ser CSS y JS. Ahora la filosofía aquí es realmente la co-ubicación. Tu lógica y tus estilos están en el mismo lugar. Esto nos da una buena experiencia de desarrollador al poder pasar props a nuestros estilos y realmente se siente inherentemente React. Ahora el problema comienza a surgir cuando pensamos en cómo herramientas como esta funcionan con el marco de trabajo React real. Así que la biblioteca tiene que inyectar los estilos en el head del documento cuando el usuario está realmente usándolo durante el tiempo de ejecución, no en el tiempo de construcción.

Y en React 19 y con componentes del servidor esto puede causar algo llamado el flash de contenido sin estilo donde los usuarios pueden ver una página sin estilo muy rápidamente antes de ver tus estilos reales que se han renderizado. Ahora esto solía considerarse como un compromiso, pero con componentes del servidor esto se ha convertido en un obstáculo total para muchos equipos. Entonces, ¿qué sucede cuando estos métodos de estilo se encuentran con React 19 y el mundo moderno del front end y hacia dónde se dirige? De repente no parece que nuestros estilos solo estén evolucionando. Parece que han sido reinventados y como si estuviéramos pasando por este resurgimiento una vez más.

Así que React 19 introdujo muchas características nuevas y solo quiero echar un vistazo a un par que están redefiniendo silenciosamente cómo pensamos sobre el estilo. Así que una de las primeras, y realmente no he visto a mucha gente hablar sobre esta, pero creo que es realmente genial, es el resource hoisting. Así que durante muchos años, usamos bibliotecas de CSS y JS para co-ubicar nuestros estilos con nuestros componentes. React 19 nos da la capacidad de hacer esto de forma nativa donde puedes renderizar o enlazar una hoja de estilo y cuando React básicamente va a suspender en el renderizado mientras carga y luego elevar eso al head de todo el documento en sí. Así que eso significa que puedes tener CSS a nivel de componente que es estándar y almacenable en caché con archivos CSS regulares sin necesidad de una biblioteca.

Otro es form actions. Si alguna vez has tenido que estilizar un botón de envío para que esté tal vez deshabilitado o mostrar un spinner de carga, esto cambia cómo tenemos la capacidad de hacerlo. Así que anteriormente eso significaba estilizar por estado y luego alternar manualmente los booleanos y llevar un seguimiento de todos los diferentes tipos de piezas de estado dentro de nuestros componentes de React, pero ahora podemos usar use action state. Aquí es donde podemos pasar una función async al formulario y React nos da el estado is pending automáticamente. Así que esto cambia nuestra arquitectura de CSS y realmente no tenemos que estilizar basándonos en predicciones arbitrarias y sabemos exactamente lo que va a ser y permite que React impulse esa acción por nosotros.

Luego también tenemos primitivas asíncronas. Así que React 19 nos permite usar use optimistic para retroalimentación instantánea. Esto es realmente útil y destaca ese cambio de estilo que tenemos, no tenemos que seguir esperando al servidor. Podemos estilizar basándonos en la predicción en sí.

Y finalmente, el giro de la trama, que son los componentes del servidor de React. Creo que en este momento el año pasado eran más una cosa emergente y parece que se están convirtiendo en algo más consistente en las bases de código día a día. Así que los componentes del servidor de React, el problema allí es que no pueden leer el contexto de React. Así que juntando todas estas cosas, esto básicamente nos dice que el estado tiene que ser dinámico.

Si nuestro método de estilo no es lo suficientemente flexible como para trabajar a través de estas interacciones, vas a sentir esa fricción súper, súper rápido y tus aplicaciones van a parecer que están estilizadas de una manera realmente torpe. Y si tu biblioteca, como una biblioteca de CSS y JS, como Emotion o style components, depende del proveedor de temas para inyectar los estilos en tiempo de ejecución, vas a tener un problema bastante grande y te estás preparando para una deuda técnica.

Pero no solo me lo tomes a mí, porque a principios de este año, quiero decir a finales de marzo, principios de abril, el creador de styled components realmente hizo una buena nota de que ya no recomiendan la biblioteca y que actualmente está en modo de mantenimiento. No es que no recomienden la biblioteca, sino que ya no recomiendan CSS y JS necesariamente como un patrón. Déjame corregirme. Pero realmente todo se reduce a un par de cosas diferentes. La primera es la preocupación por el rendimiento. La segunda es la hidratación SSR y ese problema de contexto del que hablamos hace unos segundos.

Así que styled components, que una vez fue la opción preferida para el estilo basado en props dinámicas, básicamente si los equipos tienen que considerar o tienen planes de migración sobre cómo pueden terminar alejándose de eso, ¿qué están usando realmente las personas o hacia qué se están inclinando con la nueva dirección de React? Bueno, el primero es tailwind y creo que muchos de nosotros vimos esto venir. Así que V4 se siente no solo como una actualización, sino más como un reinicio de la arquitectura de la biblioteca en sí. Así que, como dije, hay una configuración CSS primero, que es un cambio realmente grande porque ya no tenemos que definir nuestros tokens de estilo y nuestras personalizaciones dentro de JavaScript. Y esto realmente nos acerca más a la plataforma y a estar más cerca del CSS nativo. También es 3.5 veces más rápido en compilaciones incrementales, porque está utilizando esas características nativas de CSS. Está utilizando características nativas como propiedad, mezcla de colores, todas las cosas en CSS que conocemos y amamos.

Y básicamente, siento que están diciendo que ya no somos solo una biblioteca de utilidades. Somos un motor de construcción nativo de CSS para la web moderna. Y luego CSS en sí mismo también está teniendo un momento de resplandor. Hay toneladas de cosas nuevas que han salido en los últimos años para las que podríamos haber recurrido a otras herramientas. Cosas como Sass para anidamiento. Ya no tenemos que recurrir a eso porque el anidamiento ahora es nativo en CSS. También tenemos cosas como el Selector Has, que nos evita tener que usar mucho JavaScript para obtener cierta lógica para el estilo. Y también tenemos cosas como las consultas de contenedor que están haciendo mucho más fácil estilizar no solo el viewport, sino el contenedor en sí.

Y si eres como yo y tal vez no te molesta que tu comida se toque de vez en cuando, o no te importa tener un poco de CSS en tu JS, podrías preguntarte, ¿hay un punto medio? ¿Hay una manera de que pueda seguir usando un patrón como CSS en JS, pero sin los problemas de rendimiento o los problemas de hidratación que cosas como styled components o emotion nos dan? Así que una cosa con la que he estado jugando recientemente se llama Panda CSS. Y se presenta como el sucesor de CSS y JS, pero te da esa sintaxis muy familiar como styled button, pero analiza tu código en tiempo de compilación, al igual que Tailwind lo hace y extrae un archivo CSS estático. Esto significa que ya no tenemos que inyectar nada en tiempo de ejecución. Y todos los activos que necesitamos se generan durante el tiempo de compilación. Y la parte realmente genial es que es seguro en tipos. Así que si estás trabajando en algo como un sistema de diseño o tal vez un equipo donde tienes diferentes tokens de diseño yendo de un lugar a otro, esto te da esas guías.

Así que sé que eso fue mucho. Así que quiero alejarme por un segundo muy rápido. Así que React 19 y lo llamé 19.2 acaba de salir recientemente. Está cambiando un poco el juego. El estilo no se trata realmente solo de cómo se ven las cosas. Se trata realmente de cómo responden al estado y la interacción. También aprendimos que el contexto es limitado y los componentes del servidor y la hidratación son más importantes ahora que nunca y el rendimiento va a ser todo. Entonces, ¿dónde nos deja eso? Tailwind se está inclinando hacia un CSS nativo. El CSS y JS en tiempo de ejecución realmente está comenzando a dar un paso atrás y el CSS nativo está avanzando rápidamente para poder llenar esos vacíos.

Así que ahora que hemos hablado un poco sobre las reglas, quiero echar un vistazo rápido a un poco de código para estos tres contendientes. Así que el primero va a ser módulos CSS. Esto debería parecer muy normal porque es el mismo CSS que conocemos y que amamos. Pero es de alcance seguro y nativo para la plataforma. Así que cuando miramos esto, podemos ver que es bastante limpio. Podemos usar nuestros selectores CSS como data pending para manejar el estado y esto funciona perfectamente con componentes del servidor porque se compila en un solo archivo CSS estático. No tienes ningún bloqueo de proveedor y es universalmente entendido. Así que si alguien nuevo en tu equipo está llegando, no tienes que preocuparte por tener un gran tiempo de adaptación para ellos y pueden comenzar a contribuir de inmediato. Es aburrido, pero a veces aburrido es algo bueno para la consistencia. A veces, sin embargo, aburrido puede tener un pequeño costo.

Y si echamos un vistazo al componente a la derecha, y espero que sea la derecha. Sí. No. Izquierda. Uno de los lados. Cuando intento conectarlo a mi estado y React, tengo que unir manualmente esas partes. Esto puede volverse muy, muy tedioso, especialmente cuando pensamos en tener que escribir todos esos diferentes nombres de estilo. No sé ustedes, pero soy muy bueno escribiendo la cosa equivocada y no dándome cuenta hasta que algo no funciona y luego depurar un error de ortografía es lo más difícil de todo porque no te va a decir que está mal.

Así que la cosa es que la desviación de diseño es inevitable. Así que sin un compilador o barandillas que te digan cuándo algo está bien o mal, digamos que tal vez estás usando margen de 10 píxeles o alguien más está usando margen de un rem, a lo largo de los años o del tiempo de tu proyecto, esas inconsistencias y números mágicos se volverán un poco incontrolables y será mucho más difícil mantenerlos juntos. Y cuando confiamos en la disciplina humana para mantener la consistencia, eso no va a ir muy bien. Porque yo mismo no soy consistente en muchas cosas y todavía soy solo una persona.

Así que básicamente queremos elegir módulos CSS si queremos priorizar la longevidad de la arquitectura sobre la velocidad de desarrollo, pero solo sepan que van a tener que invertir mucho en linters y en revisiones de código para asegurarse de que su sistema de diseño o cómo están diseñando no se desmorone. Y luego queremos echar un vistazo a Tailwind CSS y esto nuevamente va a ser realmente genial para nuestra velocidad. Así que típicamente, Tailwind ha requerido ese archivo de configuración de JavaScript, pero cuando echamos un vistazo a nuestro CSS global, podemos ver que estamos definiendo esos nuevos tokens directamente dentro de nuestro CSS. Y esa es ahora nuestra nueva verdad con el bloque de directiva de tema. Así que nuestra configuración es nativa y nuestra herramienta de construcción básicamente solo está escaneando nuestro marcado y generando el CSS correspondiente que necesitamos.

No hay un puente de contexto, por ejemplo, que teníamos con módulos CSS como en tiempo de ejecución, pero también quiero ser honesto y reconocer muchas de las críticas que tiende a dejar. Ahora había una imagen que quería agregar, pero no pude porque el nombre de la clase era demasiado largo y en realidad no cabía en la pantalla. La cuestión es que los nombres de clase pueden ser realmente, realmente indisciplinados si no tienes cuidado. Y cuando se vuelven realmente largos así, depurar especialmente la especificidad puede ser muy difícil. Y muchas veces tenemos las opciones, como pueden ver, de simplemente agregar los números mágicos en el CSS mismo, lo que de alguna manera derrota todo el propósito de tener un sistema de diseño consistente.

Así que viene con cosas realmente buenas, es realmente fácil de usar, pero si no tienes cuidado y no tienes patrones realmente buenos, como hablaré en un segundo, o simplemente lanzas números mágicos por todas partes, de alguna manera derrota el propósito de usarlo. Así que si vas a optar por algo como Tailwind, definitivamente vas a necesitar más utilidades dentro de su ecosistema, y tiene un ecosistema muy, muy vasto. Vas a necesitar algo como Prettier para asegurarte de que tus nombres estén bien organizados, o tal vez algo como Tailwind Variants, que es muy, muy útil para obtener esas diferentes permutaciones de props para ti. Tailwind es la forma más rápida que siento ahora mismo para construir las interfaces, pero para tener un sistema mantenible, vas a tener que traer tus propias barandillas, por así decirlo.

Y finalmente, quiero tomar un segundo rápido para hablar sobre Panda CSS. Si nunca lo has visto antes, de alguna manera resuelve el problema del que acabamos de hablar con Tailwind, que es esa estructura. Así que Panda es un compilador sin tiempo de ejecución, y de alguna manera parece que estoy escribiendo un objeto JavaScript regular, en territorio familiar si alguna vez has usado style components o algo como Emotion, y tienen el concepto de recetas. Así que puedo definir una receta de tarjeta, tengo los estilos base para el diseño, y luego también puedo definir mis diferentes variantes. Y puedo incluso tener lógica compuesta para modo oscuro o modo claro si quiero. Ahora, cuando ejecuto esta construcción, Panda no solo entrega el JavaScript, en realidad analiza el archivo, genera un CSS estático y coincide con esas definiciones, y me permite tener seguridad de tipos también. Así que, por ejemplo, si hago algo como tipo periwinkle, y sé que todo mi sitio es en realidad púrpura, voy a obtener un error tanto cuando estoy desarrollando, como también obtendría uno en tiempo de construcción, porque ese no es uno de los tokens conocidos.

Oh, okay, perfecto. Una cosa que también quiero mencionar es que va a haber un pequeño paso adicional. Así que para Panda, tenemos que ejecutar algo llamado Panda code gen para crear esos estilos para nosotros para que podamos usar esas utilidades. Así que básicamente crea todo un sistema de estilos de tus tokens, todo lo que quieras guardar. Esto sería algo que podrías configurar potencialmente con algo como una acción de GitHub. No son muchos pasos adicionales, pero es un paso adicional que necesitaríamos hacer.

Así que esto es algo que es genial para tal vez empresas o sistemas de diseño que puedan querer convertir de herramientas como Emotion o style components. Así que hemos visto un poco de código, así que ahora ¿qué elegimos realmente y cómo lo elegimos? Así que en teoría, creo que tenemos muchas restricciones del mundo real, tenemos muchas preferencias. ¿Cómo juntamos eso para simplemente elegir una solución de estilo? Porque no queremos seguir eligiendo una solución de estilo, ¿verdad? Como cada dos años. Queremos tener algo que escale, queremos tener algo que funcione, y lo más importante, queremos tener algo que realmente sobreviva a la próxima refactorización.

Así que tengo como una lista de verificación para mí de preguntas que hago cuando pienso en nuevos estilos. Y es más o menos lo que ves aquí. ¿Va a funcionar con componentes del servidor? ¿Va a básicamente generar ese CSS estático para mí? ¿Es seguro en tipos? Eso es algo realmente importante, especialmente para los equipos para asegurarse de que estás diseñando consistentemente con otras personas en tu equipo. ¿Es nativo primero? ¿Y utiliza esas nuevas características de CSS que están saliendo y acercándolo más a la plataforma? No queremos hacer lo contrario donde usamos tanto JavaScript para ofuscar o alejarnos más. ¿Y transmite? Lo cual es súper importante ahora cuando pensamos en más y más componentes del servidor de React que están surgiendo.

Si la respuesta es no para cualquiera de esos, aunque puedas estar eligiendo una herramienta, también podrías estar adquiriendo bastante deuda técnica. Y también creo que se reduce a dos cosas, que son la velocidad y la rigurosidad también. Si eres un equipo de una sola persona o tal vez solo dos personas y te preocupa hacerlo lo más rápido posible, eso probablemente influirá mucho en tu decisión de moverte hacia algo que ya está mayormente hecho para ti como Tailwind en lugar de usar CSS modules o si tienes personas en tu equipo que son más nuevas y te preocupa una curva, es posible que no necesariamente originalmente optes por Panda. Estas son todas consideraciones que querrías tener en cuenta cuando se trata de tu solución de estilo.

Y la cosa es que no hay una única respuesta correcta sobre qué método usar. Realmente se reducirá a cuál es tu necesidad actual. Así que como dije, quieres construir rápido. Quieres enviar. Quieres poder iterar tan rápido como puedas. Tailwind podría ser el camino a seguir. Si necesitas seguridad de tipos o necesitas rieles de seguridad para asegurarte de que todos estén en la misma página, una herramienta como Panda realmente brilla. Y si estás trabajando en una base de código heredada grande que tiene muchos estilos diferentes de todas partes y hacer una refactorización inmediata de todo no está en los planes, convertir a CSS modules podría ser el camino a seguir de manera incremental. Y si tu preocupación es tal vez tener personas nuevas en tu equipo o nuevos desarrolladores, Tailwind o CSS modules podrían tener una curva de aprendizaje más baja.

Y para interactividad compleja, Panda CSS o Tailwind con una herramienta como Tailwind variants para facilitar mucho el uso de esas diferentes permutaciones de props será el camino a seguir. La cosa es que todos tenemos nuestras herramientas favoritas o al menos tenemos una herramienta que a veces preferimos sobre otras. Y escuchar que las cosas han cambiado nuevamente o que hay algo más que necesitamos considerar puede ser realmente agotador. Pero lo único consistente y constante en nuestra industria es el cambio. Y ni siquiera llegué a cubrir las cosas realmente divertidas como la depuración y las pruebas y todas esas cosas realmente, realmente geniales. El objetivo no es realmente perseguir la nueva tendencia o como la nueva cosa divertida que está saliendo, sino más bien ser deliberado sobre cómo estamos trabajando con nuestros equipos y cómo estamos verificando para ver si nuestras soluciones de estilo están funcionando actualmente para nuestro equipo, para nuestro flujo de trabajo y para nuestro producto.

están funcionando actualmente para nuestro equipo, para nuestro flujo de trabajo y para nuestro producto. 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 tu aplicación. Y hacia dónde se dirige realmente el front end. Y así es como llegamos a crear aplicaciones que se ven bien, que se sienten bien de mantener, que escalan bien con nuestros equipos y aún se ven realmente bien.

Gracias. Vamos a algunas preguntas. Hay muchas preguntas, sí. Estás construyendo una aplicación ahora mismo, ¿qué eliges? Tailwind. Genial. Impresionante. Así que vamos a esta primera pregunta. ¿Cuál es tu opinión sobre tener una biblioteca de estilos que siempre o fomenta las anulaciones de estilo frente a las cerradas? No me gusta eso porque si siempre tienes que crear consistentemente anulaciones para todo, creo que eso un poco derrota el propósito de tener la biblioteca. Solo un poco. Sí.

Tengo que estar de acuerdo. Muy bien. Esta siguiente viene de Chris. ¿Cuál es el mayor caso de uso para CSS preprocesado como Sass hoy en día? ¿Se está volviendo irrelevante con CSS moderno implementando la mayoría de sus características? Y supongo que mucha gente, lo vimos en los resultados de la encuesta, lo están cambiando por post CSS. Entonces, ¿qué piensas? Creo que herramientas como Sass podrían estar en declive. No podría ser.

Y creo que eso es lo que es. Creo que muchos equipos están tratando de ajustar sus dependencias. Y si CSS nativo ya lo está usando o ya lo tienen, creo que podríamos seguir viendo un declive. Pero sé que hay muchas empresas que todavía usan Sass por una variedad de razones diferentes. Lo pienso un poco como PHP. No pensamos en usar PHP directamente hoy en día. Pero hay un montón de sitios web y una buena parte de la web que todavía lo usa. Definitivamente.

Muy bien. Esta siguiente es de Jay. ¿Cuáles son tus pensamientos sobre StyleX? Y si no estás familiarizado, creo que es el que es de Meta. Se parece un poco a JSS. ¿Has oído hablar de él? No, no lo he hecho. Así que es similar a JSS, pero es de Meta. Es su versión de todo este asunto de CSS en JS. Tendré que buscarlo. Tendré que poner ese en la lista la próxima vez.

Esta siguiente es de Karthik. ¿Cómo dirías que el consejo de estilo se traslada a React Native? No he usado React Native. Bien. Quiero decir, se relaciona un poco porque creo que StyleX fue el enfoque de Meta para que, funcione para React, funcione para React Native. Pero, genial. Siguiente. ¿Cuáles son tus pensamientos sobre los métodos de estilo para micro frontends? ¿Deberían todos seguir el mismo enfoque? No creo que tengan que hacerlo. Cuando pienso en micro frontends, pienso inmediatamente en Astro. Y Astro, puedes usarlo para una variedad de cosas diferentes, ¿verdad? Porque es independiente del lenguaje. Puedes tener, por ejemplo, un componente de React, puedes tener un componente de Vue, puedes tener lo que sea. Y mientras lo pienso, podría usar la misma filosofía de estilo, pero no sé si usaría las mismas herramientas exactas. Así que si un equipo se mueve más rápido con un conjunto de herramientas y otro se mueve más rápido con un conjunto diferente, no creo que tener la misma herramienta deba ser una barrera para que puedas crear rápidamente. Sí, creo que en ese punto es más un problema de gestión.

¿Cómo quieres organizar tus equipos? Exactamente. Muy bien. Katy está preguntando, ¿qué herramienta de CSS recomiendas para aplicaciones de Atlassian? ¿Alguien dijo eso? ¿Porque estoy en Atlassian? Sí, tal vez. Bueno, en realidad, un pequeño anuncio, mi jefe estará muy feliz. Trabajo en una aplicación donde estoy promoviendo una aplicación llamada Atlassian Forge, y básicamente son aplicaciones de React a gran escala dentro de Atlassian, Jira, Confluence, todas las cosas divertidas. Y puedes usar nuestra biblioteca de UI o puedes traer la tuya propia. Puedes traer tu propio componente de UI. Así que si no quieres usar nuestra biblioteca de UI y te gustaría usar tu propio CSS, te gustaría usar tu propio TIL, lo que sea, también puedes traerlo. Me gusta solo CSS nativo, pero uso nuestra biblioteca de UI porque hace que se vea y se sienta nativo. Me encanta.

Muy bien, esta siguiente es de ESK. ¿Qué tan bien adoptado está Panda CSS? ¿Parece que tendrá buena longevidad? Está mejor adoptado este año que el año pasado. Quiero decir de los resultados de la encuesta y tendré que volver a mirar la diapositiva, quiero decir que tenía tal vez un 4 o 5% de adopción. Parece que está aumentando, y el ecosistema parece estar muy bien apoyado y mejorando. No diría que conviertas todas tus aplicaciones de inmediato, pero definitivamente diría que lo mantengas en el radar. Pruébalo, porque realmente me gusta el patrón, y me encanta que esté básicamente en línea con el rendimiento de todas las otras herramientas. Así que ya no se trata solo del tiempo de ejecución o del tiempo de construcción. Realmente se trata de cuál es tu experiencia de desarrollador preferida. Entendido.

Eso es todo el tiempo que tenemos, pero si tienes más preguntas, encuentra a Bri caminando por ahí, porque hay muchas muy buenas aquí y en CatchUp. Muchas gracias, Bri.