A Web Pesou Demais: Um Manifesto pelo Código Essencial

A gente precisa conversar sobre peso.

Sabe aquele projeto que começou simples — um site de uma página, um portfólio, uma landing page — e agora tem 200MB de node_modules? Aquele bundle de JavaScript que demora 8 segundos para carregar no celular do seu cliente? Pois é. A gente fez isso. Juntos.

Não foi maldade. Foi hábito.

O Paradoxo que Ninguém Quer Admitir

Vamos observar um padrão curioso no nosso meio.

O desenvolvedor iniciante cria um site limpo. HTML na mão, CSS em um arquivo, aquele JavaScript inline básico. O site abre rápido. Funciona em qualquer lugar. A manutenção é trivial.

Aí começa a "jornada". A gente descobre os frameworks. Instala o npm. Cria o projeto com o CLI da moda. E antes de escrever uma única lógica de negócio, já estamos configurando build tools, resolvers, loaders, plugins.

Resultado? Um site institucional que precisa de 47 dependências para renderizar texto e imagens.

O pior? Às vezes a gente faz isso por medo. Medo de parecer "atrasado". Medo de não estar usando as ferramentas "certas". Medo de parecer iniciante porque escolheu resolver um problema com 20 linhas de código em vez de importar uma library.

Código complexo não é sinal de experiência. Às vezes é só sinal de que a gente não parou pra pensar.

Por Que Voltar ao Básico Não é Nostalgia

Espera. Não estou pedindo pra você abandonar tudo e voltar a tables para layout.relaxem.

Estou pedindo pra fazer a pergunta certa antes de qualquer coisa:

"Esse projeto realmente precisa de um framework?"

Para muitos projetos, a resposta honesta é: não.

Um site institucional. Um blog pessoal. Uma documentação. Uma landing page de produto. Um portfólio criativo. Essas coisas não têm estado complexo. Não precisam de virtual DOM. Não precisam de hidratação.

O que elas precisam:

• Carregar rápido — Seu usuário não quer esperar
• Funcionar sempre — Mesmo com JavaScript desativado
• Ser encontrado — Google prioriza performance
• Ser mantido — Por você, daqui a dois anos, sem документация

HTML5 evoluiu. CSS virou uma linguagem de verdade com variáveis, grid, flexbox. JavaScript (agora ES2024+) tem funcionalidades que antes precisavam de libraries inteiras.

A tríade original nunca foi tão poderosa. A gente só esqueceu de olhar pra ela.

Mãos à Obra: Minimalismo Prático

Teoria é bonita. Vamos ao que importa: como fazer isso no dia a dia?

Comece Pelos Manuais

Sim, eu sei. As specs da W3C parecem escritas por máquinas para máquinas.relaxem.

Mas são a fonte da verdade. Quando a gente para de depender de tutoriais datados e Stack Overflow de 2012, a gente descobre que o browser já faz muito mais do que a gente imaginava.

Não precisa ler tudo. Busca o que você precisa. Usa como referência. O domínio real vem daqui.

Antes do npm install

Pare. Respira. Faz três perguntas:

1. Consigo fazer isso com o que já tenho? Às vezes 10 linhas de CSS resolvem o que uma library de 50KB faria.

2. Quanto isso vai custar? Bundle size importa. Cada KB que você adiciona é tempo de carregamento no celular de alguém.

3. Quem mantém isso? Library abandonada é vulnerabilidade esperando acontecer.

Dependencies são ferramentas. Precisam ser escolhidas, não acumuladas.

Performance Não é赛后

Na NameOcean, a gente vê muitos projetos onde performance é uma reflexão tardia. "Vamos otimizar depois do lançamento."

O problema? "Depois" nunca chega.

Código minimalista é performático por design. Menos bytes para transferir. Menos parse para o browser. Menos complexidade para debugar.

Se você escreve menos código, você precisa otimizar menos.relaxem.

Publique, Mesmo Imperfeito

Aqui vai um segredo: nada força qualidade como responsabilidade pública.

Quando seu código está no GitHub ou, melhor ainda, já no ar em algum servidor, você pensa duas vezes antes de empilhar workarounds. Você documenta. Você considera acessibilidade. Você simplifica para poder explicar.

Shippar algo real é a melhor disciplina que existe.

E os Frameworks?

Preciso ser claro aqui: esse texto não é um ataque a React, Vue, Next.js ou qualquer outro framework.

Esses ferramentas existem porque resolvem problemas reais. Aplicações com estado complexo, interfaces dinâmicas, equipes grandes — frameworks fazem sentido nesses contextos.

O que eu questiono é o modo automático. A escolha por default. O "todo projeto novo = novo framework" sem pensar.

Escolha conscientemente. Escolha porque entendeu o tradeoff. Escolha porque o projeto realmente precisa.

Não escolha porque todo mundo escolhe. Não escolha por inércia.

A Verdade Nua

Minimalismo em desenvolvimento web não é minimalismo por minimalismo. Não é preguiça disfarçada. Não é rejeitar ferramentas modernas.

É domínio suficiente para saber o que você realmente precisa. É confiança para escolher o caminho mais simples quando ele é suficiente. É disciplina para resistir à tentação de adicionar "só mais uma dependência".

Código elegante não é código clever. Código elegante é código que faz exatamente o que precisa, sem peso extra.

Domine os fundamentos. Questione o que você assume como necessário. Escreva menos, mas escreva melhor.

Seu usuário vai sentir a diferença. Seu eu do futuro também vai agradecer.

E você, onde anda pesando demais seus projetos? Me conta nos comentários.