Introducción a TailwindCSS

Este artículo es una introducción pragmática del valor que aporta TailwindCSS y vamos a entrar a evaluar los beneficios y trade-offs de adoptar este framework.

Introducción

Para quien desconozca, TailwindCSS es un sistema de diseño creador por Adam Wathan y  Steve Schoger  que usa CSS y que se ha construido como un sistema de diseño que se puede utilizar a lo largo de una aplicación como si estuvieramos hablando de piezas de Lego. Es lo que se llama un approach utility first.

Este sistema de diseño trae consigo definiciones de paletas de color, el espaciado entre elementos, la tipografía, las sombras y todo lo demás que constituye un sistema de diseño.

Tailwind CSS no es el primer framework CSS que utiliza un estilo utility first, ya que hay otros menos conocidos y que aparecieron antes como Tachyons.

Beneficios

Si no eres diseñador o front-end seguramente todo esto te va a sonar genial. Si por lo contrario eres diseñador, sigue leyendo porque TailwindCSS cuestiona algunas convenciones buscando una solución que vienen del mundo del software backend.

Diseño por composición

Este punto requiere su explicación detallada. TailwindCSS no intenta cumplir con el mantra de CSS semántico ni intenta seguir BEM. Veamos primero las definiciones de estas dos maneras de hacer:

TailwindCSS no sigue CSS Semántico

Es una metodología que promueve el "separation of concerns" y por lo tanto la idea es que su HTML solo debe contener información sobre su contenido, y todas sus decisiones de estilo deben tomarse en CSS.

El siguiente ejemplo es una clara demostración de esto. Para mostrar un mensaje de bienvenida voy a usar el atributo class bautizado con el uso que le voy a dar a nivel de aplicación (un mensaje de bienvenida). Por lo tanto esta clase CSS la voy a llamar welcome.

<style>
.welcome {
    text-align: center;
}
.welcome h2 {
    color: red;
}
</style>

<p class="welcome">
    Bienvenidos al blog de <h2>Nil</h2>
</p>

Este approach presenta un problema. Nuestro CSS depende estrictamente del HTML.

Por lo tanto si tenemos que cambiar el HTML vamos a romper el CSS, creando entre si una dependencia directa y dejando la mantenibilidad de nuestra UI en un estado muy frágil. Sobretodo si vamos a reutilizar este CSS en varios lugares.

TaiwindCSS no sigue BEM

BEM (Block Element Modifier) es una metodología que le ayuda a crear componentes reutilizables y compartir código en el desarrollo frontend.

Con BEM solucionamos los problemas de CSS semántico usando nombres explícitos para cada clase CSS que tengamos que usar dentro de nuestro HTML. El mismo ejemplo de antes bajo BEM quedaría de la siguiente manera:

<style>
.welcome__text {
    text-align: center;
}
.welcome__highlight {
    color: red;
}
</style>

<p class="welcome__text">
    Bienvenidos al blog de <h2 class="welcome__highlight">Nil</h2>
</p>

Primero, hay que notar que BEM empuja a que pongas delante el nombre de lo que estás haciendo. En nuestro caso es un mensaje de bienvenida asi que todas las clases que vamos a requerir empezarán por welcome. A partir de ahí, cada trozo debe tener su nombre usando __ y el nombre.

Esto soluciona respecto al CSS semántico la fragilidad de que el CSS dependa de la estructura HTML. Sin embargo, Si tengo que usar 2 mensajes de bienvenida, digamos por ejemplo la primera vez que visitas un site, y luego otro mensaje de bienvenida si vienes de un afiliado, vamos a tener un problema.

Por lo tanto, nos encontramos en un punto en el que o creo código duplicado para separar estas 2 intenciones, o creo una abstracción para poderlo reutilizar o incluso creamos un sistema de diseño basado en componentes como hace Boostrap.

  • Si duplicamos el CSS para cubrir los 2 casos, en este caso es simplemente eso, código duplicado y cuanto más complicado sea el elemento a maquetar más CSS duplicado habrá. Aún así, es mejor que crear una dependencia entre CSS y HTML a expensas de entregar más CSS al navegador.
  • Si creo una abstracción, estamos volviendo al primer problema del CSS semántico. Si cambio el CSS de un punto (ej: mensaje de bienvenida), puedo estar cambiando el comportamiento en otro elemento HTML, creando una dependencia entre CSS y HTML.
  • Si creo un sistema de diseño basado en componentes, vamos a tener que crear más CSS para cubrir casos especiales como resaltar el h2 del HTML del ejemplo. En este caso, tendríamos un componente genérico text en el sistema de componentes y tendríamos que añadir el caso text__welcome-highlight y modificar el sistema de diseño para cada caso no contemplado, creando una dependencia entre el CSS y el HTML una vez más.

TailwindCSS romper evitar esta dependencia entre CSS y HTML o viceversa.

El ejemplo de antes en TailwindCSS quedaría de la siguiente manera:

<p class="text-center">
    Bienvenidos al blog de <h2 class="text-red-600">Nil</h2>
</p>

Tanto text-center como text-red-100 con clases que por defecto trae TailwindCSS. Si tuviéramos que recuperar el caso de nuestro ejemplo, otro mensaje de bienvenida, tendría el mismo CSS (o diferente si fuera una decisión de diseño) sin impactar en cómo se ve ningún otro elemento.

La composición de propiedades CSS resuelve que el CSS del elemento y el HTML estén en dependencia directa. Recalco el CSS del elemento porque a partir de ahora el look and feel dependerá del sistema de diseño, no del CSS y contexto a nivel de tags HTML.

Las naming conventions desaparecen

El uso de Tailwind CSS puede ayudar a reducir el tiempo que uno dedica a tomar decisiones de naming. Si trabajas en equipo esto aún es más importante dado que todo el mundo tiene preferencias y hay que alinearse primero.

Por ejemplo, usando BEM o CSS semántico hubiéramos tenido que pensar en dar un nombre si requerimos un espacio de 16px entre elementos. Ahora en cambio sólo hay que aplicar la utility mt-4  y además va a ser consistente en todo nuestro código.

Para un color, rojo por ejemplo, usaremos text-red-600 y usaremos el valor de rojo por defecto en vez de ir a buscar el color en hexadecimal o rgba.

Adiós a los magic numbers

Los magic numbers son valores que "funcionan en algunas circunstancias", pero que son frágiles y propensos a romperse cuando esas circunstancias cambian.

A estas alturas no tengo que convencer a nadie, sea de backend o de frontend que los números mágicos en general y en CSS en particular son algo malo.

Como librería CSS, Tailwind evita que uses magic numbers trayendo una serie de valores por defecto bien escalados para no uses valores arbitrarios al ajustar tus diseños. Cada pixel arriba o abajo que tengas que mover está dentro de una escala y definido en Tailwind.

Cambios de guía de estilo consistentes

Al tener todas las utilidades centralizas, se puede construir un sitio web y evolucionar/actualizar/cambiar su aspecto cambiado la paleta de colores, la separación de elementos, los rellenos, la familia y tamaños de las fuente, etc... desde un mismo punto central.

Para ello hay que modificar los valores de un archivo llamado tailwind.config.js. La documentación de TailwindCSS explica cómo hacerlo.

Evitas cambiar de contexto entre HTML-CSS

Quizá la menos importante, pero ahí está. Al trabajar directamente en el HTML y no en archivos CSS mantienes el foco.

Inconvenientes

Lógicamente TailwindCSS no es perfecto tampoco y maximizar la productividad trae consigo algunos trade-off que hay que asumir si aceptas trabajar con un framework CSS tipo utility first.

El HTML contiene detalles de implementación

Es la queja más recurrente. El HTML queda lleno de clases CSS y pierde legibilidad. Si lo que buscamos es un HTML limpio y bonito, no lo vamos a poder conseguir. Es cierto. Aunque si minificas el HTML que entregas al navegador, ¿realmente importa?

Si lo que buscas es identificar ciertos elementos HTML para tener acceso directo via CSS o JavaScript puede subsanarse añadiendo un atributo tipo id, class o  data-* y usarlo como marcador.  

Tooling para eliminar el CSS que no usamos

El otro problema es ciertamente que hay que incorporar el uso de herramientas como NodeJS  para tirar de PurgeCSS y eliminar todo aquel CSS que no se usa. Esto es un peaje que hay que pagar si queremos entregar únicamente el CSS que realmente se usamos en nuestra aplicación.

La documentación explica cómo hacerlo pero puede ser algo duro para principiantes.

Como alternativa, pagando su coste a nivel de bytes entregados al navegador, podemos cargar de una CDN un archivo minificado con todo el CSS base de TailwindCSS. Totalmente desaconsejado, pero posible.

PostCSS para cambiar los valores por defecto

Una vez más vamos a requerir NodeJS y usar PostCSS para aplicar los cambios y sobrescribir los valores por defectos. Y es que todo aquello prefabricado va a tener unos valores por defecto y no queremos que ocurra de nuevo el efecto "Bootstrap" y todas las webs se parezcan entre sí.

Sin embargo hay que decir que está muy bien documentado en la web oficial.

Conclusión

Como siempre, TailwindCSS no es la solución definitiva a todos los supuestos problemas que tiene trabajar con CSS, ni tampoco usarlo te va a permitir no aprender como funciona CSS ni vas a poder evitar escribir lineas de CSS para solucionar ciertos problemas donde TailwindCSS no va a llegar.

Si conoces CSS, TailwindCSS se aprende en una tarde y te va a hacer mucho más productivo.

Si no estás al día, el uso de TailwindCSS hará que le cojas el gusanillo para actualizarte con las nuevas funcionalidades de CSS3 como CSS Grids, Flex-box y cambiar el marco mental para trabajar en modo mobile-first, o al menos, responsive.

A los que no quieren saber nada de front-end usar TailwindCSS les parecerá más sencillo tocar front-end sin tener que escribir CSS directamente.

Comparte este artículo