Executando verificação de segurança...
3

Em defesa dos frameworks

Entendo sua dor, e não é questão de inteligência. Mas quero falar em defesa dos Frameworks.

Frameworks são ferramentas criadas para solucionar dores que alguém já teve no passado. Escrever CSS manualmente é poderoso e flexível, mas tem alguns problemas relacionados à produtividade ou a dificuldade que algumas pessoas tem para "deixar a interface bonita".

Por vários anos fui defensor de evitar ferramentas externas, mas com o passar do tempo fui me rendendo e vou te dizer alguns pontos que me fizeram mudar de ideia:

Dificuldade para excluir código

Para mim, esse é um dos problemas mais críticos, principalmente em bases de código grande. Quando você precisa excluir alguma parte do código, seja qual for o motivo, inevitavelmente vai acabar deixando algum seletor do CSS.

Outros membros da equipe podem ficar com medo de excluir seletores por não saber se estão sendo utilizados em outra parte do código e a bagunça tende a se acumular.

Inconsistência de navegadores

Ter que adicionar prefixos como webkit ou moz para resolver pequenas diferenças não só é chato como as vezes pode consumir mais tempo do que o esperado.

Muitos frameworks possuem uma camada de reset. (Obs.: Você também pode utilizar ferramentas como PostCSS, ou copiar uma folha de estilos reset padrão. Mas frameworks podem agilizar isso para você)

Especificidade de seletores

Se você tentar deixar o HTML o mais "limpo" possível, vai criar diversos seletores de elemento (p, li, section, etc). Dessa forma vai acabar com seletores do tipo #contact-section ul > li, o que fica uma bagunça na especificidade. (Obs.: Hoje em dia temos :where(), mas ainda pode-se causar problemas se descuidar)

Frameworks normalmente possuem seletores exclusivos de class ou attribute, o que torna sua especificidade muito mais fácil de entender e debugar.

Repetição

Quando você é o autor do CSS e não quer "sujar" o HTML com muitas classes, vai acabar repetindo muitas vezes os mesmos estilos. Por exemplo:

.button {
   padding-inline: 1.5rem;
   background-color: var(--primary-color);
   ...
}

.nav-link {
  padding-inline: 1.5rem;
  ...
}

.featured-section {
  background-color: var(--primary-color);
  ...
}

Até mesmo em landing pages pequenas você acaba se repetindo várias e várias vezes. Mesmo que isso não impacte muito no carregamento da página para seu usuário, pequenas mudanças podem ser chatas de implantar, mesmo recorrendo às custom properties (CSS var).

Frameworks que possuem classes utilitárias não tem esse problema. Você polui o HTML, mas seus estilos ficam extremamente fáceis de atualizar, pois são centralizados.

Estética

Especificamente para mim não é um problema. Sou designer de formação e consigo "deixar o site bonito" sozinho, inclusive prefiro customizar todo o estilo. Mas essa não é uma realidade para muitos desenvolvedores.

Vários frameworks (Bootstrap, Daisy-UI, Bulma, Materialize, etc.) são formados por componentes pré-estilizados. Isso pode ser um facilitador absurdo para quem tem dificuldades para criar os estilos sozinho. Graças à ferramentas como essas algumas pessoas puderam finalizar seu projeto sem deixá-lo horrível.


Não existe fórmula mágica. Mas não devemos fechar os olhos para ferramentas existentes no mercado. Elas não existem por acaso e a atitude mais inteligente é se manter informado e tomar decisões acertivas para o projeto.

P.S.: Hoje em dia utilizo Tailwind CSS em praticamente todos os projetos. Mas já vi benefício em vários outros.

Carregando publicação patrocinada...
1

eu substituí justamente o Styled Components pelo Tailwind justamente por isso no início, depois vi as outras vantagens e fica até mais legível e interessante (e isso vem desde Bootstrap) nomear as classes pelos comportamentos ou ações. isso, mal comparado, lembra o princípio de responsabilidade única do SOLID.

acostumei a "entulhar" de classes, mas sabendo o que ela faz só de ver a nomenclatura