Os Web Components vão superar os frameworks JavaScript

• Artigo sobre a longevidade e a flexibilidade dos Web Components, em comparação com frameworks JavaScript
• O autor defende que a escolha tecnológica de um projeto deve ser determinada pelas restrições do próprio projeto, e não pela opção padrão
• Motivos pelos quais o autor escolheu Web Components em JavaScript vanilla para o projeto: portabilidade e capacidade de renderização em HTML
• O blog do autor foi construído com várias ferramentas, como Astro, Hugo, um CMS personalizado escrito em PHP, Tumblr, Movable Type e WordPress
• Destaque para as vantagens de manter o conteúdo em arquivos de texto simples escritos em Markdown, simplificando o processo de mover conteúdo entre sistemas
• O autor afirma que, embora recursos específicos do Astro sejam convenientes, eles não são portáveis e por isso não foram usados no projeto
• Web Components podem ser escritos como HTML dentro de Markdown, o que os torna tão portáveis quanto o restante do conteúdo em Markdown
• Web Components são um conjunto de padrões da W3C para criar elementos HTML reutilizáveis, encapsulando todo o HTML, CSS e JS em um único arquivo, sem necessidade de sistema de build
• O autor observa que Web Components podem expor atributos para serem configurados externamente, de forma semelhante a props nativas
• Por preocupação com os compromissos de manutenção e dependências, o autor decidiu usar JavaScript vanilla em vez de frameworks que compilam para Web Components, como Lit, Stencil e Svelte
• O autor argumenta que dependências como TypeScript podem oferecer recursos úteis, mas exigem tempo e esforço para manter compatibilidade com novas versões e APIs
• Destaque para a importância de evitar dependências fora do controle do usuário e de se manter em padrões conhecidos e estáveis para acessibilidade de longo prazo e resiliência do conteúdo na web
• Conclusão do autor elogiando a web, quando usada com foco em longevidade, como a plataforma de computação mais resiliente, portátil e preparada para o futuro

[GN⁺]

Opiniões do Hacker News

• Artigo sobre a longevidade dos web components, em comparação com frameworks JavaScript
• Os comentaristas apontam que a biblioteca htmx não foi mencionada no artigo e que ela difere dos web components por focar na sincronização entre servidor e estado
• O htmx é elogiado por não ter dependências e por focar em compatibilidade retroativa, ao contrário de muitas bibliotecas JavaScript
• O gerenciamento de estado em web components é apontado como um problema ainda não resolvido, exigindo que desenvolvedores lidem com isso diretamente sem frameworks wrapper
• O desempenho dos web components não é tão importante quanto se imagina, e alguns elementos pequenos foram revertidos de web components por causa do custo de instanciação
• Os web components são elogiados por poderem ser adicionados facilmente a novas páginas, independentemente do framework usado, e pelo encapsulamento de estilos
• Alguns comentaristas expressam preferência pelos avanços e melhorias dos frameworks JS em vez de soluções estáticas como web components
• É enfatizada a importância de considerar o conhecimento e as habilidades da equipe ao iniciar um novo projeto
• Soluções do lado do servidor como Rails Hotwire, Phoenix Liveviews e Laravel Livewire são mencionadas como desenvolvimentos interessantes
• Os web components são criticados por não poderem ser executados no servidor e por exigirem JS no cliente para renderizá-los
• O uso de slots em web components é apontado como confuso e complexo, tornando-os menos atraentes para construir aplicações
• A API DOM é criticada por não ser adequada para juntar componentes e fazer uma aplicação funcionar
• Os web components são criticados pela falta de suporte do editor para recursos como autocompletar nomes de propriedades e eventos
• Alguns recursos básicos em web components, como botões dentro de formulários, continuam sendo problemas não resolvidos