Por que Vanilla JavaScript

Artigo original ↗ Discussão no Hacker News ↗

Os defensores do JavaScript “vanilla” argumentam que navegadores modernos, Web Components e helpers leves personalizados são suficientes para muitos aplicativos, e que frameworks grandes como React ou Angular frequentemente introduzem complexidade desnecessária, ferramentas de build e sobrecarga de desempenho — especialmente para equipes pequenas ou UIs simples. Outros contrapõem que os frameworks valem o custo em projetos moderadamente complexos ou de longa duração por imporem estrutura compartilhada, padrões previsíveis e onboarding mais fácil, mesmo adicionando abstração e mudanças frequentes. Vários participantes observam como TypeScript, JSDoc e LLMs mudam novamente os trade-offs, facilitando trabalhar diretamente com a plataforma enquanto ainda se obtém segurança de tipos e suporte à geração de código.

Escopo do Vanilla JS vs Frameworks

  • Muitos concordam que o vanilla JS é viável e agradável para projetos pequenos ou pessoais: menos dependências, sem etapa de build, controle total sobre o navegador “como o framework”.
  • Vários argumentam que o JavaScript moderno (recursos do ES5+) e as Web APIs agora são bons o suficiente para que frameworks pesados muitas vezes sejam desnecessários para CRUD básico e “interatividade pontual”.
  • Outros rebatem que, para qualquer “interface de usuário moderadamente complexa”, abordagens em vanilla tendem a se acumular até virar um framework sob medida, mal documentado, com decisões de design ad hoc.

Trabalho em equipe, Estrutura e Escalabilidade

  • Tema forte: frameworks fornecem convenções compartilhadas, previsibilidade e guardrails para equipes, especialmente à medida que bases de código e número de pessoas crescem.
  • Usar um framework popular simplifica contratação e onboarding; novos desenvolvedores e LLMs já conhecem os padrões.
  • Críticos observam que os próprios frameworks se fragmentam (variantes de React, gerenciadores de estado, sistemas de estilização), então escolher um deles não elimina totalmente a discordância ou a complexidade.

Web Components e Abstrações “Leves”

  • Alguns defendem Web Components e JavaScript vanilla modular como um meio-termo escalável: UIs componentizadas, imports dinâmicos e pools de componentes compartilhados sem ferramentas pesadas.
  • Outros veem as abstrações personalizadas do artigo (incluindo EHTML) como micro-frameworks de fato, adicionando mais uma camada sob medida para aprender.

Sistemas de tipos e Ferramentas

  • Vários comentários promovem TypeScript ou JSDoc/@ts-check para verificação estática, com divergência sobre se uma etapa de build é aceitável ou necessária.
  • Há ceticismo sobre setups “zero build” para apps complexos devido à ausência de minificação/code-splitting e à fragilidade de longo prazo de ferramentas customizadas.

Performance, UX e Escolhas de Arquitetura

  • Debate sobre SPA vs aplicativos multi-página: alguns insistem que MPAs são rápidas com cache adequado; outros dizem que SPAs podem parecer mais ágeis e dinâmicas.
  • Vários criticam o React por adicionar latência e complexidade a UIs que precisam apenas de algumas atualizações no DOM; outros veem o React como uma “parafusadeira elétrica” poderosa para SPAs maiores.

LLMs e o Futuro dos Frameworks

  • Alguns esperam que os LLMs reduzam a necessidade de grandes frameworks, tornando mais fácil trabalhar diretamente com APIs da plataforma ou pequenos helpers.
  • Outros observam que os frameworks funcionam como guardrails para código não determinístico gerado por LLMs e que os LLMs já funcionam bem com stacks populares como React/TypeScript.