Usar un kit de comidas es una trampa seductora. Obtienes las zanahorias ya picadas y la salsa ya medida, y de repente te conviertes en un chef porque seguiste tres pasos para armar un plato. Se siente como una victoria porque no tuviste que pasar una hora preparando ingredientes ni aprender a equilibrar sabores desde cero. Pero no has aprendido realmente a cocinar; solo has aprendido a seguir un conjunto de instrucciones proporcionadas por una empresa que quiere asegurarse de que sigas pagando la suscripción.
El argumento de la “productividad” para Tailwind es el mismo que se usa para vender esos kits de comidas. Nos dicen que nombrar clases es una pérdida de tiempo y que pegar flex items-center justify-between directamente en un div es la máxima eficiencia. (Probablemente porque todos hemos sido engañados antes por una herramienta de “productividad”). Pero nombrar las cosas es uno de los dos problemas más difíciles en la informática por una razón. Cuando nombras una clase .user-profile-header, estás describiendo lo que el elemento es y su rol en la aplicación. Cuando usas Tailwind, estás describiendo lo que el elemento se ve en una instancia específica. Esta es una regresión fundamental en cómo pensamos sobre la web. Hemos intercambiado la arquitectura semántica por una lista de atributos visuales, convirtiendo efectivamente nuestro HTML en una hoja de estilos gigante y fragmentada.
¿Desde cuándo decidimos que el archivo HTML también debería ser la hoja de estilos? Si miras el argumento en why-i-dont-recommend-tailwind-css, el problema central es la carga cognitiva de leer un muro de texto que parece un gato caminando sobre un teclado. Es una cosa escribir estas clases cuando estás en el flujo de una nueva función; es otra cosa completamente diferente mantener un proyecto donde cada elemento tiene treinta atributos. Es como leer una novela donde cada adjetivo se reemplaza por una especificación técnica del color y tamaño del objeto. Eventualmente podrías hacerte una idea, pero la prosa está arruinada y la intención del autor queda enterrada bajo una montaña de minucias.
Luego está la fricción de la cadena de herramientas. Para que Tailwind funcione, no solo estás escribiendo CSS; estás gestionando un pipeline de PostCSS, un archivo de configuración y un paso de compilación que debe purgar las clases no utilizadas para que tu CSS de producción no pese cinco megabytes. Para un lenguaje diseñado para ser interpretado por un navegador sin una sola línea de compilación, hemos añadido una cantidad masiva de sobrecarga solo para evitar escribir unos pocos archivos .css. Es un intercambio extraño: evitamos la “dificultad” de la cascada introduciendo la complejidad de un sistema de compilación. Básicamente hemos construido un compilador para evitar escribir un lenguaje que no lo necesita. O tal vez solo soy viejo; no, las matemáticas no cuadran.
La industria está actualmente en un sueño febril de Tailwind, pero el péndulo siempre oscila hacia el otro lado. Ya hemos visto esto antes con el auge y caída de varias bibliotecas de “CSS-in-JS” que prometían resolver los mismos problemas y terminaron creando otros nuevos. A medida que el anidamiento nativo de CSS y las variables CSS se convierten en el estándar en todos los navegadores modernos, la necesidad de un framework utility-first desaparece. Para el Q4, veremos una migración significativa de vuelta hacia módulos CSS nativos y hojas de estilo puras en los diez boilerplates frontend más populares. La “comodidad” de Tailwind es una ganancia a corto plazo que conduce a deuda técnica a largo plazo y código ilegible. Estamos intercambiando la salud a largo plazo de nuestras bases de código por la gratificación inmediata de no tener que pensar en un nombre de clase.
Tailwind es simplemente estilo en línea con un mejor presupuesto de marketing.
