Há exatamente um mês, um grupo de desenvolvedores e designers qualificados se reuniram para discutir alguns dos tópicos mais interessantes relacionados ao CSS. Isso ficou conhecido como CSS Conf EU 2013 , executado em Berlim em setembro. De todas as palestras ali realizadas, uma delas foi a que mais me chamou a atenção: CSS Module System in Google+ , do engenheiro do Google Shubhie Panicker.
Em sua palestra, Shubhie afirma que CSS não é tão simples . Por exemplo, ela menciona regressões de IU , ou em outras palavras, como um estilo usado por um módulo específico pode substituir o estilo de outro em uma situação específica. Para superar isso, o Google+ usa uma arquitetura que organiza as dependências dos módulos de cada página e, em seguida, monta corretamente os módulos de uma forma que minimiza as solicitações HTTP e permite que solicitações futuras sejam o menor possível. Isso é obtido por meio das planilhas de estilo do Google Closure , bem como de outros padrões de arquitetura.
{<1>} 
<small> Para gerar os ativos adequados para suas várias páginas, a equipe do G + organiza as dependências de acordo com as necessidades de cada página e servidores apenas essas. </small>
Compilar, vincular e construir. Fácil, certo?
A primeira sensação que tive depois de assistir a maior parte da palestra de Shubhie foi de frustração . Ela estava me dizendo que o Google, uma das empresas da web mais experientes, precisava configurar uma arquitetura inteira para apenas reutilizar um monte de widgets em suas várias páginas . Ele precisava representar graficamente todo o seu sistema, com padrões, práticas e classes cuidadosamente nomeadas para evitar algo que os Desenvolvedores da Web enfrentam há anos, se não décadas . Ele teve que projetar um sistema de construção para montar e entregar CSS aos usuários finais. Devia ter namespacespara garantir que a equipe não se confundisse. Ele estava me dizendo que depois de todos esses anos, apesar do progresso do CSS da web em termos de recursos (border-radious, gradientes, flexbox, transformações, 3d), ainda precisamos lutar para sair em termos de portabilidade, encapsulamento, escalabilidade e reutilização .
Ele estava me dizendo que CSS ainda seria fácil o suficiente para convidar as pessoas a aprendê-lo, apenas para chutá-las na cara meses depois, sempre que criarem um aplicativo de tamanho médio e outras pessoas trabalharem nele.
Manuseie com cuidado
A dura realidade do CSS é que ele é apresentado como uma linguagem simples de aprender que qualquer um pode tocar e brincar, mas em escalas maiores requer conhecimento e experiência experientes em termos de arquitetura, design e escalabilidade. Em muitos lugares, ele é tratado com leviandade e não é incomum ter outras pessoas mexendo nele.
{<3>} 
<small> Github’s 2012 CSS Performance de Jon Rojan , mostrando como qualquer aplicativo de médio a grande porte está fadado a ser tocado por vários desenvolvedores </small>
Uma parte de mim (a engenharia, BS em Ciência da Computação), acha que todos deveriam tocar no CSS. Devemos ser capazes de permitir que qualquer desenvolvedor que tenha lido metade do blog de Harry e concluído um curso da Code Academy em HTML / CSS adicione sua magia, cores e marcação ao nosso aplicativo. Nem todo mundo precisa saber sobre Tipografia, Design Responsivo ou Ritmo Vertical para criar um botão e, com a quantidade de tarefas a serem realizadas, quanto mais mãos, melhor.
A outra parte de mim (aspirante a designer, leitor Sidebar.io, Forrst, Dribbble, perseguidor do Behance), pensa que estou louca . A menos que você conheça BEM, OOCSS, tenha comprado a cópia impressa do SMACSS, possa reconhecer uma fonte humanista, saiba o que “em” em CSS realmente significa e tenha uma paixão secreta por Chris Coyier <small> (Ok, isso é assustador, desculpe Chris) </small>, não deveria estar perto do CSS da empresa. Ele / ela usará id’s à vontade, escreverá seletores superqualificados, destruirá um quando não conseguir descobrir a especificidade e usará números mágicos em todos os lugares.!important
Como um engenheiro de front-end, minha responsabilidade é equilibrar os dois lados de uma equipe e saber quando escolher qual chapéu: se a qualidade do CSS está caindo, eu invisto meu tempo limpando-o, compartilhando meus insights sobre como melhorar com a equipe e a revisão do código; se os prazos são difíceis de cumprir, concentro-me nos tíquetes recebidos, o Javascript, e compartilho as tarefas com outros desenvolvedores qualificados que podem não se destacar em CSS, mas podem fazer o trabalho.
Porque no final, todo mundo quer fazer o trabalho .
Apresentando Web Components
Se você foi até agora, provavelmente percebeu que ainda não falei sobre Web Components, ainda sendo o título do post. Eu precisava apresentar o pano de fundo adequado para mostrar como os Web Components se destacam e por que acho que estamos prestes a enfrentar uma nova era no desenvolvimento da Web, uma era dos Web Components.
Os componentes da Web são incríveis . Se você está com preguiça de ler as especificações dos Web Components (não vou culpá-lo), você pode pelo menos conferir esta introdução de Eric Bidelman ( Engenheiro de Programas da Equipe do Google Chrome ) para se familiarizar com o conceito. Embora seja uma tecnologia bastante experimental, polyfills como o Polymer podem torná-lo pronto para a “produção”. A versão tl; dr dos componentes da Web é que eles permitem que o desenvolvimento do Front End seja realmente reutilizável e escalonável , envolvendo a lógica DOM em elementos escopoáveis e vinculáveis através de modelos nativos .
Os Web Components nos permitem finalmente ter widgets reutilizáveis que permitem que vários desenvolvedores trabalhem juntos em um CSS. Qualquer um pode mexer no CSS e até mesmo na marcação à medida que cria um componente que atinge o objetivo.
Não tenho certeza se isso foi feito durante a criação da especificação, mas acho esta uma das principais vantagens da tecnologia: qualquer desenvolvedor pode criar um componente específico completamente isolado um do outro . Caso isso não tenha invadido você, vou identificar o que significa:
- Isso significa que, enquanto seu componente funcionar , não importa o quão ruim ou bom ele foi escrito, porque estilos ruins não se replicarão em sua página da web. As boas práticas usuais de CSS são seguidas apenas para garantir que o novo CSS não quebre o antigo.
- Isso significa que você pode usar métricas isoladas para medir a qualidade de um componente. Por exemplo, você pode se importar menos com o que um desenvolvedor faz em seu componente, mas declare como requisito que o tamanho do componente não pode ser superior a N kbs.
- Você precisa de um trabalho específico feito? Contrate um Freelancer e peça-lhe que crie um componente para você. Basta colocar esse
<freelancer-made></freelancer-made>elemento e vê-lo fazer sua mágica. - Se o freelancer quiser, ele pode tornar os componentes responsivos. Você já viu este exemplo legal de elementos responsivos adaptáveis ? Imagine que é um componente, pronto para ser colocado onde quer que vá.
- Você já ouviu falar do Flexbox ? Agora imagine o exemplo responsivo anterior dobrando-se à sua vontade por meio da propriedade flexbox order. Coisas como coreografia de conteúdo são uma brisa.
Em termos de reutilização, os Web Components têm algo que eu previ por muitos, muitos anos: interfaces de usuário como serviço . Eu não estou falando sobre aqueles editores WYSYWYG horríveis com código desordenado, ou aqueles estranhos widgets de terceiros que forçam seus estilos em seu site. Estou falando de componentes cuidadosamente elaborados que podem ser facilmente consumidos.
Considere, por exemplo, o seguinte componente de polímero:
<polymer-element name="application-element" constructor="ApplicationElement" attributes="">
<template>
<style>
@host { :scope {display: block;} }
</style>
<span>I'm <b>application-element</b>. This is my Shadow DOM.</span>
</template>
<script>
Polymer('application-element', {
//applyAuthorStyles: true,
//resetStyleInheritance: true,
created: function() { },
enteredView: function() { },
leftView: function() { },
attributeChanged: function(attrName, oldVal, newVal) { }
});
</script>
</polymer-element>Se você perceber, dentro deste arquivo (chamado ) temos tudo o que precisamos para um componente: o CSS, o JS e o HTML (até o Shadow DOM!). Podemos então navegar por isso em nossa página principal por meio do comando.application.htmlrel=import
<!-- Place your HTML imports here -->
<link rel="import" href="elements/application.html">E em seu corpo … <application-element></application-element>
Voilá . Agora você tem um componente de elemento de aplicativo. Isso pode ser hospedado em qualquer lugar. Contanto que você habilite o CORS corretamente no servidor, você pode até fazer solicitações entre navegadores. Clique em http://jjperezaguinaga.webscript.io/checkbox para obter um Elemento de polímero de caixa de seleção se você não acredita em mim. Aqui está um Codepen do referido componente da Web armazenado em meu próprio servidor , criado por Stefan Judis .
Você percebe o poder disso? Você pode criar seus próprios componentes personalizados e cobrá-los por meio da lista de permissões de domínio. Você pode hospedá-los em seu próprio servidor e fornecer o mecanismo de montagem do Google+ apenas concatenando arquivos HTML . Caso você esteja se perguntando, os componentes podem ser habilitados para receber parâmetros, então você pode até configurá-los em tempo de execução .
Um bom exemplo é o Google Maps Web Component.
<google-maps></google-maps>Aborrecido né? Que tal isso?
<google-maps latitute="-8.034881" longitude="-34.9182"></google-maps>Esses atributos podem ser criados pelos criadores dos componentes e podem ser tão poderosos quanto você desejar. Agora, você pode estar pensando: “Bem, teremos que nos ater a qualquer estilo / design que eles configurem para o componente”
Noup .
Veja, os Web Components têm essa propriedade mágica chamada applyAuthorStyles. Se ativado, os componentes da web podem herdar seus próprios estilos. Se você for um designer de Web Components, pode incluir uma pequena documentação da marcação do componente; aderindo a convenções como o BEM , seus consumidores de componente podem definir o estilo de classes específicas para seu componente e, mesmo que seu componente possa herdar de seu autor, outros componentes não o fazem, não permitindo a substituição .
Bem vindo a nova era
{<5>}
Para os componentes que apresentei, usei o Polymer. Assim que os navegadores começarem a implementar a maioria desses padrões de navegador, isso não será mais necessário. Os navegadores implementarão todas as especificações que fazem parte dos componentes da Web, como Shadow Dom, Decoradores, Elementos personalizados, importações e modelos. Ao contrário das outras partes dos componentes da Web, os decoradores ainda não têm uma especificação; entretanto, por meio do Polymer, você pode usar a maioria dos outros recursos atuais.
Este é apenas o começo e, claro, estou bastante otimista quanto a isso. Ainda vamos criar soluções artesanais e sob medida. Por exemplo, nem todo mundo tem problemas com o Google+ ou com sua base de usuários. A solução deles também é elaborada para reduzir as solicitações de HTTP, que caem no reino da Otimização mais do que do Gerenciamento de Módulos. A abordagem dos componentes pode não funcionar logo de cara e provavelmente eles têm outras coisas em mente. Aposto que as soluções usadas no Facebook são tão complicadas quanto o Google+ ou até mais sofisticadas. Ainda precisaremos de diretrizes e revisaremos os componentes codificados inadequadamente. Precisaremos de outras arquiteturas, maneiras de revisar componentes, estruturas para montá-los.
Mas ainda assim … o futuro parece brilhante, e estou interessado no que virá a seguir. O Web Design de Brad Frost Atomic é uma metodologia CSS que ajuda designers a criar sistemas inteiros. E se pudéssemos mesclar esse tipo de metodologias e a tecnologia de Web Components para realmente começar a montar componentes reutilizáveis? E se pudéssemos criar modelos de negócios por meio de provedores UIaaS, que pudessem mostrar componentes nativos perfeitos de pixel adequados às nossas necessidades? E se alguém pudesse ganhar a vida com componentes prontos para dispositivos móveis responsivos e cuidadosamente elaborados?