O que é framework e quando ele ajuda (ou atrapalha) seu projeto

“Framework é a mesma coisa que biblioteca?” Não, e a diferença está em quem manda no seu código. Numa biblioteca, você chama as funções quando quer. Num framework, é ele que chama o seu código no momento certo, seguindo uma estrutura que já vem pronta.

Martin Fowler descreve isso como inversão de controle, o famoso princípio de Hollywood: “não nos ligue, nós ligamos para você”. No Django, por exemplo, você não escreve o laço que fica esperando requisições. Você escreve uma função que recebe a requisição e devolve uma resposta, e o framework decide quando executá-la.

Essa troca (perder liberdade para ganhar estrutura) é ótima em muitos projetos e péssima em alguns. Os erros abaixo são os que mais aparecem quando alguém adota um framework sem entender essa troca.

Achar que React, Django e Lodash são a mesma categoria

Muita gente chama tudo de framework, e isso gera confusão na hora de estudar e de conversar em entrevista.

O caso do React é o que mais rende discussão. A documentação oficial do React se apresenta como biblioteca para interfaces, e a própria equipe recomenda usar um framework como o Next.js para apps completos. Na prática, o mercado chama o ecossistema inteiro de “framework front-end”, e tudo bem usar a palavra no dia a dia. Só não erre isso numa entrevista técnica em que perguntem a diferença.

Escolher pelo ranking em vez do problema

O custo aqui aparece meses depois. Alguém vê que um framework está no topo de uma pesquisa e decide usá-lo num projeto que não combina com ele.

Um exemplo comum: um site institucional de cinco páginas, que muda duas vezes por ano, montado com um framework de aplicação completo, com build, servidor Node e dezenas de dependências. Um HTML estático ou um gerador de sites simples resolveria com hospedagem gratuita e quase nenhuma manutenção. O framework não estava errado; o problema era pequeno demais para ele.

O caminho inverso também acontece: um sistema interno com login, permissões, painel administrativo e relatórios, escrito “na mão” porque “framework é pesado”. Seis meses depois, o time reescreveu metade do que o Django ou o Laravel dariam prontos, com mais bugs.

Pular a linguagem para ir direto ao framework

É o erro mais caro para quem está aprendendo, e o mais frequente. A pessoa aprende React antes de entender funções, arrays e map em JavaScript, ou aprende Django sem saber o que é uma classe em Python.

Funciona por algumas semanas, copiando tutoriais. Aí aparece um erro que não está no tutorial, e não há base para entender a mensagem. Pior: a pessoa não sabe se o problema é da linguagem, do framework ou do próprio código. Uma regra que costuma funcionar: antes de um framework, consiga escrever um pequeno programa só com a linguagem, como uma lista de tarefas no terminal ou uma página com JavaScript puro que consome uma API.

Brigar com as convenções em vez de aprender com elas

Frameworks como Rails, Django e Laravel funcionam por convenção: a pasta tem nome certo, o arquivo fica num lugar certo, a tabela do banco segue um padrão de nome. Quem chega de outro jeito de trabalhar tenta reorganizar tudo “do meu jeito” e passa a lutar contra a ferramenta.

O custo é duplo. Você perde o benefício (outro dev que conhece o framework entenderia seu projeto em minutos) e ganha trabalho extra para configurar o que viria pronto. Se as convenções incomodam muito, talvez o framework escolhido não seja para você, e trocar é mais honesto do que deformar.

Um bom teste antes de adotar: abra o tutorial oficial do framework e tente terminá-lo em uma tarde. Se você trava em conceitos da linguagem, e não do framework, ainda é cedo.

Ignorar o custo de atualizar

Todo framework lança versões novas, e algumas quebram compatibilidade. Quem adota um framework assina, sem perceber, um contrato de manutenção.

• Verifique se o framework tem versões de suporte longo (LTS) e por quanto tempo cada uma recebe correções de segurança. O Django, por exemplo, publica esse calendário na documentação oficial em português.
• Leia o guia de migração da última versão grande antes de adotar. Se ele é enorme, as próximas também serão.
• Conte quantas dependências o projeto inicial já traz. Cada uma é algo que pode ficar desatualizado.
• Veja se a comunidade é ativa: perguntas respondidas, issues fechadas, lançamentos recentes.

Projetos que ficam três ou quatro anos sem atualizar o framework chegam num ponto em que a atualização vira um projeto inteiro. É bem comum empresa manter sistema antigo em versão sem suporte justamente porque ninguém quis pagar essa conta aos poucos.

Tratar o framework como caixa-preta para sempre

No começo, é normal não saber o que acontece por baixo. O problema é continuar sem saber depois de um ano de uso.

Quando a aplicação fica lenta, quem não entende como o ORM do framework monta as consultas SQL não consegue achar a causa. Um caso clássico é o problema N+1: uma página que lista 50 pedidos e, para cada um, faz uma consulta separada para buscar o cliente, totalizando 51 consultas onde bastaria uma ou duas. O framework permitiu, mas não avisou. Saber ler o SQL gerado, usar as ferramentas de depuração e abrir o código-fonte de vez em quando separa quem usa o framework de quem domina o framework.

Como olhar o SQL que o ORM gera

No Django, a ferramenta django-debug-toolbar mostra cada consulta feita por página, com tempo e quantidade. No Laravel, o Debugbar cumpre o mesmo papel. Se uma página simples faz dezenas de consultas, use os recursos do próprio ORM para carregar os relacionamentos de uma vez (select_related e prefetch_related no Django, with() no Laravel).

Quando o framework atrapalha de verdade

Não adotar framework também é uma decisão válida, e há situações em que ela é a melhor:

• Scripts e automações pequenas, que rodam uma vez por dia e cabem em 100 linhas.
• Bibliotecas que você vai publicar para outras pessoas usarem dentro dos frameworks delas.
• Projetos com requisito extremo de desempenho ou de tamanho, como código embarcado.
• Protótipos para aprender um conceito, quando o framework esconderia justamente o que você quer entender.

Para quem quer ver como os sites atuais combinam essas peças, este panorama de estruturas e frameworks usados em sites modernos mostra exemplos de arquitetura real. E se algum termo deste texto ficou nebuloso, o glossário de programação do buildbase tem as definições curtas lado a lado.

A escolha que costuma acertar para quem está começando

Escolha um framework popular da linguagem que você já sabe, com documentação boa e vagas no seu mercado, e fique nele por pelo menos um projeto completo. Para Python, Django ou FastAPI. Para JavaScript, React com Next.js. Para PHP, Laravel. Para Java, Spring Boot.

O que você aprende no primeiro (rotas, camadas, ORM, testes, configuração por ambiente) se transfere quase inteiro para o segundo. Trocar de framework a cada mês dá a sensação de progresso, mas é o jeito mais lento de ficar bom em qualquer um deles.