HTML First

Reação geral a “HTML First”

• Muitos gostam da proposta de um desenvolvimento mais simples, centrado em HTML, especialmente para sites pequenos/médios e apps renderizados no servidor.
• Outros veem isso como uma romantização de práticas do início dos anos 2000 e uma ignorância do motivo pelo qual frameworks, ferramentas de build e a separação de responsabilidades se tornaram comuns.

HTML vs Frameworks (React, Vue, etc.)

• Pró-HTML-first:
  • A maioria das interfaces web são formulários e interatividade básica; renderização no servidor + “sprinkles” de JS (htmx, Alpine, etc.) muitas vezes basta.
  • Frameworks impõem complexidade pesada (gerenciamento de estado, roteamento, cadeias de build) e podem adicionar ~50% de esforço a projetos que não precisam de comportamento de SPA.
  • É bom para a aprendibilidade e para “View Source” como ferramenta de ensino e depuração.
• Céticos:
  • Para apps maiores e com estado (dashboards, motores de reserva, ferramentas ricas), frameworks ajudam a gerenciar complexidade, reutilização e fluxos de trabalho da equipe.
  • Sem eles, as equipes tendem a reinventar mini-frameworks ad hoc e ainda assim lutar contra peculiaridades do navegador.
  • Muitos devs valorizam usar uma única stack poderosa em todo lugar, em vez de dividir modelos mentais.

Atributos inline, localidade e separação de responsabilidades

• Defensores de onclick inline/classes utilitárias argumentam:
  • “Locality of behavior” (HTML, comportamento e estilo juntos) torna os componentes mais fáceis de entender em um só lugar.
• Críticos argumentam:
  • Isso reintroduz exatamente o tipo de spaghetti que a separação entre CSS/JS resolveu; é difícil refatorar e depurar em escala.
  • JS inline quebra ou enfraquece CSP, aumenta a exposição a XSS e complica revisões de segurança.
  • Acessibilidade sofre (por exemplo, div clicável em vez de <button>).

CSS, Tailwind e design de classes

• Tailwind é elogiado por:
  • Evitar arquivos CSS semânticos de difícil manutenção ao compor pequenas classes utilitárias.
  • Funcionar bem no escopo de componentes e incentivar tokens de design consistentes.
• Críticas:
  • Ele efetivamente transforma class em um segundo atributo style; o HTML fica carregado.
  • Exige uma etapa de build (purging/geração de CSS), o que conflita com ideais de “sem build”.
  • Algumas medições sugerem que bundles do Tailwind podem ser maiores do que CSS semântico bem projetado.

HTMX, hyperscript e bibliotecas “baseadas em HTML”

• HTMX e Alpine são citados como boas formas “HTML-first” de adicionar interatividade sem SPAs completas.
• Preocupações:
  • Retornar HTML de APIs pode misturar as preocupações de front-end e back-end.
  • hyperscript é explicitamente uma DSL customizada, contradizendo o próprio aviso do artigo contra sintaxes customizadas.
  • Alguns veem o HTMX como adequado para ferramentas internas e apps modestos, não para front-ends muito grandes.

Acessibilidade, UX e elementos nativos

• Muitos enfatizam semântica nativa (<button>, <details>, <summary>, <datalist>, ARIA adequada) como crucial para acessibilidade e suporte a teclado/leitor de tela.
• Outros observam que controles nativos (seletores de data, multiselects) são inconsistentes, difíceis de estilizar e frequentemente limitados demais, empurrando as equipes de volta para componentes JS personalizados.

Temas históricos / meta

• Vários comentários enquadram isso como mais uma volta de um ciclo recorrente: inline → separação CSS/JS → frameworks JS → agora “HTML-first” novamente.
• Há forte discordância sobre se isso é progresso genuíno, uma correção de rota útil ou apenas a mais recente moda.