TDC BH | FRONT-END: As diversas formas do css moderno

Jul / 2019Front EndUriell Viana

Quem possui alguma experiência trabalhando com CSS, provavelmente já teve dificuldade para atingir um resultado esperado, ou se frustrou pra fazer alguma coisa. Até aqui, nada fora do comum.

No início, eu me relacionava bastante com o gif. do Family Guy (slide 2 da minha apresentação, disponível no final desse post), porque eu via a ação como "tentativa e erro", até que aquele monte de regras de CSS que eu atolei na classe resulte no esperado.

Hoje, na minha opinião, é fácil trabalhar com CSS. Seja você quem for.

Nos preocupamos muito mais com o resultado final do que pensando em como escrever um bom CSS, e isso, vindo da popularização de padrões na linguagem.

Voltando no tempo, quando não havia toda essa facilidade de trabalhar com CSS, o único jeito de personalizar nossa página era pelo próprio HTML. E com isso, tínhamos tags específicas pra controlar a aparência, como layout ou fonte.

O Internet Explorer 5.5 eventualmente surgiu interpretando a primeira versão do CSS. E na época, poucos sites adotaram o CSS, porque já estavam estabelecidos usando HTML, e a maioria dos "Webmasters" não tinham migrado ainda. Alguns sites confiaram na tecnologia, tipo Wired e ESPN. E foi mais ou menos assim que folhas de estilo viraram a norma.

Só que, alguns dos problemas da época, acontecem até hoje. Listei três dos maiores problemas que temos hoje em dia pra aplicar o CSS num site, afetando aplicações de pequena a grande escala:

  • Namespace global, então classes definidas numa folha de estilo, necessariamente podem ser utilizadas globalmente no nosso HTML. Em alguns casos isso é a nossa intenção, e em outros casos não é. Não temos muito controle sobre isso;
  • Arquivos muito grandes, então rapidamente nossos estilos crescem em tamanho, ou importamos outros estilos que já têm um tamanho considerável. E isso é sempre relevante quando estamos falando da web, onde nosso usuário pode ter conexões ou dispositivos muito lentos;
  • Isolamento, em parte isso se enquadra no namespace global, mas se trata da modularização dos nossos estilos. Numa página do seu site você pode precisar de 80% dos estilos declarados, mas em outra você só usa 20%.

Como os problemas para aplicar o CSS num site foram resolvidos?

Existem várias propostas para atacar estes problemas, então vamos explorar algumas.

Algumas metodologias surgiram pra auxiliar na estrutura, organização, e também como propostas que atacariam o namespace global e o isolamento. São frequentemente aplicadas em conjunto, e são essenciais para construir aplicações de grande escala com alta qualidade.

  • SMACSS: Se trata de um guia de boas práticas pra uma estrutura modular e escalável;
  • OOCSS: Valoriza o princípio de responsabilidade única e que a estrutura se separa da aparência;
  • BEM: Estrutura simples e robusta que atende o isolamento com escopo controlado.

Além dessas metodologias, a necessidade de fazer MORE with LESS 😎

Listei os três pré-processadores mais populares hoje em dia, porém o SASS tem se mostrado mais consolidado no mercado. Os três chegam essencialmente no mesmo resultado: estender a sintaxe do CSS.

Com isso veio o hype de variáveis, aninhamento, mixins e funções. Mas nós acabamos duplicando código.

Vamos ver um exemplo demonstrando que não é tão simples:

Temos o seguinte HTML estruturado com o BEM (slide 14): Uma tabela com cabeçalho e 2 linhas de corpo.

E o seguinte CSS para acompanhar, foi escrito na sintaxe do SCSS, aproveitando das regras aninhadas (slide 15).

Consegue identificar algum problema? Esse é o CSS gerado pelo SASS, dá pra ver que com uma regra aninhando outras conseguimos duplicar desnecessariamente a classe Table, que se a estrutura BEM fosse seguida, não teríamos nenhum problema com o namespace global (slide 16).

Agora imagine com muito mais regras aninhadas.

Logo, precisamos reduzir nossos estilos.

  • PurgeCSS: Remoção de código não utilizado.
  • Stylelint: Análise estática de código. Indica potenciais problemas.
  • PostCSS: Um mundo de transformações e plugins pra estender seu CSS.

Aqui temos alguns exemplos de pós-processamento que podemos fazer com nosso CSS. Recomendo que você explore o ecossistema de plugins que o PostCSS oferece, pois é tudo muito poderoso e as possibilidades são inúmeras. Mas use com moderação.

Mas então, metodologias, pré e pós processadores resolveram os três problemas, certo?

Sim. Mas e na prática?

Tenho alguns exemplos de como o CSS é aplicado em algumas frameworks modernas. O Angular por exemplo não introduz nenhuma aplicação muito diferente do padrão. Já o Vue (slide 21):

O Vue traz uma proposta que todo o código relacionado ao seu componente, reside no arquivo .vue, então os estilos, javascript e estrutura do HTML ficam no mesmo arquivo.

O React, implementa os estilos "em linha" em forma de objeto, o que facilita na hora de personalizar baseado em uma variável ou comportamento. Mas estilos em linha não são uma boa prática (slide 22).

Trazendo mais pro lado do React, o que é mais popular? Listei três maneiras comuns de se aplicar o CSS em frameworks.

  • O JSS, interpreta os estilos declarados em objeto e estende as funcionalidades dele, permitindo comportamentos de hover e até estender outro estilo. Ele gera classnames a partir dos objetos e podemos passar pros nossos elementos;
  • O CSS Modules, que tem uma proposta bem parecida, gerando os classnames automaticamente, mas escrevemos os estilos em arquivos .css separados do javascript. Então quando importamos o arquivo, ele processa o import pra gerar os classnames; e
  • Voltado pra proposta inicial do JSS e do Vue, a gente tem o CSS in JS, que em resumo é estilo escrito dentro dos arquivos javascript. E tem esse compilado muito bem feito de todas as implementações de CSS in JS nesse repositório, entra até nas diferenças de implementações de cada um (slide 26).

No exemplo (slide 27), eu usei o Styled Components, uma das bibliotecas mais conhecidas do CSS in JS pra definir um componente de botão, onde ele pode ser quadrado ou arredondado dependendo de uma prop.

Além dos dois, temos também uma opção mais diferente, o CSS Funcional. Ele parte um pouco da metodologia do CSS Atômico, que eu optei por não mencionar antes. Em outro exemplo (slide 28), a gente tem um button e um input, os dois tem uma cor de texto igual. Mas pense que isso pode virar um padrão na minha aplicação. Quantas vezes eu vou ter que declarar a mesma regra de CSS?

O CSS Funcional, ou Atômico, escolhe tratar esse problema com classes de propósito único.

O próximo exemplo (slide 29), é algo bem diferente do que estamos acostumados, então abram a mente pra algo novo.

Nele (slide 30) temos classes que definem aspectos específicos e individuais da aparência do meu elemento, só que no estilo, a declaração é apenas uma.

Numa aplicação grande onde você tem padrões visuais parecidos, essa metodologia reduziria drasticamente o tamanho do CSS final que seu site utilizaria.

A desvantagem é que a legibilidade das suas classes é prejudicada.

Dessas três propostas, posso afirmar que uma é melhor que a outra, já que são diferentes e podem ser usadas em conjunto também.

Combinei o poder do styled components que nos entrega componentes que já podemos utilizar, com o css funcional, pra reduzir a quantidade de CSS escrito. E ainda posso usar todas as funcionalidades de composição de componentes do styled components (slide 32).

Esse é um exemplo simples de aplicação que mostra como todas essas formas são flexíveis de mexer.

Olhando pra trás, cobrimos um monte de conteúdo, mas qual foi o ganho real?

  • Atacamos três dos maiores problemas em qualquer aplicação;
  • Conhecemos a maioria das soluções relevantes no mercado pra CSS;
  • Descobrimos alguns prós, contras e pontos de atenção na hora de aplicar.

Ainda que essa apresentação tenha um tom um pouco superficial, a intenção é encorajar mais profissionais a buscarem novas opções e entender como elas funcionam, para o desenvolvimento não virar mão única, onde o código que escrevemos vira algo completamente diferente, e que só voltamos a olhar quando dá problema em produção.

Se você quiser explorar mais das soluções que listei acima, eu incluí alguns links nos slides da apresentação.

Confira abaixo o conteúdo da palestra do Uriell Viana, desenvolvedor na Dito, apresentado na trilha de front-end e no palco principal do primeiro TDC BH:

Uriell Viana

Uriell Viana

Software Engineer