O que Precisamos em Vez de "Web Components"
As críticas aos Web Components se concentram em sua complexidade, semântica fraca e baixa adequação ao modo como os frameworks JavaScript modernos realmente constroem interfaces, com muitos argumentando que eles adicionam especificações frágeis sem resolver problemas centrais como gerenciamento de estado, reconciliação e estilos. Os comentaristas, em vez disso, pedem que os navegadores padronizem primitivas de baixo nível nas quais os desenvolvedores já convergem — como melhor diffing do DOM, reatividade e widgets de UI — enquanto outros defendem os Web Components (muitas vezes por meio de bibliotecas como Lit) como uma forma útil e agnóstica a frameworks de encapsular elementos interativos. A discussão se amplia para preocupações com a rotatividade do ecossistema JavaScript, padrões sobrepostos como Observables e signals, e se a web deveria caminhar para modelos de aplicativos mais parecidos com nativos ou binários.
Padrões, navegadores e governança
- Debate sobre para quem os Web Components realmente servem: desenvolvedores de aplicações vs. engenheiros de navegadores/padrões.
- Discordância sobre os papéis do W3C vs. WHATWG: alguns veem o W3C como formalizando as especificações de facto do WHATWG; outros destacam atritos (instantâneos de HTML, privacidade, mudanças de especificação que quebram conteúdo existente).
- Preocupação de que as especificações HTML e processos relacionados tenham se tornado confusos, lentos e, às vezes, quebrando compatibilidade retroativa.
Web Components: benefícios e ceticismo profundo
- Os fãs gostam de:
- Poder definir elementos personalizados que funcionam em diferentes frameworks e em HTML puro.
- Encapsulamento via Shadow DOM e módulos ES.
- Uso em bibliotecas de componentes e aplicações complexas (muitas vezes com Lit) sem etapas de build, em princípio.
- Os críticos argumentam:
- O design ignorou a experiência real de frameworks e a evolução do userland.
- As especificações são complexas, frágeis e geram mais especificações para corrigir problemas específicos de Web Components.
- Má adequação como blocos fundamentais para frameworks modernos (renderização antecipada, história fraca de SSR, composição estranha, surpresas do Shadow DOM).
- Líderes do ecossistema que antes defendiam Web Components se afastaram deles.
- Um nicho em que muitos concordam que ajudam: widgets encapsulados e controles de formulário personalizados, de certa forma como iframes menores e mais seguros.
Frameworks, rotatividade do ecossistema e compatibilidade
- Forte frustração com a complexidade do frontend em JS: muitas camadas (bundlers, linting, TS, build/transpile) e mudanças frequentes de paradigma (classes → hooks → server components).
- Outros contrapõem que todos os ecossistemas evoluem, e que o JS não é singularmente ruim comparado, por exemplo, ao empacotamento em Python ou a mudanças de ruptura em outras pilhas.
- Preocupação mais ampla de que bibliotecas e ferramentas JS raramente priorizam interfaces compartilhadas e estáveis, levando a “incompatibilidade interna” e upgrades dolorosos.
Reatividade, observables e primitivas sobrepostas
- Concordância de que “reatividade” e reconciliação são problemas reais, mas ainda sem consenso de design.
- Signals, observables, streams e outras primitivas reativas correm o risco de se sobrepor como padrões incompatíveis.
- Alguns acolhem observables em nível de navegador; outros temem a proliferação de maneiras quase duplicadas de “ouvir mudanças”.
WASM, apps nativas e o papel da web
- Alguns gostariam que os navegadores simplesmente executassem binários nativos; outros apontam falhas e problemas de segurança de plugins no passado.
- Há consenso de que operações no DOM dominam o desempenho da UI; WASM ajuda principalmente com computação pesada, não com UIs reativas típicas.
- A ferramenta para WASM é vista como melhorando, mas ainda inferior à nativa; existem fluxos de trabalho de compilação cruzada, mas eles parecem desajeitados.