Dejé de recomendar Tailwind CSS: la verdad que nadie te cuenta

Hay un hilo en Hacker News con 100 puntos y 102 comentarios peleándose por una sola frase: "I don't recommend Tailwind CSS". Y no, no lo escribió un abuelo que odia el progreso. Lo escribió un dev que lo usó en producción durante años.

Si usas Tailwind — o estás por adoptarlo en tu empresa — este artículo te va a incomodar. Y es exactamente lo que necesitas leer. 😬

El framework que nadie cuestiona

Tailwind CSS es el framework de moda: miles de clases utilitarias que resuelven espaciados, colores y tamaños sin que toques una hoja de estilos.

Su pitch es irresistible: "no necesitas saber diseño, solo combina clases". Y para prototipos es verdad. Es rapidísimo.

Pero la crítica tiene un punto incómodo: hay un techo de clases básicas que tienes que internalizar, y al inicio pasas el día con la pestaña de documentación abierta. No es magia: es una curva de aprendizaje disfrazada.

El argumento más rebatido (y por qué no muere)

Los fans citan siempre al creador, Adam Wathan, y su defensa es elegante: la separación de concerns no desaparece, cambia de dirección. Con CSS semántico, tu CSS depende del HTML. Con utilidades, tu HTML depende del CSS. El acoplamiento existe en ambos casos, solo cambia la flecha.

Suena razonable... hasta que ves el problema real: el markup te miente. El orden de las clases en tu HTML no determina cuál gana: lo decide el orden en que Tailwind genera las clases en la hoja final, que tú no controlas. Tienes que abrir el inspector y adivinar.

Ejemplo concreto: ¿qué color gana si pones text-red-500 y text-green-500 en el mismo elemento? La respuesta no está en tu HTML. La decide el compilador. Y eso, en un proyecto grande, es una bomba de tiempo.

El pecado más grave: no aprendes CSS

Aquí está la parte que más duele: Tailwind crea una falsa sensación de aprendizaje. Usas colores y espaciados pre-hechos, y crees que sabes CSS. No sabes CSS: sabes Tailwind.

Piensa en un botón: fondo índigo, texto blanco, esquinas redondeadas. En CSS vanilla se explica solo. En Tailwind escribes bg-indigo-600 text-white font-semibold rounded-lg... y para saber qué color es exactamente indigo-600, necesitas la documentación abierta. El código no se explica a sí mismo.

Y cuando llega un bug de cascade o un diseño que no está en el catálogo de clases, el dev junior se paraliza. Nunca aprendió los fundamentos porque el framework se los escondió. 📉

La ironía que nadie menciona

Mientras tanto, el CSS nativo dio un salto enorme: cascade layers, @property, anidamiento nativo... y la ironía máxima es que Tailwind está construido sobre esas mismas features modernas. Es una capa de utilidades sobre un CSS que ya no necesita intermediarios.

El debate ya no es "utilidades vs CSS a mano". Es "CSS nativo moderno vs una capa encima". Y la plataforma está ganando terreno cada año.

Mi opinión (la que nadie te dio)

No es que Tailwind sea malo. Es que es una decisión, no un default. Para un producto grande con muchos devs tocando componentes, tiene argumentos. Para un proyecto server-rendered con templates, es sobre-ingeniería pura.

Y en LATAM el problema es peor: adoptamos frameworks por moda, no por arquitectura. Contrata a un dev "experto en Tailwind" y probablemente nunca escribió una media query a mano en su vida.

El consejo del autor original es el más sano que he leído este año: aprende CSS primero. Después decide con conocimiento. El tiempo que ahorras hoy, lo pagas con intereses mañana.

Yo lo firmo. Y añado: un CV que diga "Tailwind Developer" no es un skill, es un red flag para cualquier tech lead que sepa de verdad. 🚩

¿Y tú? ¿Usas Tailwind por convicción o porque "todo el mundo lo usa"? Cuéntamelo en los comentarios. 👇

Comparte esto con ese dev que jura que Tailwind es el futuro del CSS. 🚀