Por qué no recomiendo Tailwind CSS

Tailwind CSS es un framework de CSS muy popular entre los desarrolladores web. Sin conocimientos previos en diseño gráfico, te resuelve el estandarizado de espacios, colores y tamaños. Pero además, si eres tenuemente desorganizado, te fuerza a una metodología de trabajo basada en crear grandes estructuras a partir de utilidades sencillas (Utility-First Fundamentals). Y a todo ello hay que sumar una documentación fácil de entender con un buscador impecable.

En el pasado lo utilicé en varios proyectos, me ayudó a crear interfaces de usuario rápidamente. Y a pesar de todo ello, es una herramienta que no recomendaría en cualquier contexto. Te voy a dar mi punto de vista, mis razones, por las cuales deberías pensártelo dos veces antes de usar Tailwind CSS en proyectos medianos o grandes. El único requisito que te pido es una mente abierta, autocrítica y una actitud de aprendizaje.

Debes aprender decenas de clases

Tailwind tiene miles de clases de utilidad. Aunque la documentación es muy buena y el autocompletado del editor ayuda muchísimo, hay un techo de clases básicas que tienes que interiorizar. Lo más probable es que al principio desarrolles con una pestaña del navegador abierta y el buscador trabajando sin parar. Inviertes tiempo en entender la forma más adecuada de aplicar cada clase. Un proceso lento al arranque. Y si has creado tus propias clases que se mezclan con las de Tailwind, la dificultad aumenta.

Rompe la separación entre la estructura y el diseño

Tailwind CSS es una biblioteca de utilidades gigantesca, clases atómicas con tareas específicas. Salvo que agrupes clases con @apply, acabas incluyendo decenas de ellas en tu HTML. Esto rompe la regla clásica de separar la estructura del diseño, o el HTML del CSS. Engorda el HTML, la legibilidad se resiente y pierdes la reutilización.

Ahora bien, aquí conviene pararse, porque es la crítica que más se rebate. Adam Wathan, el creador de Tailwind, escribió el texto fundacional de la defensa, y su argumento es bueno. La separación de responsabilidades no desaparece, cambia de dirección. Con CSS "semántico", tu CSS depende del HTML; puedes reestilizar el HTML, pero tu CSS no es reutilizable. Con utilidades, tu HTML depende del CSS; el CSS es reutilizable, pero tu HTML no se reestiliza solo. El acoplamiento existe en ambos casos, solo cambia el sentido de la flecha.

El argumento es válido en un mundo de componentes, donde React o Vue ya juntan lógica, marcado y estilo en el mismo archivo. Ahí la separación por tipo de archivo ya la habías roto tú antes. Pero en un proyecto renderizado en servidor, con plantillas y CSS clásico, la separación sigue teniendo todo el sentido. No es una ley universal, es una decisión que depende de tu arquitectura.

No es consistente en sus nombres

Su nomenclatura no siempre es coherente, a veces es opaca y tiende a confundir. Fíjate en las clases de alineación. ¿Cuál es la diferencia entre items-center, justify-center, text-center y place-content-center? El nombre no es intuitivo ni sigue un patrón claro. Por si tienes curiosidad, items-center alinea elementos en un contenedor flex, justify-center los alinea en el eje principal, text-center centra texto y place-content-center centra contenido en un grid. Voy a renombrarlas buscando coherencia: flex-align-items-center, flex-justify-content-center, text-align-center y grid-place-items-center. ¿Notas la diferencia?

Hay más ejemplos: justify-center pero items-center (no align-center); border da 1px pero border-2 da 2px. Son fricciones pequeñas que se acumulan.

El design system no se impone tanto como parece

Uno de los grandes argumentos a favor de Tailwind es que su escala de espacios y colores te obliga a ser consistente. Y es verdad, pero con una trampa, los valores arbitrarios. Puedes escribir w-[347px], text-[#1a2b3c] o p-[5.5rem] sin que nada te avise. Son una vía de escape que rompe el sistema. Nada te impide usar sky-400 y blue-400 en el mismo proyecto. La consistencia sigue dependiendo de tu disciplina, no del framework. El sistema te ayuda, pero no te salva de ti mismo.

No es una buena puerta de entrada para aprender CSS

Tailwind es fácil de usar si ya dominas los estilos. Pero para quien tiene poca experiencia en CSS, crea una falsa sensación de aprendizaje. Transmite que es una versión minimalista de escribir CSS, quitándote el esfuerzo de mantener un código ordenado. Usar tantas clases prediseñadas obstaculiza la capacidad de dominar CSS de verdad. El tiempo que ahorras en nombrar clases lo pierdes aprendiendo a usar el framework de la forma más eficiente.

Por otro lado, si profundizas en Tailwind, te alejas de aprender los fundamentos de la plataforma. pt-4 te obliga a traducir mentalmente a padding-top: 1rem. Ganas fluidez en la abstracción, no en CSS. A mis alumnos y compañeros les recomiendo antes aprender CSS que Tailwind. Y si ya eres un desarrollador experimentado, quizá ni necesites el framework.

Es difícil de leer

Te muestro un botón con fondo índigo, texto blanco, fuente seminegrita, bordes redondeados, hover y focus.

Primero en CSS vainilla. Me tomo la libertad de usar variables para colores y espacios, y anidamiento para el hover y el focus, algo compatible hoy con todos los navegadores.

:root {
  --color-blanco: #fff;
  --color-negro: #000;
  --color-indigo: #4f46e5;
  --color-indigo-hover: #4338ca;
  --gap-s: 0.5rem;
  --gap-m: 1rem;
}

.boton {
    padding: var(--gap-s) var(--gap-m);
    background-color: var(--color-indigo);
    color: var(--color-blanco);
    font-weight: 700;
    border-radius: var(--gap-s);
    &:hover, &:focus {
        background-color: var(--color-indigo-hover);
    }
}

Ahora en Tailwind CSS usando @apply.

.boton {
    @apply py-2 px-4 bg-indigo-500 text-white font-semibold rounded-lg hover:bg-indigo-700 focus:bg-indigo-700;
}

El CSS vainilla es autoexplicativo, mientras que con Tailwind tienes que revisar la documentación. ¿Qué color es bg-indigo-500? ¿Cómo de redondo es rounded-lg? ¿bg-indigo-700 es más oscuro que bg-indigo-500? El primer código es más fácil de mantener, la curva para un desarrollador nuevo es baja y el CSS tiende a ser modular. Haces un esfuerzo mayor con CSS vainilla, sí, pero solo al inicio. Después tienes el control total de variables, cascada y nomenclatura.

Un detalle curioso. El ejemplo de arriba usa @apply, y el propio Adam Wathan ha admitido que @apply "básicamente solo existe para engañar a la gente" y que si empezara Tailwind de cero no lo incluiría. Es decir, la vía que usas para recuperar la legibilidad de una clase normal contradice la filosofía de Tailwind. Y si no usas @apply, entonces te comes la sopa de clases en el HTML.

El HTML te miente sobre la prioridad

Quizá hayas oído que Tailwind "ignora la cascada". Es una forma imprecisa de explicarlo, porque el problema real es más sutil e interesante.

Poder controlar qué selector gana según su posición en la hoja de estilos es básico en cualquier arquitectura. Un error típico de los diseñadores web con poca experiencia es creer que el orden de las clases en el HTML determina cuál manda. No es así. Mira este código.

<p class="color-rojo color-verde">Soy un texto</p>

¿De qué color es? No lo sabes. Necesitas ver la cascada del CSS.

.color-verde {
    color: green;
}

.color-rojo {
    color: red;
}

Ahora sí, es rojo, porque .color-rojo está definido después. Hasta aquí, CSS normal.

El problema con Tailwind es que esta ambigüedad no la puedes resolver ni reordenando tus clases. Fíjate.

<p class="text-red-500 text-green-500">Soy un texto</p>

Podrías pensar que gana el verde, que va el último en el atributo. Pues no, sale rojo. Lo que gana lo decide el orden en el que Tailwind genera esas clases en la hoja final, no el orden en el que tú las escribes en el HTML. El marcado te miente. Leyendo el HTML no puedes saber el resultado. Y no lo arreglas cambiando el orden de las clases, porque ese orden lo controla el compilador. Te quedas con !important o con evitar utilidades en conflicto. Es lo que se llama una abstracción con fugas. Te promete simplicidad y te obliga a saber cómo funciona por debajo. Otro caso clásico, class="mt-4 mt-0" no hace lo que su orden sugiere.

No es cómodo trabajar con las Dev Tools

Al construir componentes con muchísimas clases, revisar en el inspector qué estilos se aplican se vuelve lento. Tienes que hacer scroll buscando qué gana y qué se sobrescribe. Con CSS vainilla ves rápido qué estilos hay y en qué orden, y un error es más fácil de localizar. Es verdad que las extensiones de editor alivian esto en tiempo de escritura, pero en el navegador, depurando en producción, la sopa de clases sigue ahí.

Conclusión

¿Y si usas CSS moderno a secas?

Aquí está, para mí, el debate realmente fresco. Ya no es "utilidades contra CSS a mano". Es "CSS moderno nativo contra una capa de utilidades por encima".

Mira lo que la plataforma te da hoy, sin instalar nada:

• Cascade layers (@layer) para ordenar la prioridad sin pelear con la especificidad.
• Anidamiento nativo, ya sin preprocesador.
• Custom properties (variables CSS) para tus tokens.
• :has(), el selector de padre que llevábamos veinte años pidiendo.
• Container queries para responsividad por componente.
• color-mix() para derivar colores.

¿Y sabes qué es lo irónico? Que Tailwind está construido justo encima de esas mismas características. Usa cascade layers nativas, @property, container queries y colores en OKLCH. Lo cual da munición al argumento más incómodo. Si la plataforma ya trae todo eso, ¿cuánto de Tailwind sigue siendo imprescindible?

La contrapartida es clara. CSS nativo te da las características, pero no te da el sistema de restricciones, ni el estilo pegado al marcado (colocation), ni el autocompletado. En proyectos pequeños o renderizados en servidor, el CSS moderno a secas es una opción estupenda. En un producto grande hecho por componentes y con mucha gente tocando, Tailwind sigue teniendo argumentos. No hay un ganador universal, hay un contexto.

Pero pongamos las cosas en su sitio. No es una herramienta mala. Es una herramienta con un coste que se paga en el futuro, y que actualmente compite además con un CSS nativo mucho más capaz que hace unos años. Antes de elegirla, aprende CSS. Después, decide con conocimiento. El esfuerzo inicial que te ahorras hoy, quizá lo pagues con creces mañana. O quizá no. Ahora, al menos, tienes los dos lados para decidir tú.

Fuentes

• CSS Utility Classes and "Separation of Concerns", Adam Wathan (el texto fundacional de la defensa: la dirección de la dependencia).
• Open-sourcing our progress on Tailwind CSS v4.0, blog oficial de Tailwind (motor nuevo, config CSS-first con @theme y las cifras de rendimiento).
• Why I Don't Like Tailwind CSS, Aleksandr Hovhannisyan.
• Disadvantages of Tailwind CSS, Script Raccoon.