Mi gran amigo Dani Cabal nos contó en su artículo Tailwind es a la programación lo que la peste fue a Europa medieval cómo hemos viajado al pasado para volver al presente e implementar nuestros estilos como hace 30 años. 

Pero en este artículo no os voy a llevar al pasado sino al futuro, en concreto a un futuro en el que nuestra capa de estilos está bien organizada y estructurada, tenemos variables, utilidades y clases encapsuladas que nos ayudan a que nuestro código gane en legibilidad y limpieza. ¿Pero no hacemos esto ya? Tranquilidad, seguid leyendo. 

«¿CSS? A donde vamos, no necesitamos CSS.»

De vuelta al futuro

Para viajar a ese futuro prometedor, no usaremos un Delorean sino algo con más clase, o mejor dicho clases. Usaremos Tailwind.

Si bien hay fans y detractores de Tailwind, hay cierto consenso en los inconvenientes que genera su uso. ¿Pero acaso es un argumento de peso que nuestro código se vuelva ilegible e inmantenible? “Por suerte”, tenemos herramientas para luchar contra estas contrariedades y flexibilizar y escalar nuestros estilos. 

– ¡Pero yo ya hago eso que dices! 
– Espera y sigue leyendo.

Problemas de lectura y debug

Una de las principales quejas que recaen sobre Tailwind es que el código generado ensucia nuestro HTML ya que un componente estándar puede tener decenas de clases incluso aún siendo un componente pequeño que solo tenga las clases necesarias. Solo teniendo en cuenta las imprescindibles, las correspondientes asignadas a media queries y alguna que otra pseudo clase nos plantamos en una buena ristra de clases. Ni que decir tiene que volver a este componente pasado un tiempo para modificarlo se puede convertir en una ardua tarea, pero que no cunda el pánico, tenemos una solución a este problema.

Está solución no es otra que encapsular nuestros estilos, hay varias maneras de hacerlo pero me voy a centrar en dos en concreto. La primera sería encapsularlos en clases con @apply. Esto no es otra cosa que una clase de css que contiene las clases de Tailwind. 

.button {
  @apply bg-green rounded-l
}

Con esto y utilizando la clase button tendremos todos  los estilos que hemos aplicado, en este caso bg-green y rounded-l

Otra solución de encapsulación sería utilizar una librería como por ejemplo class-variance-authority. Con ella podemos no solo extraer nuestros estilos del HTML sino también controlar cambios de estado y variantes. 

Otro problema común es la inspección de estilos en el navegador. Si utilizamos Tailwind de forma canónica debuggear se hace tedioso, si encapsulamos estilos con @apply solventamos este problema, no así con class-variance-authority ya que el resultado equivale a añadir los estilos como clases en el HTML.

Llegados a este punto hemos resuelto el problema de tener una ristra interminable de estilos como clases en el HTML y una mejora a la hora de debuggear (si encapsulamos con @apply). ¿Acaso no es esto un enorme paso hacia el futuro?

– Yo ya hacía esto con estilos semánticos preprocesados hace más de 10 años.
– Si, pero ahora utilizas Tailwind. ¡Boom!

“¿Qué nos pasa en el futuro Doc? ¿Nos volvemos gilipollas o algo así?” (Marty McFly)

Aprender y dominar un framework

Otro problema que resaltan los detractores de Tailwind es lo tedioso que es aprender las más de 4000 clases que incluye. Sinceramente, en nuestro trabajo como desarrolladores estamos constantemente aprendiendo y tener que estudiar una nueva tecnología no considero que sea un problema. Además, al final siempre hay clases más comunes que otras y no es complicado encontrar las clases que implementen propiedades menos usadas. 

Por otra parte, sabiendo una clase sabidas todas sus variantes. Por ejemplo, si sabemos que p-4 equivale a padding: 1rem (en base a 16px) sabemos que p-8 equivale a 2rem. 

Si sabemos que la clase rotate-45 equivale a transform: rotate(45deg) sabemos que la clase rotate-60 equivale a… 

-Esto… La clase rotate-60 no está contemplada en Tailwind, habría que añadirla a la configuración tal que

extend: {
  rotate: {
    '60': '60deg',
  },
}

– Vale ¿y la clase p-15?
– Tampoco existe, habría que añadirla a la configuración también
– Pero mi diseñador ha puesto varios paddings de 52px en sus diseños.
– Seguro que son imprescindibles esos espacios. O puede que no les haya dado tiempo a aprender las más de 4000 clases que tú si has aprendido y no sepa que tienes que añadir ese espaciado en la configuración. Y ten en cuenta que la clase p-15 solo afecta el padding, si quieres un margen de 52px  también debes de añadirlo a la configuración.
-Vale, le pasaré el curso Haz tu propio twitter en solo 2h con Tailwind a los diseñadores.

Insisto, no debe de ser un problema aprender a utilizar una tecnología, sin embargo…

CSS se desvanece en el tiempo

Después de un año de uso intensivo me cuesta esfuerzo recordar las propiedades base de CSS y mi conocimiento se está desvaneciendo como Marty McFly cuando no conseguía que su madre fuera al baile del encantamiento bajo el mar con su padre. Cuando aparezca un nuevo framework, y os aseguro que aparecerá (como cada viernes), tendré que apuntarme todas las propiedades que tiene CSS en un almanaque para revisarlo cuando llegue el momento.

“Supongo que no estáis preparados para este framework. Pero a los juniors les encantará.”

Conclusiones

Llegados a este punto es el momento de plantearnos cuál es la diferencia entre encapsular y organizar nuestra capa de estilos con Tailwind vs CSS preprocesado. ¿Estamos viajando varios años en el futuro o volviendo al lejano oeste? Huelga decir que cada desarrollador es libre de ejercer su trabajo con la tecnología que más le agrade, con la que se sienta más cómodo o por la que más le paguen. 

Me parece interesante pensar si realmente estamos mejorando nuestro stack dándole funcionalidades a tecnologías que no están pensadas para ello. Tailwind nos dice (en el header de su página web) que con su uso vamos a construir sitios web modernos sin dejar el HTML, justo todo lo contrario que ofrecen los enfoques de encapsulación de Tailwind. Tal vez nuestras webs sean modernas, pero ¿acaso las desarrollaremos más lento y dejando continuamente el HTML? Solo hay una cosa cierta, “En mi opinión, si vas a hacer algo como esto, hazlo con estilo.” (Emmett L. «Doc» Brown).

Lee más en nuestro blog