Cenário de Web Components em 2020

[felipefialho]

Aproveitando o gancho da issue #1691 e pegando de carona o que já foi discutido na #1224 (de 2018), quero trazer de novo essa discussão aqui.

Sabemos que boa parte dos browsers atuais dão bom suporte para Custom Elements e que existem N formas de gerar Web Components atualmente (Oi, Svelte).

Mas também sabemos que a renderização para SSR ainda é um pouco obscura e necessita de algumas intervenções para funcionar.

A principal vantagem seria ser agnóstico com relação ao framework utilizado, portanto um DS usando Web Components, funcionaria com tranquilidade em projetos utilizando frameworks diferentes, esse é o cenário de muitas empresas que por vezes tem projetos legados (ou não), rodando em tecnologias diferentes. Isso inclusive garante um "envelhecimento" melhor dos componentes no decorrer dos anos.

Afinal, pra vocês, qual o cenário de Web Components em 2020?

[yanmagale]

Penso que seja bem isso mesmo ....

Acredito que o próximo passo seja a geração/suporte dos Web Components com as ferramentas atuais - https://custom-elements-everywhere.com/, e com isso podermos utilizar estes components com tudo o que aquela lib/ecossistema oferece

[joaopavila]

Aproveitando o gancho da issue #1691 e pegando de carona o que já foi discutido na #1224 (de 2018), quero trazer de novo essa discussão aqui.

Sabemos que boa parte dos browsers atuais dão bom suporte para Custom Elements e que existem N formas de gerar Web Components atualmente (Oi, Svelte).

Mas também sabemos que a renderização para SSR ainda é um pouco obscura e necessita de algumas intervenções para funcionar.

A principal vantagem seria ser agnóstico com relação ao framework utilizado, portanto um DS usando Web Components, funcionaria com tranquilidade em projetos utilizando frameworks diferentes, esse é o cenário de muitas empresas que por vezes tem projetos legados (ou não), rodando em tecnologias diferentes. Isso inclusive garante um "envelhecimento" melhor dos componentes no decorrer dos anos.

Afinal, pra vocês, qual o cenário de Web Components em 2020?

Mas se fizer um Design system usando svelte por exemplo, deixaria de ser um DS não? Aí entraria no caso de ser uma LIB por exemplo.

Acredito que web components ainda não é a bala de prata pra fazer libs para serem agnósticas a frameworks. Se for pra fazer algo pequeno e não demande esforço tudo bem, mas agora fazer uma LIB grande, não sei se é viável.

Acho que o hype do momento para web components é o Svelte, porém estava dando uma olhada no polymer esses dias também que me chamou bastante atenção e é mais "sólido" do que o svelte. Então vale a pena dar uma olhada também.

[vhfmag]

Concordo sobre DSs serem uma excelente aplicação e sobre SSR ser uma das principais limitações pra que isso esteja mais difundido (junto com o fato de React até hoje não ter suporte 🙄). Existem soluções pra SSR de WCs específicas pra frameworks e bibliotecas específicas (polymer, stencil, etc), mas isso mata a ideia de ser vanilla e universal.

Mas ainda acho que a principal aplicação de WCs é em experimentação de novos padrões pro HTML. Queremos um componente padrão para abas, mapas, tooltips, internacionalização ou um equivalente de picture pra vídeos (escolha de src de acordo com media query)? Tudo começa com um WC.

Quem tem feito um bom trabalho de estudo e experimentação nisso é a Microsoft, que tem um projeto conjunto com a Google onde eles mapeiam as deficiências dos componentes atuais e o que simplesmente ainda não existe, mas eu não consigo achar de jeito nenhum o site ou o repositório 😕

---

Edit: ACHEI! https://open-ui.org/

[afonsopacifer]

Invoco a @LarissaAbreu, que acabou de migrar todos os web components da empresa (que são open source) p usar full JS (sem HTML imports que foi descontinuado em favor de ESmodules no browser) ❤️

[afonsopacifer]

Concordo sobre DSs serem uma excelente aplicação e sobre SSR ser uma das principais limitações pra que isso esteja mais difundido (junto com o fato de React até hoje não ter suporte 🙄). Existem soluções pra SSR de WCs específicas pra frameworks e bibliotecas específicas (polymer, stencil, etc), mas isso mata a ideia de ser vanilla e universal.

Mas ainda acho que a principal aplicação de WCs é em experimentação de novos padrões pro HTML. Queremos um componente padrão para abas, mapas, tooltips, internacionalização ou um equivalente de picture pra vídeos (escolha de src de acordo com media query)? Tudo começa com um WC.

Quem tem feito um bom trabalho de estudo e experimentação nisso é a Microsoft, que tem um projeto conjunto com a Google onde eles mapeiam as deficiências dos componentes atuais e o que simplesmente ainda não existe, mas eu não consigo achar de jeito nenhum o site ou o repositório 😕

Edit: ACHEI! https://open-ui.org/

Sobre React, aqui na empresa usamos Web components feitos com Polymer (rodando como elementos HTML nativos) sendo renderizados a partir do JSX com React... tudo normalmente..

PS: A única diferença é que usamos class ao invés de className quando renderizamos um Web Component a partir JSX.

[felipefialho]

@afonsopacifer Na experiência de vocês:

• Chegaram a usar com SSR? Tiveram problemas nesse sentido?
• A implementação e comunicação das props do React com do Web Component rolou tranquilo ou tiveram que fazer muitas modificações?
• Usaria uma solução diferente de Polymer hoje, como Svelte ou Stencil?

[afonsopacifer]

@afonsopacifer Na experiência de vocês:

• Chegaram a usar com SSR? Tiveram problemas nesse sentido?
• A implementação e comunicação das props do React com do Web Component rolou tranquilo ou tiveram que fazer muitas modificações?
• Usaria uma solução diferente de Polymer hoje, como Svelte ou Stencil?

• Nao usamos SSR, mas teoricamente não faz diferença, pq injetar um web component como string da no mesmo que um HTML normal (a partir do momento que o custom element está disponível no escopo do browser)

• props rola normal, da no mesmo que usar um tag HTML qualquer.

• Polymer é tranquilo, principalmente a partir da versão 3.x, funciona muito bem.. mas o Google sugere a partir de agora usar o lit-elements por ser mais leve (não testei).

A Lari me mandou aqui uma foto da arquitetura que usamos para compor o design system da empresa:

Coisas comuns (independente do app/produtos) são web components, já as camadas mais específicas do produto são React (p aproveitar o ecosystema).. Cada componente é um projeto separado com seus testes e arquitetura própria (temos um generator p scaffolding)... Ao mudar a tecnologia em um novo produto, reaproveitamos uma ca%$#$@ de coisas se mantendo na plataforma, sem depender da Lib do momento.

[eliseumds]

@afonsopacifer o ponto de fazer SSR é justamente pra que crawlers não precisem simular um browser. Suponhamos que você tenha um componente que renderize um Review:

<consumer-review title="..." body="..."></consumer-review>

O Google não vai conseguir ler o conteúdo da shadow root que consumer-review gera porque ele só tem acesso a uma grande string que é source code da página. Podemos argumentar que é possível fazer pre-rendering, mas essas coisas não funcionam bem com sites dinâmicos. E eu nunca vi um site relevante nas buscas fazendo somente client-side rendering.

[wilsongomes-swe]

@eliseumds quando se refere a "essas coisas não funcionam bem", se refere ao pre-rendering de web components ou a pre-rendering geral (Next / Nuxt...)?

[eliseumds]

@wilsonneto-dev pre-rendering é viável pra páginas estáticas ou até dinâmicas mas sem muitas variações, do contrário fica muito caro e complexo.

[afonsopacifer]

@afonsopacifer o ponto de fazer SSR é justamente pra que crawlers não precisem simular um browser. Suponhamos que você tenha um componente que renderize um Review:

<consumer-review title="..." body="..."></consumer-review>

O Google não vai conseguir ler o conteúdo da shadow root que consumer-review gera porque ele só tem acesso a uma grande string que é source code da página. Podemos argumentar que é possível fazer pre-rendering, mas essas coisas não funcionam bem com sites dinâmicos. E eu nunca vi um site relevante nas buscas fazendo somente client-side rendering.

Saquei! Mas quando a string é entregue, o browser tem que parsear o HTML estatico certo? Se o web component estiver na string, ele vai ser renderizado normalmente... Claro que as lógicas dentro do componente não vão passar pelo SSR... mas seila... é que aqui na empresa nós pensamos em um web component como um elemento nativo HTML... então, como não faz sentido renderizar o shadow dom dentro da tag video (SSR), para nós tbm não faz sentido renderizar o shadow dom do webcomponent... Mas seila hahaha

[raisiqueira]

@afonsopacifer Já que vcs estão migrando para Polymer 3 e a recomendação da própria comunidade é migrar para Lit Element, pq não migraram direto para Lit Element?

[LarissaAbreu]

@raisiqueira a recomendação é que para projetos novos seja utilizado o Lit Element por ele ser mais leve e mais rápido que o Polymer...

Como os nossos web components já estavam feitos com Polymer 2 eu decidi apenas fazer a migração para Polymer 3 mesmo já que no nosso caso a diferença seria mímina.

[felipefialho]

@LarissaAbreu E o Stencil, chegaram a considerar ele?

[LarissaAbreu]

@LarissaAbreu E o Stencil, chegaram a considerar ele?

É uma coisa que ainda está na nossa lista para ver como funciona direitinho para poder considerar utilizá-lo... Na nossa lista tem o Stencil e até mesmo a possibilidade de não utilizar lib nenhuma para criar os nossos componentes rs

[juliovedovatto]

Meses depois, passo aqui pra dizer que Stencil não é uma boa escolha.

Tive experiência de 8 meses de desenvolvimento com eles e cheguei a conclusão que a Ionic não sabe o que está fazendo direito.

Listo alguns problemas aqui:

• Quase toda semana um release, o que fica difícil de acompanhar.
• Algumas dessas mudanças causam breaking change e side-effects. Eles resolvem um problema, mas acabam criando problema diferente pra outra pessoa que fez algo diferente.
• Falta de suporte do fórum. Se ver os issues, boa parte os mantenedores nem respondem. Ou demoram pra dar feedback.
• Integração com outros frameworks é meio problemática. Dificil manter reatividade de componente integrado com Vue ou React. Tem que usar watchers e atualizar via DOM, o que gera um grandes trechos de código pra lidar com um web componente.
• Passar props reativas é só por string, resto tem que ser feito via DOM. Já vi gente sugerindo usar JSON.stringify e fazer JSON.parse no web component 🤦🏻‍♂️ (no caso do Vue, mas acredito que React/Angular acabe sendo mesma situação)
• Virtual DOM dele é cheio de problemas. Principalmente quando envolve <slots>
• Como ele é 100% typescript, ele gera um d.ts dos componentes que você cria. Se você importar uma definição de uma lib de terceiros que esteja usando. Esse .d.ts vai importar ela também. Problema que isso acaba dando problemas na hora de você importar seu web component pra um Vue/React. Acabei tendo que deixar pacotes @types/* como dependencies do projeto (ao invés de devDependencies)

Stencil acabou só sendo bom para por exemplo, criar um widget pra colocar em outro site (tipo aqueles embed do Spotify pra ouvir uma playlist num site). Integrar os web components gerados nele para usar em outro framework acabou não sendo bom.

Eu acho que se a Ionic decidir continuar projeto, terão que rever o Roadmap. Por enquanto, vou dar uma pausa dele e esperar. Quem sabe daqui 1 ano o cenário dele esteja diferente.