CSS puro o framework utilitario: dónde vive la regla

El precio de un framework utilitario no está en los bytes. Está en las decisiones que sigues tomando, porque el valor de cada regla vive en el HTML que escribes. El CSS nativo con tokens pone la regla en un solo lugar y le da un nombre. La elección es entre regla impuesta y libertad con disciplina.

Dónde vive la regla de estilo en cada camino

En el camino utilitario la regla vive en la lista de clases del elemento. Un botón carga px-4 py-2 text-sm bg-blue-600 en su propio HTML. La hoja de estilo es salida generada, así que el HTML es la fuente de verdad.

La documentación de Tailwind (en inglés) describe ese mecanismo. La herramienta trata los archivos fuente como texto plano y busca tokens que podrían ser clases. Después genera CSS para los tokens que reconoce y descarta el resto.

En el camino nativo la regla vive en la hoja de estilo, elegida por clase o por elemento. El HTML nombra la intención y la hoja guarda el valor.

Esa diferencia decide qué pasa cuando borras una pantalla. En el camino utilitario la regla se va con el HTML. En el camino nativo la regla queda en el archivo, sin uso y todavía interpretada.

Quién decide el valor visual

En el camino utilitario decide quien escribe el HTML. Dos pantallas pueden salir con espacios distintos y nada en la herramienta lo impide.

En el camino de tokens el valor vive en una variable de CSS. MDN describe las variables como forma de definir un valor en un lugar y referenciarlo en varios. La misma página señala el problema que resuelven, que es el color repetido en muchas reglas y el buscar y reemplazar en cada cambio.

Un archivo de tokens define --space-4 una vez. Un componente lee var(--space-4). La decisión sale del elemento y pasa a la escala.

La diferencia central es esta: un camino decide elemento por elemento y el otro decide en el token.

Qué cambia cuando cambia el diseño

Cambiar la marca en el camino utilitario significa editar HTML. El color de marca vive en nombres de clase, así que cada archivo que lo usa tiene que cambiar. Una escala configurada ayuda solo cuando el cambio sigue la escala.

Cambiar la marca en el camino de tokens significa editar una variable. Cada componente que la lee acompaña, sin tocar archivos de componente.

La misma página de MDN registra un límite que conviene saber. La función var() funciona solo en valores de propiedad, así que no sirve dentro de una media query ni de una container query.

Dos recursos nativos cubren el resto. Las capas de cascada deciden qué conjunto de reglas gana sin subir la especificidad. La página de MDN sobre capas (en inglés) afirma que la primera capa declarada tiene la prioridad más baja y la última la más alta. La misma página afirma que una declaración normal fuera de capa sobrescribe una declaración normal en capa, y que una declaración importante invierte ese orden.

Las container queries estilizan un elemento por el tamaño de su contenedor, y MDN las presenta como alternativa a las media queries. Una tarjeta se adapta dentro de una barra lateral angosta sin breakpoint de viewport.

Qué pasa cuando entra gente nueva al equipo

En el camino utilitario la persona nueva lee el HTML y ve los valores. La convención la impone el build, porque la documentación de Tailwind avisa (en inglés) que un nombre de clase armado por concatenación no se detecta. El nombre completo se vuelve una regla que la herramienta verifica.

En el camino de tokens la persona nueva lee la hoja de estilo y el archivo de tokens. La convención la impone la revisión, y nada bloquea un padding: 13px suelto.

Aquí cómo es el equipo pesa más que el gusto. Un equipo grande con rotación gana la regla gratis en el camino utilitario, y esa exigencia es la heurística de consistencia. Nielsen Norman Group la enuncia como una de las diez (en inglés): la persona no debería preguntarse si dos pantallas significan lo mismo.

Un equipo chico con un dueño del design system la gana en el archivo de tokens.

Qué cobra cada camino en mantenimiento

El camino utilitario cobra en verborragia en el HTML, en retrabajo cuando cambia la escala y en un paso de build. La ganancia documentada es tamaño. Tailwind afirma (en inglés) que generar CSS a partir de las clases en uso mantiene la hoja lo más chica posible.

El camino de tokens cobra en nomenclatura y en poda. La página de performance de MDN (en inglés) afirma que todo estilo se interpreta, se use o no en el layout y en el pintado. La misma página afirma que un selector complejo aumenta el tamaño del archivo y el tiempo de parsing. También dice que el CSS bloquea el render hasta que el navegador decide que lo necesita.

Una regla sin uso que nadie borra sigue en ese camino crítico. Es la cuenta que paga, una y otra vez, una hoja que solo crece.

El camino del medio cobra una decisión extra por componente, y lo trato abajo.

Cuándo gana el framework utilitario

El framework utilitario gana en cuatro situaciones, y son comunes como para nombrarlas.

Equipo grande con rotación alta, donde la regla no puede depender de quién escribió el archivo.
Muchas pantallas parecidas armadas con el mismo conjunto chico de componentes.
Plazo corto, donde la convención de nombres es un costo que el equipo no paga ahora.
Producto cuyo diseño cambia poco, así que la escala se mantiene estable.

Lo que se ahorra son decisiones, no bytes. El framework fija los valores disponibles y quien escribe el HTML elige uno. Eso ahorra de verdad cuando veinte personas tocan la misma interfaz.

Ese ahorro tiene precio. Lo pagas en HTML que esconde el valor y en una hoja que no se lee como documento de diseño.

El camino del medio: CSS nativo con tokens y capas

Casi toda comparación se detiene en dos opciones. La tercera es una hoja organizada por token y por capa.

El archivo de tokens guarda las escalas: color, espacio, tipografía, radio y sombra. La variable de CSS le da nombre a cada paso.

En la definición de Nielsen Norman Group (en inglés), un design system reúne los estándares que permiten gestionar diseño a escala. En CSS, esos estándares se vuelven valores en el archivo de tokens, y el componente los lee de ahí.

Las capas guardan el orden: tokens, base, componentes, utilidades. MDN registra que la primera capa declarada tiene la prioridad más baja y la última la más alta, y que la prioridad se invierte en las declaraciones marcadas como importantes.

Las container queries resuelven el componente que tiene que adaptarse a su propio espacio, no al viewport.

El costo es una convención tuya y una revisión que la sostiene. La ganancia es un cambio de diseño que toca un archivo y un HTML que sigue legible.

Cómo decidir sin cambiar de camino cada dos años

Decide pensando en quién es dueño del valor, no en el framework de moda.

Si el equipo no logra imponer una convención de nombres, quédate con el framework utilitario.
Si una persona es dueña del design system y las escalas cambian seguido, quédate con tokens.
Si el producto tiene decenas de pantallas con estado compartido, la pregunta de CSS es secundaria.
Si el sitio es contenido, los dos caminos cuestan más de lo que las páginas merecen.

Después escribe la decisión. Una regla que puedes señalar sobrevive a una persona nueva y a una moda nueva.

Cambia cuando cambie la realidad del equipo, no porque salió una charla nueva. Tamaño del equipo, rotación, cantidad de pantallas y velocidad de diseño son las entradas. Cuando una se mueve, revisa la elección.

Dónde las fuentes discrepan

Nielsen Norman Group tira para dos lados en el uso del color. El artículo de jerarquía visual (en inglés) manda usar color vivo y saturado en los ítems importantes y color menos saturado en los ítems de menor importancia. El artículo de paneles y gráficos (en inglés) prohíbe el mismo movimiento, porque las personas no perciben los colores en un orden, así que el color no debe cargar magnitud.

Las dos reglas valen cuando el objeto cambia. Una página usa color para marcar dónde mirar primero. Un gráfico usa color para marcar cuánto, y esa lectura necesita un canal ordenado. Un design system que mantiene una escala de color para los dos trabajos hereda el conflicto.

Los otros dos artículos coinciden entre sí. La heurística de consistencia (en inglés) pide que el mismo elemento signifique lo mismo entre pantallas. El artículo de design system (en inglés) pide que el equipo sostenga un conjunto de estándares para componentes y patrones. Los dos describen el problema que resuelve un archivo de tokens. Ninguno dice si el token debe ser un nombre de clase o una variable de CSS.

Verifica antes de llamarlo decidido

Mide los bytes de CSS que carga la página y la parte que la página usa.
Busca en la hoja valores crudos que deberían ser token, como color en hexadecimal y espacio en píxeles.
Cambia un token y cuenta cuántos archivos cambian.
Lee una pantalla escrita por otra persona y mira si la regla es obvia.
Confirma que el build falla cuando el nombre de clase se arma por concatenación.
Revisa después de un trimestre, porque el equipo y el producto se mueven.

El framework no cobra en bytes. Cobra en las decisiones que sigues tomando. El CSS nativo con tokens cobra en disciplina que alguien tiene que sostener. Elige cuál de esas cuentas va a pagar tu equipo.