Tailwind no es para mí

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

Las críticas a Tailwind CSS se centran en sus verbosas clases de utilidad, la “contaminación” del HTML y el bloqueo alrededor de la sintaxis no estándar `@apply`, y algunos desarrolladores sostienen que socava el HTML semántico, la accesibilidad y la mantenibilidad a largo plazo. Sus defensores responden que Tailwind mejora la productividad, mantiene el estilo localizado junto a los componentes y reduce problemas comunes de CSS como el nombrado, los conflictos de especificidad y la acumulación descontrolada de hojas de estilo, especialmente en aplicaciones grandes o desarrolladas con rapidez. El intercambio destaca una tensión más amplia entre el HTML/CSS/JS “aburrido” y las nuevas abstracciones, así como prioridades distintas en torno a la velocidad de desarrollo, la legibilidad y la preparación para el futuro.

Sentimiento general

  • El hilo está muy dividido: algunos ven Tailwind como una gran mejora de productividad, otros lo consideran feo, propietario y malo para el mantenimiento a largo plazo.
  • Muchos sostienen que la elección depende sobre todo del flujo de trabajo personal, la escala del proyecto y la tolerancia al bloqueo por herramientas.

Productividad frente a mantenibilidad

  • Sus defensores dicen que Tailwind:
    • Elimina tener que nombrar clases CSS y gestionar hojas de estilo grandes.
    • Mantiene la “localidad de comportamiento”: los estilos están junto al marcado/componente, lo que facilita copiar y pegar y razonar sobre el código.
    • Acelera el prototipado y los MVP, especialmente para personas sin mucha experiencia en CSS.
  • Sus críticos dicen:
    • Los atributos class largos se vuelven ilegibles, especialmente con 20–50 utilidades en un solo elemento.
    • Refactorizar meses después, o que lo haga otra persona, es doloroso.
    • Fomenta la “sopa de div/span” y una semántica débil, perjudicando la accesibilidad y el rendimiento.

CSS, arquitectura y separación de responsabilidades

  • Un bando enfatiza la separación: HTML para estructura, CSS para estilo, JS para comportamiento. Tailwind se ve como un retroceso hacia estilos en línea y “spaghetti”.
  • Otros argumentan que la separación estricta está sobrevalorada; colocar los estilos junto a los componentes reduce los cambios de contexto y los problemas propios de CSS (guerras de especificidad, abuso de !important).
  • Hay debate sobre si Tailwind es “solo CSS en línea” (críticos) o un sistema de utilidades restringido y basado en temas que evita muchos problemas de los estilos en línea (defensores).

Bloqueo, herramientas y portabilidad

  • Algunos temen que @apply de Tailwind y los tokens de diseño definidos en JS sean propietarios y hagan que los estilos no sean portables.
  • Otros señalan herramientas que convierten entre Tailwind y CSS normal, y proyectos orientados a “des-Tailwindizar” código.
  • Preocupa la necesidad de una etapa de compilación y de herramientas JS incluso para CSS; otros señalan que muchas pilas ya tienen un pipeline de compilación.

Web components, custom elements y Shadow DOM

  • Debate sobre usar elementos personalizados (por ejemplo, <ui-card>) para evitar la sopa de div:
    • Algunos sostienen que se pueden usar etiquetas no declaradas solo por semántica y para seleccionar con CSS.
    • Otros subrayan que eso no es lo mismo que los verdaderos custom elements, que requieren JS y Shadow DOM.
  • Se critica el Shadow DOM como una abstracción problemática que complica el estilo y la integración con Tailwind y otras herramientas.

Alternativas y enfoques intermedios

  • Alternativas mencionadas: PicoCSS, CSS puro con funciones modernas, CSS Modules, Styled Components, LESS/SASS, bibliotecas atómicas/de utilidades y herramientas que extraen Tailwind a CSS normal.
  • Un compromiso habitual: usar utilidades para maquetación/estructura, y clases o componentes personalizados para el aspecto visual; agrupar clases de Tailwind dentro de abstracciones de componentes.

Metadiscusión: moda tecnológica y “tecnología aburrida”

  • Varios comentarios lamentan el cambio constante de frameworks y la tecnología como moda.
  • Algunos defienden HTML/CSS/JS “aburridos” sin herramientas pesadas; otros defienden la experimentación y señalan que los frameworks suelen influir en futuros estándares.