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

Rate this content
Bookmark
Slides

Bibliotecas como Tailwind se volvieron muy populares y su enfoque de clases atómicas, también conocido como clases utilitarias, fue un interesante cambio de paradigma en CSS. A muchos desarrolladores les encanta, y es comprensible por qué.

Sin embargo, tendemos a olvidar que la base de esta técnica no es nueva. Mucho antes de Bootstrap, todos teníamos nuestros pequeños fragmentos de CSS copiados de proyecto en proyecto con clases similares.

En esta sesión, discutiremos la evolución del CSS escalable, analizaremos las limitaciones y desventajas del CSS Atómico, y también descubriremos dónde puede ser beneficioso este concepto.

Matheus Albuquerque
Matheus Albuquerque
30 min
06 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy analiza los problemas tradicionales de escalar CSS y las ventajas del CSS Atómico, incluyendo un mejor rendimiento y manejo de consultas de medios. Se pueden abordar preocupaciones sobre el exceso de HTML y la ruptura de la separación de responsabilidades. Tailwind CSS tiene limitaciones en la detección de clases y puede generar un exceso de marcado. Los desafíos incluyen la exploración y consulta de componentes, así como la personalización de CSS. Ahora se aborda la seguridad de tipos con herramientas como Tailwind CSS ClassNames y TypeWind. La composición de hojas de estilo y el CSS y JS Atómico son importantes para construir kits de interfaz de usuario. Consideraciones para Tailwind CSS incluyen su idoneidad para el desarrollo basado en componentes y posibles limitaciones con Web Components.

1. Introducción a Atomic CSS y Problemas de Escalabilidad

Short description:

Hola a todos. Hoy estamos aquí para discutir los problemas tradicionales de escalabilidad de CSS, la falta de espacios de nombres, CSS quedándose en el pasado, su imprevisibilidad y su naturaleza estática.

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.

2. Ventajas de Atomic CSS y Abordando Preocupaciones

Short description:

Entonces, Atomic CSS a menudo se compara con los estilos en línea, pero ofrece ventajas como un mejor rendimiento, manejo de consultas de medios y selectores pseudo, y una API bien definida. Las preocupaciones sobre el exceso de HTML y la ruptura de la separación de preocupaciones se pueden abordar con algoritmos de compresión modernos y un cambio de perspectiva. Al usar Atomic CSS, puedes ensamblar piezas de una hoja de estilos en el HTML, proporcionando una API y evitando escenarios imprácticos. Con herramientas modernas, Atomic CSS puede aliviar preocupaciones y brindar nuevos beneficios.

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.