Web Components Eliminam o Aprisionamento a Frameworks JavaScript

Artigo original ↗ Discussão no Hacker News ↗

Web Components são apresentados como uma forma de evitar o aprisionamento a um único framework JavaScript, expondo partes da UI como elementos customizados padrão que podem ser usados em React, Vue, Angular e outros. Os comentaristas estão divididos: os defensores gostam da capacidade de encapsular componentes complexos, interativos ou de sistema de design e combiná-los com ferramentas leves como Lit, enquanto os críticos destacam limitações como ergonomia estranha, suporte fraco a SSR, problemas de estilização e acessibilidade do Shadow DOM e a necessidade de muitas especificações adicionais. Um tema recorrente é que Web Components funcionam melhor como uma camada de interoperabilidade de baixo nível ou um alvo de compilação, e não como substituto completo para frameworks de aplicação, que ainda oferecem recursos de nível mais alto como roteamento, gerenciamento de estado e templating.

Papel e promessa dos Web Components

  • Vistos como uma forma baseada em padrões de encapsular UI para que possa ser reutilizada entre frameworks (React, Vue, Angular, Svelte) ou incorporada como “ilhas” em páginas estáticas/SSR.
  • Úteis para migração gradual entre frameworks ou para encapsular um widget específico de um framework para uso em outro lugar.
  • Alguns os consideram excelentes para componentes folha, sistemas de design, widgets altamente interativos ou internamente stateful, e aplicativos simples sem etapa de build.

Limitações, lacunas e problemas do Shadow DOM

  • Muitos comentaristas consideram Web Components “meio prontos”: ergonomia estranha por si só, muitas vezes exigindo bibliotecas auxiliares (por exemplo, lit, Stencil), o que reintroduz um tipo de aprisionamento semelhante ao de frameworks.
  • Shadow DOM é especialmente controverso: difícil de estilizar de fora, dependência de ::part, dificuldade para corresponder a layouts dirigidos por designers e problemas com formulários e ARIA através das fronteiras de shadow.
  • Documentos vinculados do W3C listam muitas partes ausentes ou dolorosas (participação em formulários, acessibilidade, estilização, scoped registries, etc.), sugerindo que muitas outras especificações ainda são necessárias.
  • Alguns argumentam que Shadow DOM duplica iframes ou faz escopo de CSS de forma ruim; poucos dizem que é um erro que deveria ser redesenhado.

Relação com React e outros frameworks

  • Há amplo consenso de que Web Components são primitivas de baixo nível ou uma “ABI”, não um substituto para frameworks que lidam com roteamento, gerenciamento de estado e templating.
  • Um lado enfatiza o valor central do React: um modelo em que a UI é uma função (em sua maior parte) pura do estado da aplicação. Outro contrapõe que esse padrão é anterior ao React e que a conveniência do JSX/templating e a evangelização do Facebook foram fatores maiores.
  • Críticas ao React: pesado, superdimensionado para muitos aplicativos, complexidade dos hooks, pressupostos do virtual DOM que não combinam com navegadores modernos e silos de “especialistas em framework”.
  • Defesas do React: ecossistema maduro, forte oferta de contratação, boa história de SSR e ainda um bom equilíbrio entre poder e manutenibilidade. Alternativas (Solid, Svelte, Vue, Angular, lit) são discutidas como melhores opções em alguns aspectos.

Uso prático e melhores práticas

  • Conselho de praticantes que usam Web Components em produção:
    • Prefira-os para widgets autocontidos; não construa aplicativos inteiros com Custom Elements puros a menos que você adicione uma camada de templating.
    • Considere evitar Shadow DOM para componentes em nível de aplicativo, ou use padrões (CSS parts, template viewport, base-style mixins) para facilitar a estilização.
    • Mantenha um framework principal por aplicativo para desempenho e consistência; use Web Components nas fronteiras quando necessário.

Considerações organizacionais e de ecossistema

  • As escolhas de stack são fortemente influenciadas pela facilidade de contratação, consistência da equipe e bases de código existentes.
  • Alguns desejam um futuro com menos dependências e mais capacidades nativas; אחרים veem a tendência avançando para mais ferramentas e abstrações de nível mais alto construídas sobre frameworks e Web Components.