Se você quer criar um botão do zero, primeiro precisa criar o universo
Recriar do zero algo aparentemente simples como um botão na web moderna expõe o quanto o HTML nativo já fornece em comportamento, acessibilidade e nuances entre dispositivos — e como é fácil errar esses detalhes. Comentadores debatem por que widgets nativos mais ricos (como um combobox “de verdade”) estão estagnados há décadas, apontando para política entre navegadores, padrões complicados como Web Components e a tensão entre HTML de “documento” e interfaces mais parecidas com apps. A acessibilidade surge tanto como uma preocupação técnica e ética genuína quanto como um campo minado legal, com alguns argumentando que IA e ferramentas mais inteligentes logo cuidarão de grande parte dessa complexidade, enquanto outros alertam que terceirizá-la para agentes opacos pode piorar usabilidade, privacidade e confiabilidade.
Sátira, botões e complexidade de acessibilidade
- Muitos veem o texto como preciso, apesar de estar apresentado de forma satírica: reimplementar um botão adequado é surpreendentemente difícil.
- Alguns leitores acharam o conteúdo educativo, por dependerem de frameworks e não conhecerem muitas das preocupações de acessibilidade.
- Outros observam que o código de exemplo ainda tem bugs (por exemplo, lógica incorreta de pointer/mouse-up), o que reforça o ponto de que fazer isso “direito” é complicado.
HTML nativo vs componentes customizados e widgets ausentes
- Vários argumentam que widgets complexos (por exemplo, comboboxes com filtragem no servidor) são difíceis ou impossíveis de fazer apenas com HTML nativo, empurrando desenvolvedores para implementações customizadas.
<input>+<datalist>é citado como uma solução parcial de combobox, mas atualização dinâmica/eficiente e comportamentos mais ricos continuam em falta.- Há frustração de que o HTML ainda não tenha muitos widgets de nível mais alto que toolkits nativos tinham há décadas.
Fornecedores de navegadores, padrões e estagnação
- Alguns culpam todos os principais navegadores pelo progresso lento em componentes nativos de HTML sem JavaScript.
- Outros rebatem as alegações de que a Apple bloqueia exclusivamente o progresso, apontando padrões como o Open UI e filosofias diferentes sobre velocidade versus segurança.
- A recusa do Safari em oferecer suporte à extensão de built-ins (por exemplo,
class MyButton extends HTMLButtonElement) é discutida; críticos dizem que isso força uma reimplementação completa em vez de uma customização leve.
Web vs “semantic web” e necessidades de aplicações
- Comentadores distinguem entre a “semantic web” centrada em documentos e aplicações web altamente interativas.
- Requisitos de negócio e de UX frequentemente divergem do que os controles nativos de formulário oferecem; atender a essas expectativas com elementos nativos puros é visto como impraticável ou caro demais.
Impacto da IA em UI e acessibilidade
- Um lado afirma que a IA agora torna trivial gerar componentes complexos e acessíveis, além de testes, do zero, enfraquecendo o argumento de “não reinvente o botão”.
- Outros contrapõem que a IA repete erros comuns (por exemplo, usar botões de forma incorreta para navegação), não cobre automaticamente todos os casos extremos e pode incentivar code bloat.
- Alguns relatam boas experiências ao pedir a LLMs para adaptar a acessibilidade em apps existentes; outros temem que modelos treinados em “código ruim” propaguem padrões ruins.
Conformidade de acessibilidade, ações judiciais e preocupações com “racket”
- É compartilhada uma história sobre uma ação judicial de acessibilidade que levou a mudanças caras, em grande parte superficiais, e a assinaturas contínuas de “conformidade”.
- Há debate sobre se futuros leitores de tela/agentes de IA tornarão a conformidade técnica rígida menos relevante, ou se leis e incentivos manterão o sistema atual em vigor.