Construindo um frontend robusto com aprimoramento progressivo

 (gov.uk)
1 pontos por GN⁺ 2024-09-30 | 1 comentários | Compartilhar no WhatsApp

Como construir um frontend robusto: aprimoramento progressivo

  • Comece com HTML

    • Os serviços governamentais devem funcionar apenas com HTML
    • A camada de HTML é tolerante a falhas, então pode funcionar até em navegadores antigos
    • É preciso usar marcação semântica correta e estruturar o documento de forma lógica

  • Uso de CSS

    • É possível estilizar o serviço com CSS
    • A camada de CSS é tolerante a falhas, pois pode ignorar declarações individuais
    • Deve-se evitar tecnologias como CSS-in-JS

  • Uso de JavaScript

    • JavaScript é usado para adicionar elementos interativos
    • A camada de JavaScript não é tolerante a falhas e pode gerar erros
    • É possível melhorar a compatibilidade com detecção de recursos das APIs do navegador, inclusão de polyfills, transpiling etc.
    • O JavaScript deve complementar o HTML e o CSS

  • Alternativas ao JavaScript

    • Deve-se considerar soluções simples que atendam às necessidades do usuário mesmo sem JavaScript
    • Algumas alternativas são exibir tabelas de dados, exportar dados e pré-renderizar gráficos como imagens

  • Uso de frameworks JavaScript do lado do cliente

    • Deve-se evitar o uso de frameworks quando a interface não for complexa
    • Ao usar frameworks, podem surgir problemas como aumento do tamanho da base de código, problemas de desempenho e dependência de código de terceiros
    • Ao usar frameworks, cada interface de usuário deve ser projetada como um componente separado

  • Motivos pelos quais CSS ou JavaScript podem não carregar ou não executar

    • As causas podem incluir erro de rede, extensões do navegador, indisponibilidade de fornecedores terceirizados, falha na resolução de DNS e bugs causados por atualizações do navegador
    • Alguns usuários podem desativar intencionalmente recursos do navegador

  • Aplicações de página única (SPA)

    • Não se deve construir serviços como aplicações de página única
    • SPAs podem prejudicar a acessibilidade e causar problemas como gerenciamento de foco na navegação entre páginas e impossibilidade de usar os botões voltar/avançar

  • Teste do serviço

    • Componentes que dependem fortemente de JavaScript ou de frameworks JavaScript devem funcionar em vários navegadores e dispositivos
    • Também é preciso testar a acessibilidade

  • Estudos de caso e guias relacionados

    • Por que usar aprimoramento progressivo
    • Design para diversos dispositivos
    • Como testar o desempenho do frontend
    • Entendendo a WCAG 2.2

Resumo do GN⁺

  • O aprimoramento progressivo é uma forma de construir sites na ordem HTML, CSS e JavaScript
  • Esse método aumenta a tolerância a falhas do serviço e permite que ele funcione em diferentes navegadores e dispositivos
  • O JavaScript deve ter um papel complementar, e soluções alternativas devem ser consideradas
  • Aplicações de página única devem ser evitadas devido a problemas de acessibilidade
  • Os testes do serviço devem garantir acessibilidade em diferentes ambientes

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-30
Comentários no Hacker News

  • Ao usar frameworks JavaScript, é preciso conseguir demonstrar qual benefício isso traz para o usuário

    • Se for um app que pode funcionar offline como um aplicativo de desktop, faz sentido construí-lo como uma single-page application (SPA)
    • Exemplos incluem Photopea, Google Docs/Sheets, tldraw etc.
    • Se for um app que precisa de conexão com a internet e várias páginas, é melhor deixar o navegador cuidar da navegação

  • Pontos apontados como desvantagens das SPAs

    • Usuários de tecnologias assistivas podem não perceber mudanças de contexto ao navegar entre páginas
    • Não conseguem lidar com o foco ao mudar de página
    • Não é possível usar os botões de voltar e avançar do navegador
    • Não é possível se recuperar de erros caso a conexão de rede caia
    • Mas esses problemas também podem ser resolvidos em SPAs

  • Seria bom se toda a internet seguisse esse conselho

  • Soluções simples devem ser priorizadas

  • Fico curioso sobre por que Linux não está na lista

  • Parece que muita gente gosta dessa abordagem

    • Fico curioso sobre por que a tendência geral é usar JavaScript e frameworks como React sem necessidade

  • Usa HTML e dados previamente buscados no servidor, e processa no cliente o que pode ser feito no cliente

    • Usa CSS mínimo e JavaScript vanilla
    • Pode parecer antiquado para os colegas, mas não deixa nada a desejar

  • Muitas SPAs têm problemas, mas nem todas são problemáticas

    • Exemplos como VitePress e SolidJS mostram que isso pode funcionar bem
    • Quase ninguém deixa de usar JS
    • Não há problema para processar JS mesmo em dispositivos de baixo desempenho
    • Problemas de acessibilidade não têm relação com usar ou não SPA
    • O Svelte também já vem com alertas de acessibilidade embutidos

  • Renderização no lado do servidor também não é boa em todos os casos

    • É preciso ter cuidado ao usar frameworks JavaScript do lado do cliente
    • A base de código cresce, e como há mais trabalho para fazer no cliente, podem surgir problemas de desempenho
    • Pode acabar dependendo de código de terceiros, o que dificulta a manutenção
    • Ao usar frameworks JavaScript, é preciso conseguir demonstrar qual benefício isso traz para o usuário
    • É preciso estar ciente dos impactos negativos e saber mitigá-los
    • Frameworks devem ser usados apenas nas partes que não podem ser construídas só com HTML e CSS
    • Cada parte da interface deve ser projetada como um componente separado
    • Mesmo que o JavaScript não carregue, o restante da página deve continuar carregando normalmente