Substituindo JavaScript apenas com HTML

• Apresenta formas modernas de substituir recursos dependentes de JS por HTML/CSS na web
• Usa elementos padrão como details·summary, datalist e popover para implementar acordeão, autocomplete, modal e navegação off-screen
• Essa abordagem reduz download, avaliação e uso de memória, melhorando o desempenho e a experiência do usuário
• Para cada recurso, são fornecidos exemplos no CodePen, documentação do MDN e informações de compatibilidade entre navegadores
• O JS deve ser usado apenas onde for realmente necessário, com aproveitamento ativo dos recursos avançados de HTML/CSS

---

Substituindo recursos de JS com HTML e CSS

• Por muito tempo, o JavaScript ficou responsável por recursos que não podiam ser implementados com HTML e CSS
  • Porém, com a expansão dos recursos de HTML e CSS, algumas funcionalidades de JS agora podem ser substituídas por tecnologias web nativas
• Como o JS precisa ser baixado, descompactado, avaliado e mantido na memória, é mais eficiente migrar para HTML/CSS tudo o que for possível
• A proposta é deixar o JS focado na lógica complexa e delegar o controle de UI mais simples ao HTML/CSS

Acordeão / painel de conteúdo expansível

• Com os elementos details e summary, é possível criar um acordeão sem JS
  • O conteúdo pode ser aberto e fechado com clique, e o estado padrão pode ser definido com o atributo open
  • Se usar o mesmo atributo name, apenas um painel permanece aberto
• Também é possível estilizar com CSS ou controlar abertura/fechamento com JS
• Materiais relacionados: documentação do MDN sobre details, exemplo no CodePen e tabela de compatibilidade entre navegadores

Campo de entrada com sugestões de autocomplete

• A combinação de input e datalist permite criar um dropdown com filtragem automática
  • Ao digitar, a lista de sugestões é filtrada automaticamente
  • Além de texto, há suporte a vários tipos de entrada como number, time etc.
• O Firefox atualmente suporta apenas entradas baseadas em texto, e há limitações de acessibilidade no mobile
• Materiais relacionados: documentação do MDN sobre datalist, tutorial do SitePoint e tabela de compatibilidade entre navegadores

Modal / popover

• Os atributos popover e popovertarget permitem criar modal e popover sem JS
  • Há três modos: auto, hint e manual
  • auto fecha ao clicar fora ou pressionar ESC, enquanto manual só fecha manualmente
• Firefox e iOS não oferecem suporte ao modo hint
• Materiais relacionados: documentação do MDN sobre popover, blog do Chrome, exemplo no CodePen e vídeo sobre acessibilidade

Navegação / conteúdo off-screen

• É possível implementar um menu de navegação off-screen usando o recurso popover
  • O elemento nav dá significado semântico, e o CSS translate move o conteúdo para dentro e para fora da tela
  • Fecha ao clicar fora, e popover="manual" permite configurar fechamento manual
  • O pseudo-elemento ::backdrop pode deixar o fundo semitransparente
• Materiais relacionados: API Popover do MDN, blog do Chrome e exemplo no CodePen

Conclusão

• Reconhecendo o poder do JS, ele deve ser usado apenas onde for necessário
• Com os avanços recentes de HTML/CSS, surgiram muitas alternativas sem JS
• Mais exemplos podem ser vistos no post do autor: “Replace JS with No-JS or Lo-JS Options”
• Reforça a melhoria da experiência do usuário por meio da minimização de JS e otimização de desempenho

[labeldock]

Esse tipo de tentativa às vezes me faz refletir se estou fazendo overengineering, mas, do ponto de vista do trabalho prático com requisitos robustos, é quase um número de força.

[skageektp]

> É possível implementar um acordeão sem JS com os elementos ** e **

Parece que faltou um pedaço do conteúdo.

[xguru]

Fiz a correção~!

[shakespeares]

Há limitações bem claras e, no momento em que a IA foi ativada... será que há necessidade de fazer esse tipo de refatoração?
Isso levou em consideração pontos como o bloqueio de conteúdo em JS?

[GN⁺]

Comentários no Hacker News

• É uma pena que nem todos os exemplos tenham sido colocados inline
  Se os exemplos alternativos em HTML tivessem sido colocados diretamente na página, em vez de links para o CodePen, teria sido bem mais convincente
  • Concordo totalmente. Às vezes você clica em algo como FooMaker v1.0 e, em vez de ver um caso de uso comum, só mostram casos extremos aleatórios
  • No começo achei que fosse um texto de 25 anos atrás. O GIF com dithering passa uma vibe totalmente retrô
  • Também fiquei frustrado por não haver exemplos inline, mas, se isso for um post de blog convidado, até dá para entender
• O potencial das tags <details> / <summary> é realmente enorme
  Dá para fazer quase tudo com elas, mas a maioria das bibliotecas de componentes ignora isso
  Não precisa nem de atributos aria e a acessibilidade já vem embutida
  • Antes, uma desvantagem era que a busca com cmd+f não encontrava texto dentro de details fechados, mas agora isso pode ser resolvido com o atributo hidden="until-found" e eventos
  • Só que lidar com animações é complicado. Os navegadores não dão suporte nativo a transições para mudança de display
  • Também existe a funcionalidade de abrir details automaticamente ao pesquisar com ctrl+f
  • <details> também funciona em sites baseados em Markdown, como o GitHub. Dá para recolher logs longos e postar tudo de forma mais limpa
  • Também dá para implementar só com CSS. Por exemplo, na documentação do Go101, dá para expandir clicando no “+”. Também há este demo de painel com abas. Isso mostra a força do Modern CSS
• O ponto principal não é “sem JavaScript”, mas que o HTML já cobre funcionalidades esquecidas (formulários, diálogos, validação, navegação etc.)
  Ao escrever o livro “You Don’t Need JavaScript”, a percepção foi que o JS muitas vezes complementa recursos já existentes da plataforma, em vez de adicionar algo realmente novo
  • Queria que existissem mais livros assim. Precisamos de livros focados em resolver problemas, e não apenas em aprender frameworks
  • Antigamente o suporte dos navegadores era insuficiente, então os desenvolvedores criavam soluções alternativas, e isso acabou virando padrão. Recentemente, o ritmo de lançamento de recursos de CSS acelerou, e até o layout masonry já entrou em fase experimental
• A maioria dos recursos de HTML é excelente, mas <input> e <datalist> deixam a desejar no uso real
  Os usuários esperam tolerância a erros de digitação, texto auxiliar e boa UX no mobile, e o datalist não atende a isso
  • O mais incômodo é não poder separar o texto exibido do valor real (value) no datalist
  • Na maioria dos casos, select é mais apropriado, mas ele não tem busca
  • O estilo padrão é muito grosseiro e feio
  • No Android, o dropdown nem aparece
  • Como o comportamento varia de dispositivo para dispositivo, no fim você precisa adicionar JS. Só com HTML, você cai num inferno de compatibilidade
• Fiz várias entrevistas de frontend recentemente, e ainda avaliam só habilidade em JS centrada em React
  Quase não ligam para uso semântico de HTML nem para acessibilidade
  • Se o time usa React, quem mexe direto com a DOM pode acabar sendo eliminado por aderência ao time
  • Usar arquivos CSS separados deixa os componentes bem mais limpos. Tailwind não é ruim, mas eu não gostaria de usar isso numa entrevista
  • Fora do HN, quase ninguém se interessa por purismo em HTML
• Incomoda que tenham colocado só links para o CodePen e não os exemplos direto na página
  Num texto que diz “vamos fazer só com HTML”, depender de um serviço externo soa contraditório
  • Pessoalmente, acho aceitável. O CodePen é conveniente para favoritos e syntax highlighting. Mas existe o risco de link rot
  • Ainda assim, teria sido melhor oferecer tanto exemplos inline quanto links para o CodePen
  • Enfatizar HTML e, ao mesmo tempo, obrigar a carregar uma UI de CodePen de 2 MB é paradoxal do ponto de vista de UX
• Estou ansioso pelo recurso de select customizável que deve chegar em breve
  Está no stage 3 do WHATWG e talvez possa substituir a implementação pesadelo dos dropdowns em JS
  Veja este post do blog do Chrome
• HTML puro é familiar e confortável, mas hoje tem limites para criar webapps funcionais
  Já tentei alternativas como HTMX e Phoenix LiveView, mas elas não são solução completa
  No fim, parece mais realista aceitar o JS moderno
  • Mesmo usando só um pouco de JS, dá para ir muito mais longe do que usando apenas HTML. Hoje o abuso de JS na web está prejudicando seriamente a usabilidade
  • Parece que estão complicando demais o HTMX. Se você usar hx-select / hx-target com base no estado do servidor, dá para manter tudo simples
  • A tag <marquee> era adequada para implementar rolagem horizontal em sites de compras, mas hoje fazem isso à força com JS. Seria bom se o HTML desse suporte nativo a mais padrões de UI
  • Já desperdicei muitos tokens tentando implementar efeito marquee em React. Nem era um loop perfeito, só um truque de animação
  • Se você usa Elixir e Phoenix, vale considerar também o Gleam. Ele compila para JS
• HTML e JS são ferramentas com propósitos diferentes
  Webapps complexos precisam de JS, mas ainda existe muita coisa que pode ser feita só com HTML
  • Algo como Google Earth obviamente precisa de JS, mas acho que algo no nível do Gmail também poderia ser feito com HTML. As tendências e o hype dos fabricantes de navegadores estão travando a evolução do HTML
  • htmx é complementar ao JS. A ideia central é trocar hipertexto estruturado em vez de JSON. Na prática, já fiz apps bem complexos rapidamente com htmx + um pouco de JS
  • O HTML deveria oferecer mais recursos por padrão. Por exemplo, suporte a verbos HTTP, melhorias nos controles de entrada etc.
  • Muitos sites pesados em JS na verdade poderiam ser substituídos tranquilamente por htmx. A escolha da ferramenta é uma questão de hábito
• Concordo com a ideia de que “o JS não precisa gerenciar acordeões nem menus de navegação”
  Mas hoje o JS virou uma ferramenta central para coleta de dados e rastreamento publicitário
  Fico me perguntando se, sem JS, as big techs conseguiriam implementar o mesmo nível de vigilância e serviços de anúncios
  No fim, a antipatia contra JS não vem só de uma questão técnica, mas também da desconfiança em relação ao ecossistema de publicidade