Skip to main content

Arquitectura CSS moderna dentro de Tailwind

Tailwind no elimina la arquitectura, la hace inevitable​

Usar Tailwind no elimina CSS, elimina CSS implícito y desordenado. La arquitectura sigue existiendo, pero cambia de forma.

En CSS clásico:

  • La arquitectura vive en archivos.
  • Se oculta tras selectores.
  • Se rompe con el tiempo.

En Tailwind:

  • La arquitectura vive en decisiones explícitas.
  • Está distribuida entre config, componentes y capas.
  • Se vuelve visible cuando falla.

Tailwind no evita el caos. Lo hace evidente antes.

Capas reales en un proyecto con Tailwind​

Aunque Tailwind promueve utilidades, un proyecto real sigue teniendo capas claras:

  1. Sistema: Tokens, escalas, reglas globales (configuración).
  2. Estructura: Layout, regiones, composición (HTML + utilidades).
  3. Patrones: Combinaciones recurrentes de utilidades (componentes).
  4. Excepciones: Casos raros, ajustes quirúrgicos, hacks conscientes.

El error común es mezclar estas capas sin criterio.

@layer no es una reliquia, es una herramienta quirúrgica​

Tailwind mantiene el concepto de capas CSS:

  • base
  • components
  • utilities

No para volver a CSS clásico, sino para colocar lo que no pertenece al HTML.

Uso correcto de @layer:

  • Base: normalización, tipografía global mínima.
  • Components: patrones que no deben repetirse.
  • Utilities: utilidades atómicas (core de Tailwind).

Si algo vive mejor fuera del JSX, probablemente pertenece a @layer.

Cuándo usar utilidades y cuándo abstraer​

Regla práctica:

  • Si se repite poco → utilidades en el markup.
  • Si se repite mucho → abstracción.
  • Si se repite y cambia → componente.
  • Si se repite y no debe cambiar → clase en @layer.

Error frecuente:

  • Abstraer demasiado pronto.
  • Crear clases “bonitas” sin contrato.
  • Volver a nombres genéricos (.card, .box, .item).

CSS “extra” no es fracaso​

Un proyecto sano con Tailwind sí tiene CSS propio, pero:

  • Poco.
  • Con intención clara.
  • En lugares controlados.

Ejemplos legítimos:

  • Animaciones complejas.
  • Estados avanzados (:has, combinaciones raras).
  • Hacks de navegador.
  • Reset puntual de librerías externas.

Ejemplos ilegítimos:

  • Reescribir spacing.
  • Ajustar colores arbitrarios.
  • Duplicar utilidades existentes.

Arquitectura por responsabilidad, no por tipo de archivo​

En proyectos modernos:

  • No se separa por “CSS / JS / HTML”.
  • Se separa por responsabilidad.

Ejemplo mental:

  • Un componente incluye:
    • Su estructura
    • Sus utilidades
    • Sus variantes
    • Su CSS puntual (si lo necesita)

El CSS no vive solo. Vive donde se usa.

Evitar el “utility soup”​

El mayor riesgo con Tailwind no es la repetición, es la acumulación acrítica.

Señales de alarma:

  • Clases largas sin patrón.
  • Diferencias mínimas entre componentes.
  • Cambios de spacing o color sin razón clara.
  • “Copiar y pegar hasta que funcione”.

Solución:

  • Detenerse.
  • Extraer patrón.
  • Nombrar intención.
  • Reubicar la decisión.

Composición > herencia​

Tailwind fuerza un modelo moderno:

  • No hay cascada profunda.
  • No hay herencia implícita.
  • Todo se compone explícitamente.

Ventaja:

  • Menos efectos colaterales.
  • Cambios más previsibles.
  • Menos miedo a tocar código.

Coste:

  • Más decisiones visibles.
  • Más responsabilidad.

La composición exige criterio, pero lo recompensa con estabilidad.

Interacción entre Tailwind y frameworks modernos​

En React, Vue, Svelte, etc.:

  • Tailwind vive en el JSX/templating.
  • El estado vive en el framework.
  • La arquitectura surge de su interacción, no de uno solo.

Errores frecuentes:

  • Intentar que Tailwind “resuelva lógica”.
  • Usar clases como sustituto de estado.
  • Condicionales visuales sin sistema.

CSS moderno que sí convive con Tailwind​

Tecnologías compatibles y útiles:

  • :focus-visible
  • :has()
  • Custom properties (CSS variables)
  • Media queries avanzadas
  • Container queries (cuando aplica)

Pero siempre bajo la misma regla:

Si no puedes explicar por qué existe, no debería estar.

Señales de una buena arquitectura con Tailwind​

  • La config es pequeña y clara.
  • Los componentes son legibles.
  • Las excepciones están localizadas.
  • Los cambios no rompen cosas inesperadas.
  • El equipo comparte lenguaje visual.

Errores frecuentes al escalar con Tailwind​

  • Convertir utilidades en clases sin contrato.
  • Crear una “mini capa CSS” caótica.
  • Abstraer antes de entender el patrón.
  • No revisar decisiones antiguas.
  • Pensar que Tailwind es solo productividad.

Este módulo introduce el sexto pilar del sistema: una arquitectura sana no elimina complejidad, la coloca en el sitio correcto y la hace visible.