Qué está en discusión (y qué no)
Conviene aclararlo de entrada: Tailwind es CSS. No reemplaza al lenguaje ni te exime de entenderlo. Si no sabés cómo funciona flexbox, flex gap-4 items-center te va a fallar igual que display: flex. Lo que cambia es dónde escribís los estilos y cómo los organizás.
En el enfoque tradicional escribís reglas en un archivo .css o .scss y las aplicás mediante clases semánticas: .card, .card__title, .btn--primary. En el enfoque utility-first componés el diseño directamente en el marcado con clases atómicas de propósito único: rounded-lg, p-6, text-sm.
La discusión real no es «cuál es mejor», sino qué problema estás tratando de resolver.
El problema que Tailwind vino a resolver
Cualquiera que mantuvo un CSS grande conoce estos síntomas:
- Nadie borra nada. Ante la duda de si
.header-old-v2se sigue usando, se deja. El archivo solo crece. - La especificidad se descontrola. Aparece el primer
!importanty ya no hay vuelta atrás. - Nombrar cuesta más que estilar. Metodologías como BEM existen justamente porque poner nombres consistentes a nivel equipo es difícil.
- Todo es global. Tocás una regla para arreglar una sección y rompés otra que no estabas mirando.
Tailwind ataca esos cuatro puntos de raíz. Las clases utilitarias son de alcance local por definición, no hay que inventar nombres, la especificidad es plana y el CSS no crece de forma indefinida: siempre son las mismas utilidades reutilizadas.
Lo que se pierde en el camino
Tampoco es gratis:
El marcado se vuelve ruidoso. Un botón puede terminar con quince clases. Es legible cuando lo escribiste vos, menos cuando abrís un archivo ajeno seis meses después.
Hay curva de aprendizaje. Aunque sea CSS, hay que memorizar la nomenclatura. mt-4 es margin-top: 1rem, pero eso hay que saberlo.
Requiere build. Tailwind necesita un paso de compilación. En un entorno donde solo podés subir archivos por FTP a un hosting compartido, eso complica cosas.
Duplicación en el HTML. Si repetís la misma combinación de veinte clases en diez lugares y no estás trabajando con componentes, cambiar el diseño implica editar diez veces. Tailwind asume que tenés componentes (React, Vue, partials de Blade, bloques de WordPress). Sin esa capa, el argumento se debilita bastante.
Qué cambió con Tailwind 4
Vale mencionarlo porque modifica varias objeciones históricas. La versión 4 movió la configuración al propio CSS: en lugar de un tailwind.config.js, se define el sistema de diseño con @theme directamente en la hoja de estilos.
css
@import "tailwindcss";
@theme {
--color-marca: #e5662f;
--font-display: "Sora", sans-serif;
--radius-card: 12px;
}Esas variables quedan disponibles como utilidades (bg-marca, font-display) y también como custom properties nativas de CSS, así que se pueden usar en CSS común dentro del mismo proyecto. La frontera entre «usar Tailwind» y «usar CSS» se volvió mucho más porosa. Además el motor nuevo compila bastante más rápido y la detección de clases ya no requiere configurar rutas a mano.
Comparación práctica
| Criterio | CSS tradicional | Tailwind |
|---|---|---|
| Velocidad al prototipar | Media | Alta |
| Curva inicial | Baja | Media |
| Escalabilidad en equipo | Depende de la disciplina | Alta por defecto |
| Peso final | Crece con el proyecto | Estable |
| Legibilidad del marcado | Alta | Media |
| Legibilidad de los estilos | Media | Alta |
| Necesita build | No | Sí |
| Consistencia del diseño | Requiere convención | Forzada por el sistema |
Cuándo elegir cada uno
Elegí CSS tradicional cuando:
- El proyecto es chico y no justifica una toolchain.
- Trabajás sobre un tema de WordPress clásico sin build, o retocás estilos de un maquetador visual como Elementor.
- Necesitás animaciones complejas,
@supports, selectores muy específicos o control fino que en utilidades se vuelve incómodo. - El sitio lo va a mantener alguien que no conoce Tailwind y no va a aprenderlo.
Elegí Tailwind cuando:
- Trabajás con componentes: React, Vue, Astro, Livewire, bloques nativos.
- El proyecto va a crecer y lo van a tocar varias personas.
- Querés un sistema de diseño consistente sin escribir la documentación de tokens a mano.
- Estás iterando diseño rápido y necesitás ver cambios sin saltar entre archivos.
La opción que casi nadie menciona: las dos
En la práctica, los proyectos que mejor envejecen usan un híbrido. Tailwind para el layout, el espaciado y las variantes de estado, y CSS propio para lo que las utilidades hacen incómodo: keyframes, estilos de contenido generado por un editor, resets específicos, o esos tres componentes que se repiten en todo el sitio y merecen su propia clase.
Tailwind incluso lo contempla con @apply, aunque conviene usarlo con moderación: abusar de @apply es reconstruir el CSS tradicional con pasos extra.
En resumen
CSS tradicional te da libertad total y te cobra en disciplina. Tailwind te quita algo de libertad y te devuelve consistencia y velocidad. Ninguna de las dos cosas es universalmente mejor, y la mayoría de las discusiones online se producen porque cada uno está pensando en un proyecto de escala distinta.
La pregunta útil no es cuál está de moda, sino: ¿este proyecto tiene componentes?, ¿lo va a tocar más gente?, ¿va a vivir tres años? Si respondés que sí a las tres, Tailwind te va a ahorrar trabajo. Si respondés que no, el archivo .css de siempre sigue siendo una decisión perfectamente profesional.
Deja una respuesta