Eles estão se espalhando cada vez mais, Web Components!

Qual mudança que Web Components causa na arquitetura CSS?

Com o crescimento dos Web Components — que é a divisão de interface de usuários em pedaços de única responsabilidade de HTML, JavaScript e CSS — será que nós vamos ver uma evolução (ou revolução) em como nós escrevemos, organizamos e empacotamos CSS para os nosso web sites?

Atualmente, existem duas maneiras principais de escrever CSS: baseado em componentes e baseado em utilidades (Eu também vi esse último sendo referenciado como CSS orientado a objetos ou CSS funcional, respectivamente).


Baseado em componentes

A abordagem baseada em componente estabelece uma relação 1-para–1 entre HTML e seu seletor. Então, cria-se um padrão de estrutura e aplica-se ele ao elemento HTML.

Por exemplo, um botão codificado no CSS com uma classe .button e aplicado ao elemento HTML.

Teoricamente, há um limite para o número de padrões que você deve ter no seu site. Entretanto, é comum ver sites crescerem e adicionarem mais funcionalidades sem remover padrões antigos. Eu já vi sites com 10 anos de idade onde toda a estrutura CSS era remendada.

SMACSS se encaixa bem nesse campo.


Baseado em utilidades

Na outra ponta, temos a abordagem baseada em utilidades. Ela estabelece uma relação 1-para–1 entre seletores e propriedade CSS.

Por exemplo, um botão — consiste de um conjunto de propriedades CSS — recebe um número N de classes no HTML.

Atomic CSS se encaixa bem nesse campo.


Entre os dois mundos

É claro, que existem pessoas (quer dizer, a maioria, eu acho) que escolhem misturar essas duas abordagens juntas. Alguns usam a estrutura baseada em componentes para algumas coisas, como botões e campos de formulário, e então eles usam a estrutura de utilidades para outras coisas, como layout ou ritmo de espaçamento.


Entrega

Como esse CSS chega ao usuário final é um fator a se mencionar.

A maioria dos projetos que eu vejo por aí, adotam o plano de unificar todo o CSS do projeto e entregam apenas um arquivo, minimizado e cacheado.

Quando eu estava trabalhando no Yahoo!, o motivo de estarmos usando a abordagem baseada em componentes, é que podíamos empacotar e enviar o CSS necessário apenas para aquela página e nada mais. Apenas quando novas páginas tinham novos componentes é que o CSS para eles eram carregados. Isso era feito através de uma combinação do arquivo que era solicitado com o servidor, empacotando os arquivos individuais em um só CSS, no tempo de requisição e cacheando eles.


Web Components

Se você já chegou a dar uma olhada em Web Components, a parte anterior soou familiar.

Se um Web Component é requisitado apenas quando ele é usado, então, o CSS que se refere a ele também será carregado apenas quando ele for solicitado.

Web Component na verdade consiste de 4 tecnologias diferentes: custom elements, HTML Imports, Templates e Shadow DOM. Quando eu me refiro a Web Components nesse artigo, eu me refiro a todos eles. Se um projeto atualmente está usando HTML Import, por exemplo, ele deve usar uma estratégia diferente para empacotar e carregar componentes. O projeto pode estar empacotando tudo em apenas um arquivo, como muitos fazem hoje em dia. Nesse caso, nada do que estou falando aqui realmente se aplica.

Isso quer dizer que uma abordagem baseada em componentes nos permite localizar o CSS para determinado componente e ainda ganhamos a vantagem de performance de usar apenas o CSS que é necessário.

Muitos que estão utilizando React usam CSS Inline, estão fazendo exatamente a mesma coisa. Eles estão escrevendo CSS nos seus componentes e aquele CSS só é usado quando o componente é solicitado.

Nessa altura, você pode adivinhar, que minha abordagem (usando SMACSS) em empacotar um site usando Web Components não muda muita coisa. Alguns conceitos como convenção de nomes e namespace no CSS, irão cair no esquecimento devido ao Shadow DOM.

Para aqueles utilizando uma abordagem baseada em utilidades, eles ainda vão precisar passar por um processo de empacotamento que terminará com um arquivo de tamanho final (teoricamente) ainda grande, mas isso não é um grande problema. Cada Web Component irá solicitar apenas as propriedades CSS que ele precisa e nada mais.


Performance

Mas a dúvida ainda persiste, será que uma entrega focada em pequenas partes cria uma melhor experiência de usuário do que aquela que entrega tudo de uma vez?

Será que 240kb de CSS (usando a abordagem baseada em componentes), dividida em pequenos pedaços de 20kb solicitados multiplamente pelas páginas criam uma experiência melhor do que um único arquivo de 50kb (se utilizarmos a abordagem baseada em utilidades)?

Eu tenho visto experiências positivas e negativas com ambos os cenários. A entrega focada em pequenas partes, na verdade, depende do HTTP/2 ser mais adotado (que irá acontecer futuramente) e no geral, a melhoria de performance é boa, porém, não é necessariamente a resolução de todos os problemas. Nós iremos continuar vendo otimização na parte do servidor que irão melhorar a performance de entrega de arquivos.

(Não estou dizendo que HTTP/2 é ruim. Pelo contrário, acho que devemos atualizar o quanto antes, e esses exemplos são partes da evolução.)


Conclusão

E após tudo isso, eu acredito, que de imediato, a arquitetura CSS não irá mudar muito. Com certeza iremos ver mais conversas sobre o que deve ser definido como Web Component e o que deve ser definido fora disso. Mas, assim como React, é possível que uma abordagem completamente diferente seja criada.

É aguardar para ver!


Créditos