Web Vanilla Pura

 (plainvanillaweb.com)
2 pontos por GN⁺ 2025-05-12 | 1 comentários | Compartilhar no WhatsApp
  • Explica as técnicas básicas de desenvolvimento web usando apenas HTML, CSS e JavaScript
  • Apresenta como implementar sites e aplicações somente com tecnologias web padrão, sem ferramentas de build nem frameworks
  • Aborda formas de estruturar e estilizar usando Web Components e recursos modernos de CSS
  • Busca um ambiente de desenvolvimento simples e benefícios de longo prazo, sem a complexidade dos frameworks nem o peso da manutenção
  • Tutorial voltado principalmente para desenvolvedores que já dominam tecnologias web padrão

Visão geral da Web Plain Vanilla

Uma visão geral das principais técnicas para criar sites e aplicações apenas com tecnologias web padrão, sem ferramentas de build nem frameworks, no desenvolvimento web

  • Descreve um ambiente que utiliza apenas editor, navegador e padrões web
  • Apresenta uma estrutura que permite implantação em produção sem configuração inicial nem lógica no lado do servidor

Tópicos abordados

1. Componentes (Components)

  • Mostra como usar Web Components para compor elementos de alto nível apenas com HTML, JavaScript e CSS
  • Mostra uma forma de substituir a abordagem de componentes de frameworks como React ou Vue

2. Estilização (Styling)

  • Mostra como aproveitar o poder do CSS moderno para substituir as conveniências oferecidas por CSS Modules, PostCSS e SASS
  • Apresenta o conceito de uma organização de estilos estruturada e modular, indo além do CSS clássico

3. Sites (Sites)

  • Mostra como estruturar projetos web com base em Web Components e fazer o deploy sem ferramentas de build nem servidor
  • Apresenta um fluxo de deploy prático e simples

4. Aplicações (Applications)

  • Mostra como criar aplicações web de página única usando apenas técnicas vanilla
  • Explica abordagens de roteamento e gerenciamento de estado

Público recomendado

Destinado a desenvolvedores que já conseguem trabalhar razoavelmente com HTML, CSS e JavaScript

  • Para quem está começando em desenvolvimento web, recomenda percursos de aprendizado básico como Odin Project ou MDN

Por que a abordagem vanilla

Os frameworks modernos oferecem rapidamente estrutura e recursos poderosos, mas vêm acompanhados do aumento da complexidade das ferramentas e dos frameworks, além de uma carga constante de manutenção

  • A abordagem Plain Vanilla abre mão de parte da conveniência de curto prazo em troca de simplicidade e do benefício de longo prazo de uma manutenção praticamente zero
  • Os navegadores atuais tornam essa abordagem realmente viável graças ao excelente suporte aos padrões web de hoje

Leituras relacionadas

1 comentários

 
GN⁺ 2025-05-12
Opiniões do Hacker News

  • Eu já saí da discussão "vanilla ou framework" e hoje penso mais em: "isso realmente precisa de um site?"
    Quando você começa a ficar cético sobre a necessidade real de uma interface web, especialmente em webapps e no universo de SaaS B2B, descobre que dá para levar o negócio bastante longe sem sequer mexer no navegador
    A maior parte do tempo que gastei criando sites e apps foi em UI/UX administrativa, isto é, fazer o administrador alterar campos no banco de dados para que a aplicação se comporte de acordo com a expectativa do cliente
    Em muitos casos, é muito mais rápido, simples e com menos trabalho inútil entregar ao negócio apenas um template de configuração (como uma planilha Excel) e inserir/mesclar o resultado diretamente em tabelas SQL
    A web oferece apenas um tipo de UI/UX. E-mail ou arquivos de texto puro às vezes são mais flexíveis

    • Vejo com frequência consultorias digital-first sendo pouco ágeis no B2B por insistirem em construir webapps bonitinhos sem necessidade
      Especialmente em órgãos públicos, os compradores muitas vezes não entendem direito o que estão adquirindo e acabam pagando caro demais
      Os responsáveis por compras precisam ser mais bem instruídos sobre o que realmente é necessário
    • Eu vendo urnas funerárias online. Meu site só tem um link de e-mail. Não tem carrinho de compras
      Uma loja física de urnas não tem carrinho, então por que a loja virtual precisaria ter?
      Quando comprei ferramentas especializadas de marcenaria online, apenas preenchi um formulário e recebi as peças com a fatura; se eu quisesse, nem precisava pagar na hora
      Existem muitos formatos de comércio, online e offline, e, se você observar com atenção como as pessoas vivem de formas interessantes, vai encontrar isso por toda parte
    • Para ferramentas internas que mal passam de CRUD, a web é mais útil quando um consultor externo vai fazer tudo de uma vez, ou quando a equipe interna não tem como cuidar disso para sempre
      Com um mínimo de capacidade de manutenção, um template de Excel + um script simples e customizado acaba sendo muito mais flexível.
      É especialmente eficaz quando o usuário final já é o tipo de pessoa que lida com dados brutos de qualquer forma
    • No B2B, antes do SaaS, era 100% assim que se operava
      E ainda hoje 99% do B2B funciona desse jeito

  • Não sou contra frameworks. Só acho que em muitos casos eles são desnecessários
    Sempre me perguntei por que eu deveria adicionar 100 KB de JS antes mesmo de escrever uma linha de código
    Eu e minha equipe construímos o https://restofworld.org sem nenhum framework
    Pesquisas, outreach e feedback por e-mail foram extremamente positivos em termos de usabilidade e experiência de leitura
    Talvez usemos um framework mais tarde, mas por enquanto JS vanilla continua servindo muito bem

    • Este comentário é um bom exemplo da desconexão que sempre aparece nessas discussões
      De um lado, há pessoas construindo grandes webapps em equipes de 30+ pessoas, e basta alguém dizer que fez sem framework para surgir imediatamente uma enxurrada de dúvidas sobre como lidou com funcionalidades essenciais em grande escala
      Mas a resposta é que essas funcionalidades nem são necessárias, porque estamos falando de algo como um blog, então nem havia necessidade de framework desde o início
      Por outro lado, quem nunca teve experiência com webapps realmente grandes acaba pensando: "por que as pessoas usam frameworks?"
      A web é, de fato, um conjunto extremamente diverso de softwares.
      Então, ao discutir frameworks, acho que é preciso deixar claro de que tipo de software estamos falando
      Neste caso, isto é um blog em WordPress
    • A página é ótima e carrega bem, mas isso não tem relação com a abordagem descrita no TFA
      Ela usa WordPress, que é um grande framework, e apenas está sendo renderizada de forma estática
      O TFA fala de não usar ferramenta de build nenhuma, apenas padrões modernos da web. Só editor, navegador e padrões web
    • "Por que adicionar 100 KB de JS antes de escrever uma linha de código?"
      Nos apps corporativos em que trabalhei, 100 KB nunca foi uma preocupação
      A maioria eram apps grandes feitos por várias equipes, usando React etc.
      Em Lob/B2B, ninguém liga para o carregamento inicial da página
      Os usuários usam o app todos os dias e, na maior parte do tempo, os assets estáticos já vêm direto do cache do navegador
      Se você usa um framework inteligente como Next.js, o conteúdo é separado em chunks imutáveis por rota
      O render inicial é HTML estático, então o usuário nem percebe a hidratação
    • O site é bonito. Também encontrei bons artigos nele
      Mas, na discussão entre vanilla e framework, sempre que aparece um exemplo desses é um site de notícias/artigos, então penso: "eu nem teria usado framework nisso desde o começo"
      No fim, exemplos reais de uso precisariam ser apps mais interativos
      Hoje em dia prefiro usar apenas o framework e padrões consistentes, minimizando outras dependências
    • Uma das vantagens dessa estrutura é que o histórico de avançar/voltar do navegador fica muito rápido
      No iPhone, eu já estava acostumado demais a voltar e ver a página inteira recarregar sempre
    • Parabéns! Acho que garantir a usabilidade é o mais importante
      Mas desenvolvedores vivem obcecados, por diversão, com telas de loading, componentes hidratados, animações excessivas e modais irritantes
    • Não sei se isso ocorre por não usar framework, mas ao navegar para trás/para frente a URL muda na hora e a página não atualiza, então você continua no mesmo artigo
      Além disso, scroll infinito é péssimo para usabilidade, porque dificulta acompanhar onde você está pela posição da barra de rolagem
    • Rest of World funciona muito rápido até aqui na Austrália e é um site de notícias fantástico, que eu não conhecia.
      Parabéns por ter participado da construção
    • É a estética de gerar páginas estáticas com WordPress
    • A maioria dos frameworks não precisa de 100 KB de JS
      No caso de Mithril, por exemplo, dá para ter tudo em 10 KB compactados com gzip
    • O problema dos exemplos vanilla é que as páginas costumam ser simples demais e a UX geralmente traz só o básico
      Se eu pensar em implementar manualmente uma tabela reativa com busca, formulários com rótulos, validação e erros bem feitos, por que eu faria isso do zero se posso usar uma biblioteca de UI em Svelte e um produto bem validado com só 25 KB de overhead?
    • A imagem principal tem mais de 200 KB, então a discussão sobre 100 KB não significa muito
      E WordPress também é um framework
      Usar framework não torna algo lento. Nem WordPress, nem qualquer outra coisa
    • Este é um bom exemplo da obesidade da web moderna
      Rápido demais
    • Rápido de verdade!
    • Gosto muito do Rest of World
    • "Por que adicionar 100 KB de JS?"
      Por produtividade do desenvolvedor, em teoria.
      Na prática, muitas vezes nem ajuda tanto assim
    • O site é realmente rápido. Já vi esse tipo de jornalismo antes
      Fico curioso se essa abordagem teve algum problema mais sério
    • O quê? Isso é impossível
    • Ninguém liga para 100 KB

  • Estou desenvolvendo um sistema para cerca de 2 mil usuários, e eles não se importam nem um pouco com UI reativa
    O melhor é fazer um monólito, não se preocupar com refresh de página e simplesmente focar em concluir o trabalho

    • Como contraponto, muitos aplicativos desktop tradicionais acabaram migrando para a web
      A motivação em geral nem foi tão técnica, mas sim o custo alto demais de distribuir apps nativos
      A web oferece um padrão barato de distribuição de aplicações, mas a tecnologia de UI continua ruim
      No passado houve várias tentativas meio capengas, como X11, Java e Flash, e espero que um dia apareça um jeito mais confortável de desenvolver webapps
    • Só com CSS @view-transition já dá para fazer transições suaves
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • Nos dias de hoje, isso é uma opinião boooa demais
      A maior parte do software é muito mais lenta e menos responsiva do que dispositivos mecânicos de 120 anos atrás
    • Só com CSS e JS já dá para fazer facilmente uma dinâmica super simples de refresh
      Não precisa puxar pacote npm nenhum
    • A separação entre React e o servidor também é uma bagunça
      O backend fica em express/node, o código inteiro fica junto, mas no ambiente de desenvolvimento o servidor roda como o servidor padrão do React, e em produção roda de outro jeito, então você acaba precisando de um modelo esquisito de build e operação que anula a conveniência do servidor de dev, como hot reload
    • Já vivi mais SPAs quebradas do que MPAs
      Até SPAs de grandes empresas como Reddit e X (Twitter etc.) foram instáveis demais no mobile
      A menos que você seja do tamanho do Twitter, ou tenha uma plataforma centrada em API, acho que não há motivo para insistir em SPA
      Se nem empresas de dezenas de bilhões fizeram isso direito, é perigoso achar que eu farei melhor
    • A vantagem da abordagem vanilla é que ela também permite evoluir sites SSR já existentes
      Não é preciso reescrever tudo em React
      Os recursos mais avançados, no estilo SPA, citados pelo autor original são opcionais
    • Usuários pragmáticos não ligam, mas usuários que vão clicando sem pensar acabam apertando o botão voltar em vez de esperar para retornar ao feed principal, e esse timing costuma ser mais rápido do que baixar o framework mais recente via CDN
    • Se o refresh da página for realmente muito rápido, aí eu concordo com essa opinião
    • Eu gostaria de saber como você concluiu que os usuários realmente não se importam com refresh de página
      Você chegou a investigar também quem abandonou o sistema?

  • Eu queria viver num mundo assim
    Venho da era pré-framework, quando tudo ainda era imaturo e era comum encontrar gente que só sabia jQuery
    Hoje, sinto que o custo-benefício dos frameworks do pós-query selector já não é tão grande assim, embora frameworks de teste sejam outra história e sejam ótimos
    Estamos presos numa prisão de frameworks do React, e todo fracasso é resultado de uma complexidade espaguetificada
    Máquinas de estado viram gambiarras hardcoded, e os artefatos traduzidos, minificados e transpilados ficam difíceis de reconhecer
    Source maps são mais uma camada de complexidade para manutenção
    Entendo por que os frameworks foram criados, mas me custa imaginar que seguir aprendendo frameworks seja mais fácil para novos engenheiros do que aprender JS vanilla

    • Também vivi essa época antiga, e o maior problema foi termos decidido construir um ecossistema de apps em cima de um formato de documento
      HTML era só uma marcação feita para facilitar um pouco a renderização de texto, e HTTP também era assim
      No passado, a proporção texto/marcação precisava ser alta, mas agora isso se inverteu completamente
      Mesmo assim, resolvemos empilhar todo o desenvolvimento de apps em cima disso, como se fosse o futuro, e basta olhar para dentro do React para ver décadas de truques e remendos
      No passado, seria como tentar fazer apps com Excel+VB ou com PDF+PostScript, algo totalmente absurdo
      Talvez por isso consumir megabytes de JS pareça tanto um exagero
    • Para mim, o grande killer app hoje é a reatividade
      Quando os dados mudam e a UI reage na hora, se eu tiver de fazer listeners manualmente, diff de atualização e ainda limpar eventos, parece quase gerenciamento manual de memória
      Na era do jQuery era assim, e havia muitos erros
      Quando for possível modularizar a view de forma declarativa e baseada em componentes com JS vanilla, aí talvez eu volte, mas por enquanto acho totalmente inviável
      Falta um fator decisivo
    • Eu também às vezes me pergunto se isso é só nostalgia embebida em princípios como KISS
      React e Angular claramente faziam sentido antes do ES2015
      Depois disso, cansei da constante mudança nos frameworks de frontend
      Até dentro do React, a forma de fazer componentes e gerenciar estado vive mudando
    • Se você opera um serviço com centenas de milhões de visualizações, imagino que na prática a estrutura real fique muito mais próxima de um site estático

  • Eu ainda não compro a ideia de Web Components
    Mesmo com recursos recentes como @scoped, import {type:css} e afins, continuo achando muito mais sensato renderizar os elementos estaticamente e depois atualizá-los dinamicamente com JS moderno
    Sou cético em relação à maioria das abordagens com Web Components e sigo acreditando que precisamos inovar fora de frameworks como React/Svelte
    Nunca senti que Web Components fossem úteis nos vários sites que mantenho

    • Web Components não resolvem meus problemas; na verdade, adicionam novos problemas
      A questão do Shadow DOM aparece dezenas de vezes por página, mas na maior parte dos casos isso só resolve problemas criados pela própria adoção dele
      Meus componentes são específicos do meu app, então eu nem tenho problema de Shadow DOM
    • "Renderizar elementos estaticamente + atualizar dinamicamente com JS moderno"
      Fico curioso sobre como Web Components tratariam isso no backend
    • Web Components fornecem um limite de abstração bem claro
      Você pode adicionar métodos extras à sua própria tag e encapsular a lógica de atualização dentro do componente
    • Acho que precisamos voltar ao Unobtrusive JS
      Precisamos de práticas que priorizem bibliotecas leves ou código que possamos escrever nós mesmos
      HTMX tem coisas boas, mas ainda se comporta como uma tag script; seria suficiente deixar URL/método claramente no HTML e coisas como hx-target só em atributos data- definidos pelo JS
      Não quero carregar todos os recursos do HTMX que não vou usar

  • Não acho que Web Components sejam substitutos para o que outros frameworks chamam de componentes
    Não dá para passar valores compostos (Object, Array etc.) por atributos, há boilerplate demais e não existe reatividade
    Eu programo em um estilo vanilla JS usando signals[1]
    Nem todo padrão W3C é a resposta certa, e convém lembrar do fracasso do XHTML
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

  • Isso parece uma abordagem bem adequada para quem faz páginas web como hobby
    Frameworks servem para padronização, para embutir boas práticas no desenho e para acelerar o início do desenvolvimento
    O site em si não tem valor intrínseco; o que importa é como expor seu conteúdo com eficiência e desenvolver a coisa certa no prazo
    Nesse sentido, frameworks reduzem custos atuais e futuros

    • Essa é a "narrativa oficial", mas na prática nem sempre é verdade
      Em grandes empresas, as decisões muitas vezes são guiadas por moda, hábito e uma postura defensiva em torno dos frameworks populares; a perda de produtividade causada pela complexidade extra não é acompanhada, e decisões erradas acabam até alinhadas com os incentivos pessoais ou do time
      Ou seja, não dá para justificar a escolha de framework dizendo que "só pode ser a decisão racional"
    • Também já vi muitos projetos feitos com React e frameworks relacionados que estavam longe de ser bem gerenciados
      Usar framework não garante automaticamente boas práticas e, na verdade, pode acabar gerando sistemas ainda mais inchados e lentos

  • Material realmente excelente
    Acho que, se você vai desenvolver para a web, precisa conhecer bem os fundamentos e saber aproveitar ao máximo a plataforma web
    Depois disso, usar ou não sistema de build/framework passa a ser uma escolha livre, desde que você entenda os trade-offs
    Pessoalmente, gosto de Remix (/React-router v7+) porque ele dialoga com a filosofia dos padrões web
    Ou seja, você consegue fazer mais com menos desenvolvimento, inclusive alterar dados do servidor usando apenas formulários HTML
    Também recomendo https://every-layout.dev, onde dá para aprender várias técnicas de layout de alta performance, acessíveis e flexíveis usando apenas CSS nativo do navegador
    Trabalho profissionalmente com desenvolvimento web desde 1998

  • Na semana passada implementei um projeto pequeno totalmente em vanilla e está funcionando muito bem
    É uma ferramenta web para escrever threads longas no Mastodon
    Durante todo o desenvolvimento, eu ficava pensando: "será que estou fazendo algo errado por não usar framework?"
    Parece que todo mundo espera frameworks hoje em dia
    Splinter, splinter.almonit.club, para quem quiser dar uma olhada