Web Components são aceitáveis

 (nolanlawson.com)
2 pontos por GN⁺ 2024-10-01 | 1 comentários | Compartilhar no WhatsApp
  • O debate sobre web components não é uma questão de escolher apenas entre desempenho máximo e padrões da plataforma, e já parte de uma premissa exagerada ao supor que eles precisam substituir todos os frameworks JavaScript
  • Custom Elements têm overhead por usarem o DOM como interface, mas em produtos reais é preciso avaliar não só desempenho, como também manutenibilidade, segurança, usabilidade e acessibilidade
  • O custo de suporte a web components pelos frameworks pode ser absorvido com algumas verificações simples, e o fato de algo ser um recurso padrão não significa que todo framework precise adotá-lo obrigatoriamente
  • Web components têm pontos fracos em server-side rendering (SSR), acessibilidade e parte da interoperabilidade, então ainda existem situações em que React, Solid e Svelte são mais adequados
  • Em ambientes como o da Salesforce, com apps renderizados no cliente, marketplaces de componentes e forte necessidade de retrocompatibilidade de longo prazo, web components podem ser uma escolha prática

O ponto de partida do debate e a posição do autor

  • O debate recente segue a partir de “Web Components Are Not the Future”, de Ryan Carniato, e “Web Components Are Not the Future — They’re the Present”, de Cory LaViska
  • O ponto central não é atacar o lado oposto, mas sim saber se desenvolvedores com restrições diferentes conseguem encontrar um terreno em comum
  • Ryan Carniato é muito respeitado por seu trabalho com o Solid e com desempenho e arquitetura de frameworks, como aparece no js-framework-benchmark
  • Web components também têm um campo real de uso, ligado à implementação de frameworks, criação de componentes, ao Web Components Community Group, ao grupo Accessibility Object Model e ao trabalho com shadow DOM, custom elements e acessibilidade

Desempenho: o custo do DOM é real, mas não é tudo

  • A fraqueza básica dos web components é o fato de serem baseados em Custom Elements
    • Como toda interface precisa passar pelo DOM, surge um overhead de desempenho
    • Se o objetivo for o framework absolutamente mais rápido, é preciso reduzir ao máximo os nós DOM, e nesse critério web components ficam em desvantagem
  • Ainda assim, desempenho não é o único critério no desenvolvimento de software
    • Manutenibilidade, segurança, usabilidade e acessibilidade também precisam ser consideradas
    • Não renderizar atributos aria-* pode tornar a renderização do DOM um pouco mais rápida, mas eles podem ser necessários para uma interface acessível
    • Micro-otimizações como usar for em vez de .forEach() ou var em vez de const/let normalmente não compensam o custo
  • Minimizar nós DOM é a ideia central da virtualization
    • Mesmo que não seja a opção mais rápida, uma abordagem mais simples pode ser suficiente
    • components as elements também não é o ideal em termos absolutos, mas nem sempre o objetivo precisa ser o ideal
  • Usar juntos custom elements feitos com frameworks diferentes também faz sentido no trabalho real
    • Pode ser necessário migrar gradualmente do Framework A para o Framework B
    • Também pode haver casos em que vários micro frontends precisem ser combinados
    • Não é a interface mais rápida, mas pode ser o trade-off necessário
  • Em desempenho web real, são mais comuns pontos de melhoria de baixo custo como layout thrashing, waterfall de rede e rerenderizações desnecessárias
    • Competições como js-framework-benchmark são interessantes para autores de frameworks, mas nem sempre são decisivas em produtos comuns
    • Se cada milissegundo importa em um ambiente com recursos limitados, abandonar web components também pode ser uma escolha válida

Custo de suporte em frameworks e liberdade de escolha

  • O autor não concorda com a ideia de que oferecer suporte a web components seja um custo excessivo para quem escreve frameworks
    • A detecção de props e attributes pode ser resolvida com a verificação prop in element
    • Gerar web components pode ser doloroso, mas não é algo que todo framework seja obrigado a fazer
    • O Vue 2 usava uma web component wrapper library separada, e o Remount existe sem participação da equipe do React
  • Dá para criar frameworks excelentes mesmo ignorando recursos adicionados à plataforma web depois de 2011
    • O jQuery v1 ainda funciona em muitos sites
    • Como equipes de desempenho dos navegadores otimizam padrões antigos usados por desenvolvedores web, código velho pode até ficar mais rápido em navegadores novos
  • Escolher adotar recursos modernos da plataforma web traz novas considerações
    • Recursos como Symbol, Proxy e Promises entram na mesma categoria
    • Graças à retrocompatibilidade da web, código escrito hoje pode continuar funcionando daqui a 10 anos
  • Também é perfeitamente possível haver frameworks que não se interessam por web components ou não querem dar suporte a eles
    • É possível construir toda a UI com web components
    • Também dá para misturar apenas alguns HTML web components
    • Também é possível não usar nenhum
    • Um framework “sem web components” também pode conquistar fãs

Padrões são referência, não obrigação

  • Quando um recurso vira padrão, desenvolvedores passam a usá-lo como base de comparação
    • Quem cria componentes precisa decidir se seu <slot> deve funcionar como o <slot> nativo
    • Também é preciso escolher entre usar IntersectionObserver ou <img loading="lazy">, ou criar uma abstração própria
  • Padrões oferecem um ponto de referência comum e um vocabulário compartilhado
    • Eles criam um critério para comparar e contrastar abordagens diferentes
    • Mas ser padrão não significa que o recurso precise ser usado obrigatoriamente
  • A web mantém lado a lado recursos opcionais e APIs antigas
    • APIs depreciadas como document.domain, with e <frame> continuam sendo suportadas
    • Os recursos da plataforma web podem ser escolhidos ou deixados de lado

Onde web components servem — e onde não

  • Web components fazem muitas coisas bem, mas não são uma ferramenta para substituir todos os frameworks JavaScript
  • Entre seus pontos fracos estão server-side rendering (SSR), acessibilidade e parte da interoperabilidade
  • Ainda há muitas situações em que frameworks como React, Solid e Svelte brilham mais
  • Dizer que “web components não são o futuro” pode fazer sentido para certos desenvolvedores ou projetos
  • No fundo do debate está o fato de pessoas diferentes estarem construindo coisas diferentes sob restrições diferentes

O caso Salesforce e o julgamento prático

  • A Salesforce mostra um ambiente em que web components podem se encaixar bem
  • Fora dessas condições, talvez não seja necessário construir toda a UI com web components, shadow DOM e toda a estrutura associada
  • Na plataforma web coexistem jogos, projetos artísticos e apps SaaS corporativos feitos com recursos variados como WebGL, Wasm e Service Workers
  • Quando novos recursos são adicionados à plataforma, em vez de limitar a criatividade, eles ampliam as possibilidades de expressão de formas antes inimagináveis
  • Como leituras complementares, o autor também recomenda o texto de Lea Verou e o texto de Baldur Bjarnason

Leituras relacionadas

1 comentários

 
GN⁺ 2024-10-01
Opiniões do Hacker News

  • Tentei entender o texto citado “Web Components Are Not the Future”, mas não havia muitos argumentos convincentes
    O estado atual dos frameworks de front-end é uma bagunça, e não quero aprender mágica (useState, createSignal etc.) que não dá para entender antes de ler frameworks ou documentações complexas
    Começar por Web Components parece intuitivo, e eles também trazem capacidades que não existem em outros lugares, como o isolamento do Shadow DOM
    Acho que a única coisa a preservar da era React é o JSX, e criei uma biblioteca para usar Web Components junto com JSX: https://webjsx.org

    • A frase “não quero aprender frameworks complexos” mistura várias ideias, então é difícil interpretá-la
      Fica ambíguo se a pessoa não quer aprender o framework em si, se quer algo que pareça mágico a ponto de não precisar aprender, ou se quer ou não ler a documentação
      Tenho usado principalmente Vue, e o ecossistema de SPA é complexo, mas também não sei que outro sistema seria possível para gerenciar aplicações cliente com estado complexo
    • Também há uma diferença em como se pensa sobre UI
      O padrão básico do jQuery é centrado em efeitos colaterais, selecionando elementos e alterando-os, enquanto React ou Vue.js permitem criar componentes cuja UI é determinada por dados de estado
      Quando os dados mudam, a atualização ocorre com o mínimo de alterações no DOM, e esse modelo torna widgets de UI, dependendo do contexto, muito mais legíveis e fáceis de manter
      Hoje, sites e aplicações desktop baseadas na web são muito mais complexos do que há 20 anos, então, se você não estiver criando apenas UIs simples, a inovação no gerenciamento de estado é importante
    • Para escrever uma aplicação React, não é preciso saber como useState funciona internamente, e a forma de aplicá-lo é bastante intuitiva
      Em contraste, a biblioteca apresentada parece exigir desde o início um modelo mental mais complexo
      Embora seja ideal entender profundamente os detalhes de um framework, o React foi bem-sucedido justamente por permitir criar aplicações bastante sofisticadas sabendo muito pouco sobre seu modelo interno
    • Angular não era tão difícil, e em cerca de uma semana dava para aprender o suficiente para criar um site complexo ou enviar um PR razoável
      Talvez seja porque sou desenvolvedor desde a época beta do C# e desde o início de HTML/JS/CSS, mas entendi rapidamente
      Escolhemos Angular ao substituir um portal central de gerenciamento de infraestrutura antigo e complexo; ele ficou estável, rápido, bonito, e todos ficaram satisfeitos
      A “curva de aprendizado íngreme” parece vir principalmente de desenvolvedores que entraram no setor sabendo apenas JavaScript e um pouco de React; com mais experiência, dá para aprender na hora
    • Um desenvolvedor curioso sobre o interior de useState consegue chegar a uma resposta lógica e correta em poucos segundos
      Não é complicado nem mágico, e uma implementação mínima parecida com hooks do React cabe em algumas centenas de linhas
      Implementações básicas de useState e runFunctionComponent são mais fáceis do que a maioria dos trabalhos do 3º semestre de Ciência da Computação na universidade
      Se isso é o critério para magia, então estamos cercados de Warlocks de nível 20 criando novas Eldritch Invocations até durante o café da manhã

  • Acho que um dos motivos pelos quais as pessoas se desencontram nesse debate é que estão otimizando para coisas diferentes
    Se você está em uma startup financiada por VC, movendo-se rápido e criando um produto central que continuará sendo mantido, um framework pode fazer sentido
    Mas, em um laboratório acadêmico, não há muito dinheiro para manter aplicações já criadas, e elas precisam continuar funcionando mesmo depois que o financiamento passa para novos projetos
    Estou quase terminando de reescrever uma aplicação Vue como Web Components, porque as dependências haviam apodrecido a ponto de ser impossível atualizá-las
    Antes eu gastava tempo consertando o inferno de dependências, e continuaria fazendo isso; experimentei Web Components, gostei de imediato e fiz a migração
    As dependências caíram de cerca de 15 para cerca de 1 (d3js), e não me arrependo
    Aplicação antiga https://bam.iobio.io/, nova aplicação https://bam2.iobio.io/

    • Às vezes acho difícil entender essa lógica
      Ninguém obriga você a atualizar um framework sempre para a versão mais recente, então teria sido possível simplesmente permanecer na versão do Vue que já usava
      Sem um motivo especial, talvez fosse aceitável usar a mesma versão até o fim
      Isso não quer dizer que Vue fosse necessário para esse caso de uso desde o início, nem que remover dependências tenha sido uma má escolha, mas, se você gosta de Vue, não parece haver uma força obrigando a ficar na versão mais recente
    • Se foi possível remover dependências mantendo apenas d3js, não teria sido possível fazer a mesma coisa e ainda manter a dependência do Vue?
      Fico curioso se o motivo de o Vue exigir dependências adicionais está no sistema de build
    • Depois que se pega prática, acho que o desenvolvimento com Web Components não é mais lento do que com qualquer framework
      Por isso não entendo bem por que o ecossistema de VC não conseguiria sobreviver sem frameworks
    • É difícil acreditar que todos os Web Components estejam sendo escritos à mão, e também é difícil imaginar que não exista nenhuma dependência externa

  • Gosto do fato de o Svelte dar suporte à criação de Web Components por meio da Custom Elements API
    Como o Svelte compila para JS/HTML/CSS comuns, é natural criar componentes reutilizáveis que funcionam em qualquer framework ou em JS vanilla: https://svelte.dev/docs/custom-elements-api

  • Acompanho a discussão sobre Web Components há anos, mas, como desenvolvedor full-stack, ainda não sei bem o que eles podem fazer para melhorar minha vida
    A maioria destes exemplos basicamente colocava dados em HTML como templates, e isso já dá para fazer com handlebars
    Será que estou deixando passar alguma coisa?

    • Na “web”, há um modelo que vê HTML como documento e outro que vê HTML como grafo de cena de uma aplicação mais complexa
      Se você usa HTML como documento, Web Components permitem adicionar recursos de interação em tempo real mais sofisticados
      Exemplos disso são emuladores de terminal conectados a WebSocket, seletores de data, elementos de formulário personalizados, mapas, tabelas de dados, widgets de abas e aqueles componentes personalizados que o antigo jquery-ui oferecia
      Dá para fazer sem Web Components, mas, ao criar como componentes personalizados, o HTML fica muito mais limpo e continua com cara de documento
      Seria bom ter uma biblioteca consistente de Web Components, e parece que também dá para fazer um chat em tempo real bem decente com HTMX e eventos enviados pelo servidor
    • É possível ter isolamento nativo completo
      O navegador isola todo o HTML, CSS e JS sem gambiarras extras
      É bom poder criar um Web Component, definir claramente as APIs de JS, HTML e CSS em termos de variáveis e então colocá-lo em qualquer ambiente sem quebrar, ou sem precisar criar um labirinto de namespaces CSS complexos e dependências de frameworks
    • É excelente para aprimoramento progressivo
      Por exemplo, você pode adicionar recursos como filtragem ou ordenação por arrastar e soltar com um Web Component que envolve uma tabela; se o JS estiver desativado ou falhar ao carregar, o usuário ainda recebe a tabela e o conteúdo básicos
      Antigamente isso era muito melhor do que a tela branca dos frameworks de front-end, mas hoje a renderização do lado do servidor está amplamente disponível, então a vantagem diminuiu
      O encapsulamento de estilos também é bom, mas hoje bibliotecas de UI headless e scoped styles dos frameworks são comuns, então parece menos urgente do que há 10 anos
      Porém, para usar slots é preciso optar pelo Shadow DOM, então é irritante não poder estilizar seus próprios componentes reutilizáveis simplesmente colocando uma folha de estilos na página
    • O motivo de os exemplos evitarem APIs dinâmicas provavelmente é que essa parte é muito feia e cheia de estado
      Se uma demo mostra 200 linhas de ajuste manual do DOM, fica difícil dizer que Web Components são o futuro
    • Web Components permitem usar, no seu framework, componentes de UI feitos em outro framework
      Isso é tudo; para a maioria dos outros propósitos, eles são bem ruins
      Além disso, dá para publicar um componente de UI que funcione em todos os frameworks sem criar 7 versões dele

  • A pior parte dos Web Components e do Shadow DOM é que eles podem fazer extensões de navegador funcionarem mal ou simplesmente não funcionarem
    Os fornecedores de navegadores também não parecem ter pressa para corrigir essa situação

    • A configurabilidade do user agent é o recurso matador da web

  • Vejo que um dos maiores “erros” dos Web Components foi tê-los associado ao Shadow DOM na cabeça das pessoas
    No desenvolvimento de apps, se você se mantém no DOM vivo, Web Components se tornam uma opção muito leve e fácil
    Você pode continuar usando as ferramentas de CSS que quiser, como bootstrap, tailwind etc., e ainda obter excelente encapsulamento funcional quase sem custo, especialmente usando algo como lit-html como renderizador
    As equipes em geral acharam trabalhar com Web Components nativos algo revigorante, e desenvolvedores vindos do mundo dos frameworks, depois de cerca de uma semana de adaptação, não queriam voltar
    Só com propriedades simples de classe e uma chamada manual da função de renderização em set(), dá para obter os benefícios da reatividade sem a burocracia dos frameworks
    O problema é que quase não há material mostrando como começar no “modo fácil”
    A maioria dos materiais introdutórios empurra a pessoa direto para tecnologias dolorosas como Shadow DOM e CSS parts, mais voltadas a autores de bibliotecas do que a desenvolvedores de apps
    Acho que eu deveria escrever um guia tipo “The Good Parts” sobre como Web Components podem facilitar a vida

    • Uso Shadow DOM todos os dias, mas essa também costuma ser a parte que mais confunde as pessoas em Web Components. Provavelmente porque não é necessária
      Como alternativa, há os “HTML web components”, que usam apenas o DOM vivo, priorizam renderização no servidor e são bons como substitutos do “tempero de jQuery”: https://adactio.com/journal/20618
      Também há o “Shadow gristle”, que usa Shadow DOM o mínimo possível e deixa no DOM vivo aquilo que precisa de estilização ou composição: https://glazkov.com/2023/03/02/shadow-gristle/
    • Se você escrever sobre isso, eu gostaria de ler. Ou ouvir também
      Essa tecnologia parece ser tanto uma bênção quanto uma maldição, dependendo de como é usada, então estou reunindo materiais e comentários relacionados
    • No emprego anterior usamos a mesma stack, isto é, WC sem Shadow DOM e apenas lit-html, e foi muito bom
      O melhor ponto é não cair no inferno de dependências a cada duas semanas
    • É exatamente isso. O que falta agora são slots para light DOM

  • A interoperabilidade é a maior vantagem do ponto de vista do usuário, mas acho que se subestima o fato de que, em troca, surge um custo de performance: cada componente usado pode trazer junto um runtime desnecessário
    Usar um framework como Lit junto com Web Components é a abordagem recomendada e, com o tempo, à medida que surgem novos frameworks e componentes ficam presos a versões antigas, esse custo se acumula
    Eu não recomendaria a ninguém uma direção em que uma página tenha várias bibliotecas duplicadas e, se isso fizer parte das boas práticas, não é bom no longo prazo
    Depois de ver por anos textos, redes sociais e vídeos de defensores de Web Components — e eu deveria ser exatamente o público-alvo —, vejo que, além do imposto da interoperabilidade, há uma série de desvantagens que os frameworks mainstream não têm
    Dentro do ecossistema de cada framework, a interoperabilidade funciona bem, e a mesma dinâmica que faz desenvolvedores buscarem interoperabilidade também os leva a se reunir em torno de alguns poucos frameworks mainstream
    Na minha visão, Web Components não acompanham do ponto de vista técnico e adicionam muita complexidade à plataforma Web em prol de um design do início dos anos 2010: https://x.com/Rich_Harris/status/1840116730716119356

    • Já tratei disso em outro texto, mas, em linhas gerais, nem toda aplicação Web é sensível a performance a cada kB extra. E-commerce é, mas ferramentas de produtividade geralmente não são
      Há muitos frameworks com runtime pequeno, como Svelte, e não estou dizendo para colocar 100 deles numa página, mas acho que uns 5 ou 6 tudo bem
      Não quer dizer que seja ideal, mas pode ajudar em migrações incrementais ou micro frontends
      Como referência, o React 17 também introduziu a capacidade de ter várias versões do React na mesma página: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • Embora isso esteja correto, olhando para a maioria das aplicações Web criadas hoje, o problema de múltiplas bibliotecas parece quase um erro de arredondamento
      React e react-dom juntos passam de 100 KB, enquanto Svelte e Lit ficam na casa de um dígito em KB
      Dá para incluir bastante framework antes de chegar perto do nível de inchaço que as pessoas usam todos os dias sem pensar
    • Num sentido mais amplo, Web Components precisam convencer os autores de frameworks
      Os sinais que vi de forma consistente até agora não são bons; essa comunidade está no X, e Web Components não resolvem os problemas deles nem são bem usados mesmo no melhor cenário
      Espero que consigam convencer, mas eles em geral dizem que Web Components fracassaram e, no conjunto, foram ruins para a Web
    • Sinceramente, não entendo bem esse argumento
      A maioria dos runtimes é bem pequena, e o fato de dois runtimes rodarem ao mesmo tempo não implica um grande overhead de performance
      Frameworks Web modernos são todos reativos; se não há nada a que responder, eles não fazem nada
      Se uma parte da página for feita em React, outra em Lit e outra em Svelte, não vejo bem por que a experiência do usuário ou o consumo de bateria ficariam perceptivelmente piores do que numa página com um único framework
      O tweet citado é sobre Web Components serem ou não “primitivas úteis para criar frameworks”, e mesmo fãs que os usaram de verdade em geral provavelmente não diriam que são
      Web Components são um mecanismo de distribuição e, se a alternativa é criar a mesma biblioteca 7 vezes para React, Preact, Svelte, Solid, Vue e vanilla JS, isso é horrível

  • Gosto de Web Components e sou otimista quanto à possibilidade de eles nos tirarem do inferno de frontend atual que nós mesmos criamos
    Recentemente fiz uma apresentação curta sobre o futuro do frontend, e parecia que outras pessoas também esperavam uma saída
    Criei uma tabela de dados para uma GUI de banco de dados, e a rolagem continua muito suave mesmo carregando centenas de milhares de linhas
    Também pretendo publicar em breve uma biblioteca de Web Components; ainda é cedo e está meio bruta, mas gostaria que mais pessoas dessem uma olhada: www.astra-ui.com

    • Acho que o único caminho para sair do inferno de frontend atual é termos imports no lado do cliente: https://github.com/whatwg/html/issues/2791
    • Dei uma olhada na documentação, e a renderização está muito estranha no Safari 18.0 de um iPhone 15 Pro Max
      Seria melhor reorganizar a barra lateral pensando em design responsivo para telas pequenas e usar max-width no body em vez de width
      O botão “explore components” no rodapé da página inicial parece não apontar para lugar nenhum
      Vocês dizem para “aprender com implementações de componentes bem estruturadas e acessíveis”, mas não encontrei links para as implementações na documentação
      Vocês dizem que “não há dependências para manter ou atualizar”, mas me parece que o próprio astra-ui é uma dependência, e também há um changelog: https://www.astra-ui.com/changes/
      Também dizem ter “controle total sobre o código e a estilização”, mas não entendo como isso é possível enquanto se depende da implementação fornecida pela biblioteca
      Fiquei curioso sobre o motivo de decidirem publicar essa biblioteca. Abrir software interno pode ser útil quando a empresa tem um objetivo específico, mas geralmente tende a consumir tempo sem retorno
      Bibliotecas de componentes precisam disputar adoção no ecossistema; caso contrário, não há público, e há pouco motivo para publicá-las
    • Qual seria o motivo para usar isso em vez de algo como componentes Vue?
    • Por que Web Components ainda não se consolidaram ou não são usados mais amplamente?
      Parecem uma ótima solução
    • Reescrevemos o código de anúncios de frontend da empresa usando Web Components

  • Há alguns meses, em um emprego novo, herdei uma base de código JS com cerca de 250 mil linhas
    Uma única classe gigantesca e algumas subclasses faziam tudo, e alguns arquivos chegavam a 30 mil linhas
    Não havia framework nem reatividade, então, ao clicar em um botão, era preciso atualizar manualmente tudo na tela por meio de event listeners
    Parecia um código escrito por alguém que ficou trancado por anos numa cela de mosteiro levando apenas um livro básico de JavaScript
    Como eu precisava fazer aos poucos, comecei a refatorar para Web Components, e isso ajudou muito; até agora reduzi 50 mil linhas
    Mas o objetivo real era aprender tudo o que o código existente fazia antes de reescrevê-lo

    • O ponto-chave para entender uma base de código antiga e obscura é refatorar pequenas partes de cada vez
      Refazer com Web Components é uma forma de alcançar esse objetivo, e é bom que não tenham jogado tudo fora para recomeçar do zero
      Só que, se você avançar até certo ponto e depois for para outro projeto, há o risco de a próxima pessoa chegar e começar a refatorar no próprio estilo, virando uma base de código obscura em três estilos diferentes
      Ainda assim, é melhor do que reescrever 250 mil linhas de uma vez

  • Uma coisa de que gostei em Web Components é que, ao menos em teoria, eles podem funcionar mesmo com JS desativado
    Já fiz isso algumas vezes para melhoria progressiva
    No geral, concordo com o Nolan. Web Components ainda têm arestas suficientes para ser difícil dominarem o mundo no estado atual, mas são bem bons para certos casos de uso
    Só não sei bem quanto à afirmação de que não combinam com renderização no lado do servidor; tenho feito isso sem problemas

    • Fico curioso para saber por que dizem isso
      Pelo que vi, parece ser necessário JavaScript para registrar um template em uma tag específica: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • Não entendo como isso deveria funcionar
      No ReactJS, é possível renderizar componentes ou templates no servidor, e considero JSX uma linguagem de templates bem boa
      Pelo que entendo, Web Components não têm uma boa linguagem de templates embutida, então é preciso trazer uma por conta própria
      Não conheço um mecanismo padrão para pegar o trecho de componente JS associado a uma tag e renderizar o HTML necessário sem executar JS
    • Sou o autor. Tratei disso em outro texto, mas basicamente as vantagens de interoperabilidade que se obtêm no cliente ainda não existem no servidor
      Se, no futuro, for possível renderizar no servidor três frameworks diferentes de Web Components, compô-los entre si e fazer hydration de forma limpa, então poderemos considerar o problema resolvido: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/