Utility First, Components After

• A menudo se piensa que la metodología utility-first en CSS, como Tailwind CSS, consiste en colgar un montón de clases en el HTML.

• Pero eso es solo la apariencia superficial; el núcleo de utility-first es el problema de cuándo componer componentes.

• Los métodos populares en los primeros días de CSS terminaron provocando una pesadilla de mantenimiento.

• La corriente de OOCSS intentó resolver el problema mediante la composición con componentes. La reutilización mejoró, pero se topó con la dificultad de definir el alcance de los componentes.

• Los componentes existen para la reutilización, pero el problema es que no podemos saber de antemano qué será reutilizable en el futuro.

• La corriente de Atomic CSS intentó resolverlo asignando una sola clase a una sola propiedad. La velocidad de desarrollo inicial mejoró, pero reaparecieron los problemas de mantenibilidad.

• La fuente única de verdad (Single Source of Truth) se rompe con demasiada facilidad: se termina dependiendo de buscar y reemplazar en todo el proyecto (depender de plantillas externas es engorroso y tiene límites).

• Utility-first, a diferencia de Atomic CSS, sí valora los componentes. Y, a diferencia de OOCSS, comienza con utilidades. Los componentes pueden componerse cuando realmente hacen falta.

• Cambia la pregunta de “qué debería convertirse en componente” por la de “cuándo debería convertirse en componente”.

• Es decir, utility-first debe entenderse como una síntesis que integra, hereda y desarrolla ambos enfoques.

• Por eso, en la metodología utility-first, los componentes deberían enfatizarse más. No se trata de “permitimos componentes”, sino de “maximizamos la reutilización posponiendo los componentes hasta el momento en que de verdad se necesitan”.

[nemorize]

Lo leí con gusto.

[mytory]

Gracias :)