Com a adoção de frameworks como Next.js e htmx, observamos um aumento no uso de renderização no lado do servidor (SSR). Como tecnologia do navegador, utilizar web components não é trivial. Frameworks surgiram para facilitar isso, alguns até mesmo usando um motor de navegador, mas a complexidade ainda persiste. Nossas equipes de desenvolvimento se vêem precisando de soluções alternativas e esforço adicional para ordenar componentes de front-end e componentes do lado do servidor. Pior do que a experiência da pessoa desenvolvedora é a experiência da pessoa usuária: o desempenho do carregamento da página é prejudicado quando web components customizados precisam ser carregados e hidratados no navegador, e mesmo com pré-renderização e ajustes cuidadosos do componente, um lampejo de conteúdo sem estilo ou alguma mudança de layout é quase inevitável. Conforme mencionado no Radar anterior, uma de nossas equipes precisou migrar seu design system do Stencil, baseado em web components, devido a esses problemas. Recentemente, recebemos relatos de outra equipe que acabou substituindo componentes gerados no lado do servidor por componentes do lado do navegador devido à complexidade de desenvolvimento. Alertamos contra o uso de web components para aplicações web com SSR , mesmo que sejam suportados por frameworks.
Desde que os mencionamos pela primeira vez em 2014, os Web Components se tornaram populares e, em geral, nossa experiência tem sido positiva. Da mesma forma, defendemos a renderização de HTML no servidor, alertando contra SPA por padrão e incluindo frameworks como Next.js e htmx além de frameworks tradicionais de back-end. No entanto, embora seja possível combinar ambos, isso também pode se mostrar profundamente problemático. É por isso que sugerimos evitar Web Components para aplicações web renderizadas do lado do servidor (SSR). Por ser uma tecnologia de navegador, não é trivial usar Web Components no servidor. Frameworks surgiram para tornar isso mais fácil, às vezes até usando um motor de navegação (browser engine), mas a complexidade ainda existe. Pior do que os problemas para a experiência da pessoa desenvolvedora é a experiência da pessoa usuária: o tempo de carregamento da página é impactado quando os Web Components personalizados precisam ser carregados e renderizados no navegador, e mesmo com pré-renderização e ajustes cuidadosos do componente, um lash de conteúdo sem estilo ou algum deslocamento de layout é quase inevitável. A decisão de abster-se de Web Components pode ter consequências abrangentes, como uma de nossas equipes comprovou quando precisou mover seu sistema de design para longe do Stencil, que é baseado em Web Components.
