Por que mais desenvolvedores não “usam a plataforma”?
Muitos desenvolvedores web ainda preferem frameworks no estilo React e widgets personalizados em vez de recursos nativos do navegador, argumentando que “a plataforma” historicamente é inconsistente, insuficiente para necessidades reais de UX e difícil de usar diretamente. Exemplos como `<dialog>`, seletores nativos de data/hora, `<datalist>` e Web Components são citados como instáveis, inflexíveis ou inacessíveis entre navegadores, enquanto demandas de design e requisitos de produto frequentemente excedem o que os controles embutidos conseguem fazer. Outros respondem que o HTML/CSS/JS modernos melhoraram e podem substituir boa parte das ferramentas pesadas em JavaScript, mas reconhecem que o impulso do ecossistema, a documentação e as abstrações existentes tornam difícil voltar aos primitivos do navegador.
Limitações Percebidas dos Recursos Nativos do Navegador
- Muitos widgets nativos (inputs de data/hora,
<dialog>,<datalist>, multi-select, comboboxes) são vistos como limitados demais ou inflexíveis para requisitos do mundo real (por exemplo, desabilitar datas arbitrárias, listas pesquisáveis, agendamento apenas em dias úteis). - O drag-and-drop nativo e alguns controles de formulário se comportam mal ou de forma inconsistente entre navegadores e dispositivos (Safari no iOS, bugs no Firefox, casos extremos estranhos como “99 minutes” em campos de horário).
- Desenvolvedores muitas vezes descobrem que rapidamente “superam” os elementos nativos e acabam reimplementando-os em JS de qualquer forma.
Web Components vs Frameworks
- Web Components são amplamente criticados por serem desajeitados, de baixo nível e difíceis de usar diretamente (boilerplate, atributos vs propriedades, gerenciamento de estado, dor com Shadow DOM, estilos/resets).
- Muitos sentem que você, na prática, precisa de uma biblioteca de wrapper como Lit ou Stencil; nesse ponto, parece algo semelhante a usar React, só com trade-offs diferentes.
- Outros defendem os Web Components como blocos de construção performáticos, mas reconhecem a integração áspera com a plataforma mais ampla e a falta de APIs ergonômicas.
Experiência do Desenvolvedor, História e Efeitos no Ecossistema
- Historicamente, a plataforma era fraca; bibliotecas de jQuery a React preencheram lacunas enormes e treinaram desenvolvedores a recorrer ao npm em vez de às especificações.
- O sucesso do React é atribuído menos à superioridade técnica pura e mais à documentação excelente, materiais de ensino, conferências e impulso do ecossistema.
- Uma vez que uma tecnologia conquista espaço mental, sua comunidade (exemplos, suporte, componentes) reforça seu domínio, mesmo que alternativas tenham algumas propriedades melhores.
Acessibilidade, UX e Requisitos de Produto
- Equipes muitas vezes abandonam widgets nativos porque não conseguem atender aos designs de UX/brand nem às expectativas de acessibilidade (gerenciamento de foco, comportamento de teclado, leitores de tela).
- Controles personalizados frequentemente ficam mais quebrados em alguns dispositivos, mas designers e PMs ainda exigem UI sob medida; engenheiros se sentem forçados a se afastar dos padrões da plataforma.
Inconsistências do Navegador e Confiança na Plataforma
- Implementações inconsistentes ou com bugs (especialmente no Safari e em versões antigas) fazem os devs hesitar em confiar em “a plataforma”.
- Polyfills, contornos e longos prazos dos padrões incentivam resolver problemas em JS, onde as equipes têm controle total e podem entregar correções imediatamente.
IA, Abstração e “Usar a Plataforma”
- Alguns usam IA para gerar sites majoritariamente nativos, com pouco JS; outros observam que ainda é preciso um conhecimento profundo da plataforma para depurar os erros da IA.
- Vários argumentam que HTML/CSS/DOM são, na prática, uma espécie de assembly de baixo nível; frameworks e padrões reativos são vistos como a forma prática de gerenciar estado e complexidade.