Web Components é uma Revolução?

O texto compara Web Components com formas anteriores de montar interfaces na Web e diz que a proposta melhora clareza, isolamento e reuso, mas não muda de forma disruptiva a experiência do usuário. Para o autor, a vantagem maior está no trabalho do desenvolvedor front-end, que ganha uma forma mais oficial de fazer o que antes era resolvido com gambiarras elegantes.

Fichamento

#

• Web Components não são explicados em detalhes técnicos; o artigo quer avaliar o valor da proposta no presente.
• Custom Elements tornam as tags mais claras e reduzem a ambiguidade de estruturas como tabs e widgets.
• Antes disso, era comum encapsular comportamento com classes, IDs e Javascript, como em plugins de JQuery.
• Shadow DOM serve para isolar estilos e comportamentos dentro de uma subárvore separada do DOM principal.
• O autor vê Shadow DOM como uma camada acima de HTML5 e CSS3, ainda sem consenso geral.
• Template permite ter um trecho de DOM inerte para instanciar depois com Javascript.
• O texto compara templates com Mustache, Handlebars e HTMLBars, e diz que a especificação ainda não resolve tudo o que essas bibliotecas fazem.
• HTML Imports empacotam componentes e dependências em um arquivo HTML que pode carregar outros assets.
• O autor aponta o risco de muitos imports aumentarem demais as requisições de rede com HTTP 1.1.
• Vulcanize e Emcee aparecem como tentativas de concatenar imports e reduzir a fragmentação.
• O artigo trata Web Components como uma evolução útil, mas não como algo disruptivo.
• O maior valor estaria em um pacote completo como Polymer/Paper, capaz de dar coesão ao ecossistema e atrair desenvolvedores.
• O texto liga Web Components a mudanças anteriores da Web, como DHTML, Ajax, GWT e o crescimento do Javascript no client-side.
• A conclusão é que Web Components parecem ser o próximo passo lógico da evolução dos browsers, não uma revolução isolada.