¡Es 2023 y finalmente puedo hablar sobre CSS Atómico!

Hola a todos. Es genial estar aquí en la React Summit, uniéndome a todos ustedes en línea. Y hoy, estamos aquí para hablar finalmente sobre CSS atómico.

Antes de seguir adelante, permítanme presentarme. Pueden encontrarme en todas partes como wide combinator. Soy Ingeniero de Software Senior en Medallia, mentor en TechLabs, y un Experto en Desarrollo Web de Google en Performance. Y el enlace para esta presentación lo pueden encontrar debajo de este código QR y los enlaces a muchas otras presentaciones que también tengo.

Entonces, hoy estamos aquí para discutir, primero, los problemas tradicionales de tener CSS a gran escala. Algunas de las cosas que considero de mal gusto sobre el tema de CSS atómico, tailwind, etc. Y luego lo que realmente considero mal y feo sobre CSS atómico como metodología. Pero también estamos aquí para discutir cómo pueden abordarse algunos de estos problemas, y luego tendremos algunas reflexiones finales sobre todo. Entonces, comenzando con los problemas de escalabilidad de CSS, supongo que el cliché es el primero. La falta de espacios de nombres. Comenzó como una característica en CSS para permitir la portabilidad y la parte de cascada de CSS, pero si estás trabajando con otros lenguajes de programación, te das cuenta de que si careces de espacios de nombres incorporados, tendrás problemas a gran escala. A lo largo de la historia de CSS, hemos tenido diferentes tecnologías que intentan abordar eso como CSS en JS y otros que básicamente usarían VLTools para interceptar y generar ámbitos automáticamente.

Otro problema clave que considero es que CSS tiende a quedarse en el pasado. Eso se debe principalmente a que tienes que mantener la compatibilidad con versiones anteriores como máxima prioridad cuando estás desarrollando nuevas características para el lenguaje, para la especificación. Y debido a eso, no siempre es factible retroceder en el tiempo y deshacer decisiones erróneas. Y eso sucede porque, sí, tienes que tener en cuenta la tasa de adopción, tienes que tener en cuenta el soporte del navegador, todo al hacer cambios en el lenguaje.

Otra cosa es que es impredecible para los humanos de alguna manera. La forma en que funciona CSS es que fusiona estilos provenientes de diferentes fuentes, diferentes orígenes. Estoy hablando de estilos en línea, hojas de estilo internas y externas, un montón de selectores que tienes, etc. Y para entender correctamente cómo sucede esto, debes conocer los cálculos de especificidad, cómo funciona la herencia y muchos otros. Y eso es bastante complejo para los humanos. Entonces, al final, nos resulta difícil predecir cómo se resuelven esos estilos.

Y por último, pero no menos importante, CSS tiene una naturaleza estática. Entonces, sigue siendo principalmente un conjunto de reglas de diseño estáticas con un soporte limitado para estilos dinámicos y variables. Y sé que tenemos funciones lógicas. Sé que hoy en día tenemos variables CSS, por lo que está mejorando cada vez más. Pero lo que noto es que todavía lucha para mantenerse al día con las demandas de las páginas web dinámicas, donde tienes temas y cambios dinámicos, ese tipo de cosas, provenientes de datos de JavaScript, etc.

Entonces, eso es un desafío. Diría que esos son los cuatro conceptos principales que tenemos.

Y ahora, pasando a Atomic CSS, el núcleo de esta charla. Intentaré abordarlo desde una perspectiva buena, mala y fea. Pero, si probablemente estás cansado de escuchar esto varias veces, quiero mostrarte, quiero hacer un enfoque diferente aquí. Y voy a comenzar explicando lo que considero que son en realidad malas interpretaciones que la gente tiene sobre Atomic CSS. Y la primera es, a menudo se compara mucho con los estilos en línea. Pero lo cierto es que, en primer lugar, los estilos en línea son realmente costosos para el navegador, porque es muy costoso convertir las cadenas que tienes en el atributo de estilo y en una representación nativa en la plataforma. Además, al agregar esos múltiples estilos, estás agregando múltiples reflows. Además, los estilos en línea no pueden manejar consultas de medios, selectores pseudo y otras características que tienes. Y un punto clave aquí es que, en su mayoría, cuando estás usando estilos en línea, tendrás que seguir definiciones preexistentes como lo harías con clases de utilidad, donde tienes una API muy bien definida y actúan como una única fuente de verdad.

El otro punto que escuchamos mucho es que genera un exceso de HTML, lo cual es malo para el rendimiento. Pero, lo cierto es que hoy en día tenemos muchos algoritmos de compresión, como GZIP, e incluso tenemos técnicas diseñadas para manejar cadenas duplicadas como el algoritmo deflated. Y, también, adopté otra perspectiva en eso. Es decir, cuanto más se repite un selector en la hoja de estilos, en realidad más trabajo tiene que hacer el navegador para resolver esos estilos. Entonces, en ese sentido, el CSS semántico y otros también podrían estar agregando un exceso de HTML.

Luego viene la preocupación de la separación de preocupaciones. Y mucha gente señala que Atomic CSS por definición rompe la separación de preocupaciones, pero creo que deberíamos cambiar nuestra perspectiva y ver que la composición de estilos se realiza en el HTML, pero no estás haciendo alineación de estilos con la altura, esos atributos. En realidad, lo que tienes son solo piezas de una hoja de estilos que se ensamblan en el HTML. Entonces, el HTML es en cierto modo el consumidor del CSS que has creado. Por lo tanto, tienes una API en ese sentido. Y también creo que esto representa esta visión muy extrema de lo que es la separación de preocupaciones. Y eso es peligroso porque puede llevar a escenarios muy imprácticos. Eso incluso se aborda, por ejemplo, en la documentación de Vue.js donde señalan que mucha gente confunde la separación de preocupaciones y la separación de tipos de componentes, por ejemplo. Y, de manera análoga, tienes muchas otras cosas como el rediseño y el mantenimiento se vuelven desafiantes o terminas con mucho CSS no utilizado o es difícil usar lo que está disponible, es difícil saber qué está disponible para que lo uses o incluso tienes que aprender otro lenguaje completo además de CSS. Y la lista es enorme. El punto es que creo que esas preocupaciones son un poco del pasado. Y si observamos Tailwind y las herramientas modernas que tenemos en el ámbito de Atomic CSS en estos días. Tenemos el potencial de aliviar la mayoría de esas preocupaciones e incluso obtener nuevos beneficios.

Entonces, ahora que hemos dejado eso atrás, creo que podemos comenzar a hablar sobre lo que considero que es negativo. Me gusta comenzar con las críticas negativas sobre el tema. Y creo que el Atomic CSS sufre de tener críticas negativas desde sus publicaciones iniciales en 2013.

Por ejemplo, verás algo como, cambios simples en el estilo del módulo han resultado en nuevas reglas en la hoja de estilos. Pero, si lo piensas, el CSS se supone que define el estilo y el diseño de la página. Entonces, si estás modificando la apariencia de los elementos de la interfaz de usuario, está bien que debas hacer ajustes en el CSS. Esto no significa que estés creando nuevas clases. Y en Tailwind, la documentación es la misma. Así que comienza con la construcción rápida de sitios web modernos sin salir nunca del HTML. Pero, creo que hay una suposición peligrosa aquí, que es cambiar constantemente entre HTML y CSS todo el tiempo es algo normal. Pero, esto podría ser en realidad una señal. Si estás ajustando constantemente el marcado mientras trabajas en la apariencia, esto podría indicar que estás tratando el marcado como una extensión del CSS en lugar de como el marcado para la estructura de tu documento.

Y, de muchas de esas tecnologías que tienen que ver con CSS dinámico, verás esas críticas, como las mejores prácticas no funcionan, y ese tipo de cosas. Y, he notado que hay esta creencia popular de que Tailwind es en realidad el futuro de todo el desarrollo web. Y, si no lo estás usando, no estás haciendo web de la manera correcta. Otra cosa es lo que me gusta llamar la dependencia de CSS de utilidad. Entonces, si piensas en HTML semántico en CSS y quieres hacer el ejercicio mágico de convertir eso en Tailwind, lo que tendrías que hacer es descomponer esas clases semánticas compuestas en clases de utilidad atómicas que tengan responsabilidades únicas. Y eso es algo fácil de hacer. Incluso tienes herramientas disponibles, como Windy, que convierten CSS semántico en atómico con Tailwind. Pero, si piensas en lo contrario, es difícil imaginar una herramienta que haga esto porque no puedes construir algo más complejo sin ensamblar esas clases manualmente. Entonces, solo podrías convertir realistamente Tailwind en algún otro framework de CSS de utilidad. Y eso es complicado porque si te mudas a cualquier otro framework o preprocesador, tendrías que hacer una refactorización considerable. Y sé que la mayoría de nosotros no hacemos esto, no estamos cambiando constantemente los frameworks de CSS o los estándares de arquitectura de CSS de manera regular, pero es algo importante que debes tener en cuenta para aplicaciones que se mantendrán a largo plazo.

La otra cosa, esto se aplica principalmente a Tailwind en lugar de toda la metodología, pero a veces veo que faltan características clave de CSS. Durante un tiempo, ese fue el caso de PseudoElement. Casi dos años después del lanzamiento inicial de Tailwind, aún no admitía PseudoElement y algunas otras características. Y eso es algo que muchos preprocesadores de CSS han admitido durante mucho tiempo. Y luego fue el caso de los degradados de fondo y de las animaciones. Y en la actualidad, es el caso de selectores como is, y where, o funciones como min, max y clamp. Y eso tiende a ser el caso para cualquier otra característica de vanguardia.

Entonces tendrás que encontrar soluciones alternativas o lidiar con la falta de ellas por un tiempo. Y el último también está más adaptado a Tailwind es su mecanismo de detección de clases. La forma en que funciona Tailwind es que no analiza ni ejecuta ninguno de tu código. Utiliza expresiones regulares internamente para rastrear cada cadena que podría ser un nombre de clase. Esto significa que solo encontrará clases que sean cadenas ininterrumpidas. Y debido a eso, no puedes construir nombres de clases de forma dinámica. Y creo que esto es algo limitante. Y esto no es realmente una sorpresa. Incluso se menciona en la documentación. Pero es algo que me gustaría ver cambiar desde la perspectiva de un desarrollador que utiliza Tailwind.

Y luego encontramos que hablan de lo feo. Y nuevamente, tengo que empezar con un cliché que es, todavía me resulta muy difícil de escanear. Y en realidad es difícil no estar de acuerdo con eso. Si tienes ese tipo de nombres de clases y quieres, por ejemplo, incrementar eso con media queries, esto se vuelve fijo. Y si lo comparas con lo que sería, por ejemplo, semántica, una alternativa en semántica CSS, tendrías algo como esto donde tienes una clase y luego tienes las media queries tradicionales para las diferentes tamaños de pantalla que soportas. Y digamos en un escenario en el que estás rastreando un error de interfaz de usuario y sabes que no está relacionado con el escritorio o la versión de la tableta, puedes ignorar los bloques de las media queries y enfocarte en tu clase, por ejemplo.

Todo esto sucede porque es simple. Es más fácil para nosotros escanear si necesitamos leer código de arriba a abajo. Y es más fácil para nuestros ojos encontrar pares específicos de propiedades y valores. Entonces, si tienes un resaltado de sintaxis adecuado, separando esas propiedades y valores, incluso tienes una mejor legibilidad. Y puedes decir, bueno, pero esos nombres de clases largos no ocurren mucho allá arriba, pero resulta que sí. Y es común ver sitios web de producción que tienen como 60, 70, incluso más nombres de clases. La otra cosa es que es una especie de cultura que fomenta grandes sopas de etiquetas en el marcado. Entonces, creo que sucede porque con Atomic CSS en general, el enfoque está en las clases, no en el marcado.

Antes de seguir adelante, no me malinterpretes, Tailwind o Atomic CSS, no promueven un HTML feo. Pero la cuestión es que con este modelo mental, puedes agregar tantos divs como quieras y no necesariamente tienes que preocuparte por el significado. Así que terminas en esta área donde puedes hacer las cosas de la manera correcta, pero debido a que es fácil, tiendes a terminar con estructuras DOM anidadas grandes que a veces ni siquiera tienen elementos semánticos significativos. Entonces, esto es, por ejemplo, un marcado real de un pie de página en la plantilla de Tailwind UI. Y sucede mucho allá arriba. Y si tuviera que dar una opinión sobre eso, diría que el problema aquí es que estás pensando primero en las clases de CSS. en lugar de comenzar con el marcado y hacer CSS desde allí. Y siguiendo con esta opinión, creo que las herramientas en general, pueden facilitar hacer ciertas cosas de una manera no ideal. Y creo que eso es lo que está sucediendo aquí. Un enfoque que facilita la semántica. Y realmente me gusta cómo Tony Yeliseya definió esto en términos de una mentalidad que, okay, necesito un lugar para poner mis clases de CSS. Así que solo agrego otro div. Y entiendo que, en última instancia, esto probablemente sea para optimizar la felicidad y la productividad del desarrollador, que es un punto fuerte en esas metodologías, pero me temo que al hacerlo, podrías estar optimizando en exceso el rendimiento, la legibilidad, el mantenimiento y la accesibilidad. Y cada vez más, al revisar esos repositorios abiertos de compartir fragmentos de código, verás ejemplos debatidos en exceso como este, donde tienes un número infinito de esto, tienes, por ejemplo, un encabezado vacío, tienes marcadores de posición haciendo lo que se supone que deben hacer las etiquetas, tienes spans que deberían ser encabezados y así sucesivamente. Entonces, creo que esto podría ser, por ejemplo, malo para la accesibilidad. Y en cuanto al rendimiento, esto también es malo, no por el tamaño de tu nombre de clase, sino porque puedes estar creando estructuras DOM anidadas y este tamaño excesivo del DOM debe evitarse. Y realmente puedes ver esto si revisas, por ejemplo, la brecha de desigualdad de rendimiento del último año, donde básicamente llegas a esta realización de que las computadoras o los teléfonos inteligentes y las redes no son tan potentes como tendemos a pensar.

Otra cosa que debo mencionar como desarrollador es la experiencia que obtienes al explorar cosas con herramientas para desarrolladores. Primero, me resulta realmente difícil encontrar componentes. Esto es algo que generalmente haces cuando estás solucionando problemas en un código base grande. Es importante que puedas reducir los componentes efectivos. Y eso es más fácil si tienes una correspondencia cercana entre el nombre del componente y sus nombres de clase. Pero aquí, con Atomics y Assassin's Jungle, solo tenemos dos opciones. O bien conocemos muy bien esa parte de la aplicación o estamos consultando cadenas en las herramientas. Pero la cuestión es que no todos en el equipo están familiarizados con cada componente en el código base. Piensa en los nuevos empleados, por ejemplo, o en repositorios monolíticos a gran escala en empresas. Y la segunda cosa es que las cadenas pueden ser reutilizadas en varios componentes. Entonces, si solo estás consultando cadenas, podrías obtener múltiples resultados que no son significativos. Y supongo que los resultados aquí, es difícil determinar dónde comienza y dónde termina un módulo. Y esto no es algo nuevo y ni siquiera tiene que ver con Tailwind. Adam Silver señaló eso en su artículo

Otra cosa es que también es difícil modificar el CSS. Por lo tanto, es común que realicemos algunos cambios pequeños y correcciones en las herramientas de desarrollo para ver cómo se verá después de cambiar el código. Pero aquí está el problema, si queremos experimentar con nuestros componentes, debemos asignarles un nuevo nombre de clase y usarlo como selector para poder modificar ese selector. O podemos usar estilos en línea, pero probablemente no veremos los cambios reflejados en toda la interfaz de usuario. Y eso es lo que estamos buscando.

También estamos aquí para discutir cuál puede ser la buena o tal vez la mejor manera de hacer las cosas, y realmente me gustó este tweet de Steven donde señala que Tailwind no es una herramienta, es todo un ecosistema. Tailwind tiene muchas cosas interesantes y creo que pueden ser incluso complicadas si hacemos algunas cosas. Y la primera es aprovechar la generación de tecnología bajo demanda. Entonces, si estás pensando en generar clases atómicas, si las implementaras, por ejemplo, con algún preprocesador de CSS, recorrerías las clases y terminarías con múltiples clases para márgenes y cosas así. Eso es lo que implica la generación bajo demanda. Terminas con un poco de CSS desperdiciado porque luego tienes que purgarlo y es posible que no generes todo el CSS que realmente necesitas. Por lo tanto, la primera recomendación es cambiar de esto a esto, donde solo generas el CSS que estás utilizando. Y si estás utilizando Tailwind, esto está disponible desde la versión 2 de Tailwind y es la configuración predeterminada en la versión 3. Simplemente están en el motor Just-in-Time y otras herramientas también ofrecen eso, como GNOME CSS.

Lo segundo es tener en cuenta Apply. Incluso Adam ha escrito antes sobre los aspectos negativos de usar Apply. Si no estás familiarizado con Apply, me refiero a este tipo de uso. Y lo complicado aquí es que te pierdes los beneficios que obtienes con los enfoques tradicionales de CSS. Te pierdes la división del nombre de clase, te pierdes el tiempo que ahorras al no tener que escribir tu propio CSS, y te pierdes la única fuente de verdad que te proporciona Atomic CSS. Es común ver muchos artículos que mencionan cómo aprovechar lo mejor de ambos mundos, y es común ver esos fragmentos de código donde se utiliza un enfoque híbrido. El punto es que creo que aquí hay un mal potencial porque los desarrolladores podrían estar usando clases funcionales como una forma de deshacer las reglas que se definieron para los componentes. Entonces, si estás usando Apply o algo similar, debes ser muy estricto para evitar que las preocupaciones se intersequen entre sí. Lo otro es la seguridad de tipos, y siento que para algunas comunidades, durante mucho tiempo la falta de una forma en Tailwind de verificar tipos o trabajar con TypeScript fue un obstáculo para su adopción. Pero hoy en día tienes herramientas increíbles como Tailwind CSS ClassNames o más recientemente TypeWind. Estas son herramientas sin tiempo de ejecución que brindan seguridad de tipos, autocompletado y más. Y debido a que puedes detectar errores en tiempo de compilación, incluso puedes usarlo en tu CI.

Otro tema es la Composición de Hojas de Estilo, que es realmente importante, especialmente si estás construyendo un kit de interfaz de usuario. Por lo tanto, si no estás utilizando la fusión de Tailwind, es una herramienta increíble que puedes combinar con la utilidad ClassNames para construir tu propia función ClassName que resolverá muchos conflictos por ti. Y luego puedes usarlo en tus componentes simplemente pasando ClassNames. Y puedes usarlo en componentes que reciben ClassName como una prop.

Si tienes casos más complejos de composición de hojas de estilo, puedes usar la biblioteca classVariancyQuantity, CVA. Con CVA, básicamente puedes definir variantes en el caso del fondo. Por ejemplo, podríamos estar definiendo el tamaño de un botón, la redondez, etc. Puedes definir las variantes completas, y luego puedes pasarlas como props a tus componentes en el caso de nuestros componentes de botón, y CVA las resolverá.

Como puedes ver, se trata mucho de tooling. Así que aprovecha las increíbles tooling que tenemos disponibles, como complementos de gradiente o los complementos de ESLinux, que, por cierto, abordan algunos de los problemas que mencioné en cuanto a que es difícil para los ojos humanos escanear. Y aprovecha también las herramientas para la accessibility. Hay bibliotecas increíbles como Redix y hay casos increíbles de combinar Tailwind con Redix para construir componentes accesibles. Así que échales un vistazo. Y también incorpora tareas de accessibility en tu proceso, como tu proceso de compilación con herramientas como XCore, JSX alley, Lighthouse, etc. E incluso en tu CI para que puedas obtener errores si presentas solicitudes de extracción, eso es increíble.

Y en tu día a día como desarrollador, utiliza herramientas para simular tipos de discapacidades. Y por ejemplo, si te preocupa el punto cultural que mencioné de tener sopas de etiquetas, etc. podría ser un problema para la accessibility, puedes usar XLanguage para detectarlos en una solicitud de extracción.

Y el último tema de esta sección es probablemente el CSS y JS atómicos. Así que hay este gran artículo llamado el problema de shorthand longhand en el CSS atómico que aborda algunos problemas del CSS y JS y el CSS atómico. Y el autor hace un buen punto sobre el CSS y JS atómicos. Dicen que nos permite escribir nuestros estilos de una manera monolítica familiar, pero obteniendo el CSS atómico y todo esto no es nuevo en Twitter, por ejemplo, lo han estado haciendo durante años en React Native sin y Facebook tiene su propia versión de eso que es de código abierto. Y hay un montón de bibliotecas disponibles como Stitches, Styletron, Compile CSS y JS, Vell y otras. Y tienes beneficios. Por ejemplo, ya no necesitas una convención de nombres de clase específica si te gustan las convenciones de Tailwind, por ejemplo, tienes estilos comunes y únicos tratados de la misma manera. También puedes obtener la extracción de CSS crítico y la división de código e incluso abordar otros problemas como los problemas de reglas CSS en el orden de búsqueda.

Sé que hemos hablado de muchas cosas. Así que antes de irnos, solo algunas reflexiones finales. Entiendo que es muy fácil caer en la idea de que esto es solo drama de internet y a tus usuarios no les importa qué herramientas estás usando. Y especialmente porque estamos teniendo muchas discusiones en internet sobre este tema. Pero otra cosa que estamos viendo son algunos artículos o, por ejemplo, personas que optaron por una metodología y tuvieron que cambiarla por otra cosa.

Y ese es el caso de las personas que cambian de Tailwind a otra cosa. Incluso tienes herramientas para convertir Tailwind y tratar de convertir Tailwind de nuevo a clases semánticas. Así que al final, tienes razón, es solo una herramienta pero elegir la herramienta adecuada puede marcar una gran diferencia. Y esa puede ser Tailwind, puede ser algún enfoque de CSS y JS, CSS semántico, módulos CSS, lo que sea.

Lo otro que vemos es que la solución al problema podría simplemente cambiar el problema que tienes. Así que se trata mucho de pensar en términos de compensaciones, compensaciones y compensaciones. Aunque te aconsejé que tengas cuidado con apply, es importante destacar que las clases de utilidad pueden coexistir con otros enfoques. Y el punto óptimo para ti podría ser una combinación de ambas convenciones, y Bootstrap es un ejemplo. En sus últimas versiones o en versiones recientes, introdujeron muchas clases de utilidad manteniendo los componentes tradicionales. Muchos otros frameworks populares han estado haciendo lo mismo.

Lo otro es que creo que Tailwind sufre mucho porque la gente piensa que se aplica a todos los proyectos. Y yo, por ejemplo, pienso que Tailwind es perfecto si estás haciendo desarrollo basado en componentes, como React, Vue, Spelter, lo que sea. Si no lo estás haciendo, entonces probablemente Tailwind no es lo adecuado para ti. Y otra cosa es que hemos recibido muchas quejas de personas que dicen que Tailwind no funciona bien con los Web Components debido a shadowed on, etc. Pero la cuestión es que están encapsulados y el CSS global no tendrá ningún efecto. Ese es el punto de la encapsulación. Así que tal vez no tenga mucho sentido utilizar Lids, Stencil y otras alternativas de Web Components con Tailwind, aunque sea factible. Me encanta esta cita de Guillermo donde compara el impulso que tiene Tailwind con JSX y React Pad. Y sí, JSX creó una sensación similar en la comunidad en su momento porque iba en contra de muchas de las mejores prácticas que teníamos y que nunca consideraríamos una buena idea. Así que creo que es interesante reflexionar sobre esto. Y por último, pero no menos importante, lamentablemente hay mucho, hay un apego emocional a las elecciones que hacen los desarrolladores. Y incluso hay un nombre para eso en psicología que es la identificación con el equipo. Y eso es malo porque te estás apegando a la tecnología y eligiendo bandos cuando probablemente no debería ser así. Eso es todo lo que tenía para hoy. Si tienes alguna pregunta, estoy disponible en línea. Y nuevamente, los enlaces están ahí. Gracias por tu tiempo. Gracias.