Volver al blog
Por qué elegimos Tailwind CSS (y dejamos SASS)

Por qué elegimos Tailwind CSS (y dejamos SASS)

Después de años usando SASS y BEM, migramos a Tailwind CSS. No fue por moda — fue por productividad real medible en cada proyecto.

30 de octubre de 2024 @devlabscl 2 min de lectura
tailwind css frontend productividad

La historia corta

Usamos SASS con BEM durante 5 años. Funcionaba. Pero cada proyecto nuevo empezaba con la misma ceremonia: configurar variables, definir mixins, crear la estructura de archivos, escribir clases que al final solo se usaban una vez.

Tailwind eliminó esa ceremonia. Y con Tailwind v4, eliminó también el archivo de configuración.

Lo que ganamos

Velocidad de desarrollo

No es anecdótico. Medimos el tiempo de desarrollo de componentes similares con ambos enfoques:

  • Card con SASS/BEM: escribir HTML, crear archivo .scss, definir clase .card, modificadores --primary, --large, media queries. ~25 minutos.
  • Card con Tailwind: escribir HTML con clases utilitarias. ~8 minutos.

El componente final es visualmente idéntico. La diferencia está en el proceso.

Cero CSS muerto

Con SASS, borrar un componente significaba buscar y eliminar sus estilos. Con Tailwind, los estilos están en el HTML — si borras el componente, los estilos se van con él.

Esto es más importante de lo que parece en proyectos grandes. Hemos heredado codebases con 40KB de CSS que nadie toca por miedo a romper algo.

Consistencia automática

<!-- Spacing siempre en múltiplos de 4px -->
<div class="p-4 mt-6 gap-8">

<!-- Colores del tema, no valores hex sueltos -->
<p class="text-gray-600 bg-blue-50">

No hay lugar para padding: 13px o color: #333333. El sistema de diseño está en las clases.

Lo que perdimos (y no extrañamos)

  • Nombres de clases semánticos.card__title--highlighted era legible pero verboso. text-lg font-bold text-blue-600 es igualmente claro.
  • Archivos SCSS separados — Menos archivos que mantener no es una pérdida.
  • Mixins reutilizables — Tailwind @apply cubre los pocos casos donde los necesitamos.

Cuándo no usamos Tailwind

Para ser justos, hay casos donde no lo elegimos:

  • Librerías de componentes publicadas — Si distribuyes un paquete npm, CSS Modules o styled-components dan mejor encapsulamiento.
  • Emails HTML — Tailwind funciona con su plugin de email, pero las limitaciones del rendering de emails hacen que inline styles sean más predecibles.

Tailwind v4: el salto

La versión 4 eliminó el tailwind.config.js. Ahora todo se configura en CSS con @theme:

@import "tailwindcss";

@theme {
  --color-primary: #3245ff;
  --color-surface: #13151a;
  --font-family-sans: 'Inter', system-ui, sans-serif;
}

Menos tooling, misma potencia. Exactamente lo que queríamos.