Os Web Components tinham muito potencial para capacitar o HTML para fazer mais e tornar o desenvolvimento da web mais acessível para não programadores e mais fácil para os programadores. Lembra como era empolgante toda vez que tínhamos novos elementos HTML brilhantes que realmente fazem as coisas ? Lembra como foi emocionante poder fazer controles deslizantes, seletores de cores, diálogos, widgets de divulgação diretamente no HTML, sem ter que incluir nenhuma biblioteca de widgets?
A promessa dos Web Components era que obteríamos essa conveniência, mas para uma gama muito mais ampla de elementos HTML, desenvolvidos muito mais rápido, já que ninguém precisa esperar pelo processo completo de especificação + implementação. Apenas incluiríamos um script e, bum, temos mais elementos à nossa disposição!
Ou, essa era a ideia. Em algum lugar ao longo do caminho, o espaço foi inundado por aficionados de frameworks JS, que se deleitam com APIs complexas, processos de construção sobredimensionados e gráficos de dependência que parecem as raízes de uma figueira-da-índia.
Ler os componentes em webcomponents.org me deixa ansioso e me sinto perfeitamente à vontade para escrever JS – eu trabalho para escrever JS! Que esperança têm aqueles que não sabem escrever JS? O uso de um elemento personalizado do diretório geralmente precisa ser precedido por um ritual de npm flugelhorn, import clownshoes, build quux, tudo completamente sem desculpas porque “aqui está meu caminhão de dependências, sim, o quê”. Muitas etapas são até omitidas, provavelmente por serem “óbvias”. Freqüentemente, você percorre o labirinto apenas para descobrir que o componente não funciona mais ou não é adequado para o seu propósito.
Além da configuração, o principal problema é que o HTML não é tratado com o devido respeito no design desses componentes. Eles não são projetados o mais próximo possível dos elementos HTML padrão, mas esperam que JS seja escrito para eles fazerem qualquer coisa. O HTML é simplesmente tratado como uma abreviação, ou pior, apenas como um marcador para indicar onde o elemento vai no DOM, com todos os parâmetros passados via JS. Lembro-me de uma palestra maravilhosa de Jeremy Keith alguns anos atrás sobre esse mesmo fenômeno, onde ele discutiu essa demonstração de componentes da Web para e-shop pelo Google , que é o garoto-propaganda dessa prática. Este é o conteúdo completo de seu <body>elemento:
<body>
<shop-app unresolved="">SHOP</shop-app>
<script src="node_assets/@webcomponents/webcomponentsjs/webcomponents-loader.js"></script>
<script type="module" src="src/shop-app.js"></script>
<script>window.performance&&performance.mark&&performance.mark("index.html");</script>
</body>Se é assim que o Google está liderando o caminho, como podemos esperar que contribuidores projetem componentes que sigam as convenções HTML estabelecidas?
Jeremy criticou essa prática sob o aspecto da compatibilidade com versões anteriores: quando o JS está quebrado ou não habilitado, ou o navegador não oferece suporte para Web Components, todo o site fica em branco. Embora essa seja realmente uma preocupação séria, minha principal preocupação é a usabilidade : HTML é uma barreira inferior para o idioma de entrada . Muito mais pessoas podem escrever HTML do que JS. Mesmo para aqueles que eventualmente escrevem JS, isso geralmente ocorre após passar anos escrevendo HTML e CSS.
Se os componentes são projetados de uma forma que requer JS, isso exclui milhares de pessoas de usá-los. E mesmo para aqueles que podem escrever JS, HTML é geralmente mais fácil: você não vê muitas pessoas rolando seus próprios controles deslizantes ou usando os baseados em JS uma vez que se tornou amplamente suportado, certo?<input type="range">
Mesmo quando JS é inevitável, não é preto e branco. Um elemento HTML bem projetado pode reduzir a quantidade e a complexidade de JS necessárias ao mínimo. Pense no elemento: ele geralmente requer * algum * JS, mas geralmente é um JS bastante simples. Da mesma forma, o elemento é perfeitamente utilizável apenas escrevendo HTML e tem uma API JS abrangente para quem deseja fazer coisas personalizadas sofisticadas.<dialog><video>
Outro dia, eu estava procurando um componente de guias simples e sem dependências. Você sabe, o exemplo canônico de algo que é fácil de fazer com Web Components, o exemplo que 50% dos tutoriais mencionam. Eu nem me importava com a aparência, era para uma interface de teste. Eu só queria algo que fosse pequeno e funcionasse como um elemento HTML normal. No entanto, foi tão difícil que acabei escrevendo o meu!
Podemos consertar isso?
Não tenho certeza se isso é um problema de design ou de documentação. Talvez, para muitos desses componentes da web, haja maneiras mais fáceis de usá-los. Talvez existam componentes da web simples que eu simplesmente não consigo encontrar. Talvez eu esteja procurando no lugar errado e haja outro diretório em algum lugar com objetivos diferentes e um público-alvo diferente.
Mas se não, e se eu não estiver sozinho nesse sentimento, precisamos de um diretório de componentes da web com critérios de inclusão rígidos:
- Plug and play. Sem dependências, sem configuração além de incluir uma
<script>tag. Se uma dependência for absolutamente necessária (por exemplo, em um componente de mapa não faz sentido desenhar seus próprios mapas), o componente o carrega automaticamente se ainda não estiver carregado. - A sintaxe e a API seguem convenções estabelecidas por elementos HTML integrados e tudo o que pode ser feito sem o usuário do componente escrever JS, é possível sem JS, de acordo com o princípio W3C de menor poder .
- Acessível por padrão por meio de padrões ARIA sensíveis, assim como os elementos HTML normais.
- Temível por meio de herança seletiva e propriedades personalizadas. Estilo mínimo por padrão. As propriedades CSS normais devem “funcionar” na medida do possível.
::part() - Apenas um componente de um determinado tipo no diretório, que é flexível e extensível e continuamente iterado e aprimorado pela comunidade. Não são 30 controles deslizantes diferentes e 15 guias diferentes que os usuários precisam percorrer. Sem marca, sem silos de “bibliotecas de componentes”. Apenas elementos projetados o mais próximo possível do que um navegador implementaria de todas as maneiras que a tecnologia atual permite.
Eu estaria pronto para trabalhar nisso se outros pensassem da mesma forma, já que esse não é um projeto para uma pessoa abordar. Quem está comigo?