Utility First, Componentes Depois

• Muitas vezes, em CSS, a metodologia utility-first como o tailwindcss é vista como algo que simplesmente pendura um monte de classes no HTML.

• Mas isso é só a aparência externa; o ponto central do utility-first é a questão do momento de compor componentes.

• Os métodos que fizeram sucesso no início da era do CSS acabaram criando um pesadelo de manutenção.

• A corrente do OOCSS tenta resolver esse problema por meio da composição de componentes. A reutilização aumentou, mas ela esbarrou no problema da dificuldade de definir o escopo dos componentes.

• Componentes existem para reutilização, mas há o problema de que não dá para saber antecipadamente o que será reutilizado no futuro.

• A corrente do Atomic CSS tenta resolver isso atribuindo apenas uma classe para cada propriedade. A velocidade de desenvolvimento inicial aumentou, mas os problemas de manutenção voltaram a aparecer.

• A Fonte Única da Verdade (Single Source of Truth) se quebra com facilidade demais — acaba-se dependendo de localizar e substituir em massa (dependência de templates externos é incômoda e tem limites).

• O utility-first, diferente do atomic, vê os componentes de forma positiva. E, diferente do OOCSS, começa pelas utilities. Os componentes podem ser compostos quando realmente forem necessários.

• Ele transforma a pergunta “o que deve virar componente?” na pergunta “quando isso deve virar componente?”.

• Ou seja, o utility-first deve ser visto como uma síntese dos dois, herdando e desenvolvendo suas ideias.

• Portanto, na metodologia utility-first, os componentes precisam ser enfatizados um pouco mais. Não deveria ser “nós permitimos componentes”, mas sim “maximizamos a reutilização ao adiar os componentes até o momento em que eles realmente forem necessários”.

[nemorize]

Gostei da leitura.

[mytory]

Obrigado :)