No recomiendo Tailwind CSS

Artículo original ↗ Discusión en Hacker News ↗

Tailwind CSS polariza a los desarrolladores frontend: algunos ven sus clases utility-first como una forma elegante de domar hojas de estilo grandes y desordenadas, y de hacer que los componentes sean autosuficientes y fáciles de reutilizar en equipos grandes. Sus críticos argumentan que recarga el marcado, oscurece la semántica, debilita la separación entre estructura y diseño y, en última instancia, solo re-abstrae CSS mientras sigue obligándote a entender el lenguaje subyacente. Muchos concluyen que la “mejor” elección depende mucho del contexto —tamaño del proyecto, habilidades del equipo y herramientas—, y que alternativas como CSS moderno sin frameworks, CSS Modules, BEM o bibliotecas de UI a menudo se prefieren para la mantenibilidad a largo plazo.

Tono general

  • La discusión está muy polarizada y repite debates pasados sobre Tailwind; muchos la califican de bikeshedding.
  • Varios señalan la continua popularidad de Tailwind como prueba de que resuelve problemas reales; otros ven su difusión como señal de un liderazgo frontend débil o de “slop”.

Beneficios percibidos de Tailwind

  • Acelera la implementación, especialmente para devs que no quieren diseñar una arquitectura CSS ni un esquema de nombres.
  • Las clases utilitarias hacen que los componentes/páginas sean autosuficientes; los cambios tienen menos probabilidades de causar regresiones por cascada en otros lugares.
  • Un sistema de diseño coherente puede centralizarse en la configuración de Tailwind (colores, espaciado, radios, modo oscuro, etc.) y luego reutilizarse mediante utilidades.
  • Funciona bien en equipos grandes y codebases grandes al evitar convenciones BEM divergentes y “spaghetti” de CSS.
  • Es fácil copiar y pegar elementos entre proyectos y que se vean idénticos.
  • El autocompletado, las herramientas del IDE y la asistencia de IA hacen que los nombres de las clases sean fáciles de recordar y aplicar.

Críticas principales

  • El marcado se vuelve ruidoso y difícil de leer; los atributos class codifican un mini lenguaje en lugar de usar clases semánticas.
  • Rompe o difumina la separación entre “estructura y estilo”; se siente como volver a los estilos en línea.
  • Requiere aprender el vocabulario de Tailwind además de CSS; los devs experimentados en CSS informan que les ralentiza.
  • Los problemas de cascada/prioridad (por ejemplo, utilidades en conflicto) socavan el “razonamiento local”, lo que lleva a complementos como tailwind-merge.
  • El uso de @apply es controvertido: algunos lo ven como necesario para la cordura, otros dicen que derrota el propósito de Tailwind.
  • Fomenta valores improvisados y de uso único (p-[13px], escalas de color mezcladas), así que la coherencia sigue dependiendo de la disciplina del desarrollador.

CSS, componentes y alternativas

  • Varios sostienen que el propio CSS (y el modelo de HTML) es el problema de raíz; Tailwind es un mecanismo pragmático de adaptación entre muchos.
  • Otros prefieren CSS moderno con variables, nesting, estilos con scope, CSS Modules o BEM, a menudo combinados con frameworks de componentes.
  • Algunos dividen responsabilidades: CSS o sistemas de diseño para tokens y semántica; utilidades al estilo Tailwind solo para layout/tipografía.
  • Unos pocos señalan que, con LLMs/agentes generando CSS, la principal ventaja de Tailwind (la autoría manual rápida) puede importar menos con el tiempo.

Contexto y visión de “la herramienta correcta”

  • Muchos concluyen que la idoneidad depende del contexto: bueno para equipos grandes, prototipos e interfaces con mucho uso de utilidades; menos convincente para codebases pequeñas y bien diseñadas con CSS acotado a componentes.