¿Por qué nos olvidamos de la Arquitectura CSS?

Hubo un tiempo en el que estaba muy extendida la idea de que CSS estaba “roto”, todos conocemos la persiana de Peter Griffin y tenemos el mejor merchandising sobre las bondades de CSS.

Siempre he defendido mi trabajo como maquetadora (mis compañeras hablaron sobre lo (des)conocidos que somos) basándome en estas bromas sobre CSS o en el debate sin fin sobre si CSS es o no un lenguaje de programación.

Tranquilos que no voy a entrar en esas divagaciones porque todes sabemos que CSS es Turing complete. Hoy os voy a hablar sobre la importancia de la arquitectura CSS en nuestros proyectos.

¿Por qué es importante una buena arquitectura CSS?

Al igual que en otros lenguajes de programación, parte de la calidad del código reside en su escalabilidad y facilidad de mantenimiento, CSS también cumple este aspecto. Cuando comenzamos un proyecto nuevo generalmente contamos con un arquitecto que establece cómo hemos de organizarnos para cumplir con las buenas prácticas en cuanto a arquitectura front, pero generalmente CSS ni está ni se le espera en esa organización. Con suerte nos encontramos una carpeta “styles” en assets con una planta rodante dentro. Además, muchas veces nos encontramos con que el proyecto va a contar CSS-in-JS o algún framework CSS como Tailwind y parece que ya todo está decidido y no debemos perder tiempo en pensar en nuestra estructura.

Y, por si esto fuera poco, no solemos hablar con diseño ni UX sobre cómo está planteado el proyecto. No importa que no tengamos un sistema de diseño, antes de que este concepto fuera mainstream teníamos componentes, antes de los componentes UI-kits y así hasta el inicio de los tiempos. Sentarte un rato a conversar y conocer el proyecto que vamos a desarrollar junto con las personas que lo han ideado de manera conceptual es uno de los pilares de una buena arquitectura CSS. ¿Crees que no tienes nada que hablar con tus compañeros de equipo? Aquí te cuento por qué es importante trabajar mano a mano con ellos.

¿Qué buscamos con una buena arquitectura CSS?

Cuando hablamos de una buena arquitectura CSS no nos referimos a las “buenas prácticas” que se han consensuado durante todos los años de vida del lenguaje ni a la aplicación de metodologías de naming o similares porque estas no son más que herramientas para conseguir un fin, pero no implica que se usen correctamente.

Cuando hablamos de una buena arquitectura CSS nos basamos en cuatro características:

• El CSS debe ser previsible: las reglas de tu CSS deben comportarse como es de esperar. Esto parece un principio muy básico y fácil de seguir pero en ocasiones cuando en un proyecto grande hay varias personas desarrollando estilos pueden encontrarse conflictos entre lo que a unos resulta previsible y a otros no. Es muy importante tener un consenso desde el principio del desarrollo ya que un CSS predecible es indispensable en una buena arquitectura.
• El CSS debe ser reutilizable: las reglas CSS deben estar desacopladas y ser lo suficientemente abstractas para poder construir nuevos componentes de manera sencilla a partir de las distintas piezas existentes.
• El CSS debe ser mantenible: este es el principal problema de CSS y el que más bromas y frustraciones genera como hemos comentado. Cuando tenemos que añadir, modificar, actualizar o reorganizar nuestros estilos los cambios no deberían suponer una refactorización de los mismos.
• El CSS debe ser escalable: a veces tendemos a pensar que un proyecto pequeño será así para siempre y por lo tanto no necesitamos cumplir con la escalabilidad. Pero este principio va más allá de la capacidad de crecer del proyecto, también es importante dentro de un código escalable que éste sea de fácil administración por una sola persona o un grupo así como que la curva de aprendizaje de la estructuración de código sea lo más asequible posible.

¿Por dónde empezar?

Se suelen definir 3 principios básicos para comenzar una arquitectura sólida que cumpla con los puntos mencionados en el apartado anterior.

• Define los componentes básicos de tu arquitectura CSS. Pueden ser componentes, átomos, bloques... dependiendo de qué metodología utilicemos, lo importante es definir unas unidades básicas.
• Estructuración de los componentes: definir qué vamos a construir con esos componentes.
• Definir una capa de ordenación estructural: ordenar estas estructuras a un nivel superior que nos permita entender de un vistazo cómo está construido nuestro CSS.

Para estos tres principios se han definido distintas metodologías y estrategias. A nivel más básico, metodologías de naming como puede ser BEM (bloque, elemento, modificador); metodologías de diseño-desarrollo como Atomic Design (átomos, moléculas, organismos, templates y páginas); y metodologías de la propia arquitectura CSS como SMACSS, OOCSS o ITCSS. Podéis conocer un poco más de estas metodologías aquí.

Estas metodologías no están escritas en piedra y no debemos seguirlas sin más. Hay que hacer un ejercicio de abstracción global teniendo en cuenta los diseños del proyecto así como las tecnologías que vamos a utilizar para desarrollarlo y encontrar nuestra propia fórmula si ninguna de las anteriores encaja en nuestras necesidades.

De coger aquello que necesitemos, con un nivel de consistencia adecuado, de cada una de estas metodologías han surgido híbridos como BEMITCSS o la fusión de Atomic Design con BEM, que también es muy utilizada.

Principios de ingeniería del software en CSS

Como generalmente no se considera CSS un lenguaje de programación, el aplicar principios de ingeniería de software a su desarrollo puede sonar extraño. Pero, dado que CSS es un lenguaje declarativo y está lo suficientemente maduro, no hay motivo para que no lo apliquemos.

De hecho, si eres desarrollador de CSS y esto te suena raro, vas a darte cuenta de que llevas aplicándolos bastante tiempo:

• Separación de intereses: utilizar clases que cumplan con un único propósito. El ejemplo más sencillo es utilizar clases específicas para interacciones con JS y otras distintas para aplicar estilos: es habitual utilizar camelCase para las destinadas a JS o añadirles el prefijo js- (lo que resulta más previsible).
• Principios SOLID: como el principio de responsabilidad única a la hora de definir las jerarquías de las hojas de estilo que componen nuestro CSS. Es decir, si estamos utilizando Sass como pre-procesador en nuestra hoja de estilos de la aplicación importaremos por orden jerárquico cada uno de los archivos scss que cumplen con una única responsabilidad, primero el reset, después la declaración de variables, etc. Cada uno de estos trozos de CSS y la forma en la que las hemos organizado en ficheros cumple con este principio de responsabilidad única de los principios SOLID.
• Principios DRY vs. WET: Don’t Repeat Yourself y We Enjoy Typing. Son dos principios antagónicos y muchas veces en el día a día caemos en la trampa del WET teniendo que refactorizar nuestro propio código más tarde, “secándolo” al aplicarle el principio DRY.
  Un ejemplo práctico del principio DRY es la definición de variables para una paleta de colores, que generalmente tendremos definidos en un único lugar de nuestro código haciendo así mucho más sencilla la modificación o también la abstracción de partes comunes del CSS en mixins o extends (siempre usados con placeholder) si utilizamos Sass.

Conclusión

Cómo habéis podido comprobar la aplicación de principios de desarrollo de software utilizados en otros lenguajes de programación son aplicables al desarrollo de CSS. Tal y como comenzaba este artículo, el CSS es una parte igual de importante que el JS o la arquitectura de datos de la API que se usa en una aplicación y debemos tratarlo con el mismo cariño y atención que ya le ponemos a estas otras partes mencionadas.

¡Tenemos un podcast sobre arquitectura CSS!