O que é um framework?

Imagine que você está construindo um pequeno aplicativo web: contas de usuário, um feed, uma página de configurações. Antes que qualquer uma das suas próprias ideias apareça na tela, você precisa de código que transforme URLs em páginas, código que converse com um banco de dados, código que mantenha as senhas seguras e código que redesenhe a tela quando algo muda. Nada disso é a ideia do seu app. Todo app precisa disso, e a maior parte é igual de projeto para projeto.

Você poderia escrever toda essa infraestrutura você mesmo, e as pessoas faziam isso, por anos. É lento, é onde vivem os bugs mais sutis, e cada equipe acabava com uma versão ligeiramente diferente, e ligeiramente quebrada, do mesmo mecanismo. Um framework é a resposta acumulada para isso: a infraestrutura compartilhada, escrita uma vez e testada por milhares de projetos, empacotada com uma estrutura que indica onde o seu próprio código deve entrar. Você constrói as partes que fazem o seu projeto único; o framework cuida das partes que todo projeto repete.

Frameworks não são uma coisa exclusiva da web. Eles existem em todos os lugares onde programas são construídos, e este capítulo é sobre a ideia em si, em qualquer linguagem e em qualquer área.

O que é um framework (e o que é uma biblioteca)

A palavra é usada de forma solta, então aqui está a distinção que realmente importa, em código:

// Uma biblioteca: seu código está no comando e chama a biblioteca quando é útil.
const label = dateLibrary.format(order.createdAt, "MMM D");

// Um framework: o framework está no comando e chama o código que você conecta a ele.
export default function OrdersPage() {
  return listOfOrders();
}

A primeira linha é você no controle: seu programa roda e ele toma um recurso emprestado para uma tarefa específica. A segunda é diferente por natureza. Você nunca chama OrdersPage diretamente. Você a escreve, coloca no lugar que o framework espera, e o framework a chama no momento certo — neste caso, quando um visitante abre a página de pedidos.

Essa inversão tem um nome: inversão de controle. Com uma biblioteca, o seu código controla o fluxo do programa e toma helpers de empréstimo. Com um framework, é o framework que controla o fluxo, e o seu código preenche as lacunas que ele deixa para você. Um resumo útil: você chama uma biblioteca; um framework chama você.

A mesma lógica aparece em todos os cantos da programação. O Django recebe a requisição web e chama a sua função de view. O Flutter executa o app e pergunta aos seus widgets o que desenhar. A Unity executa o loop do jogo e chama os seus scripts a cada frame. O pytest encontra as suas funções de teste e as executa para você. Áreas diferentes, uma mesma ideia: o framework é dono do motor, e você fornece as peças que ele foi construído para receber.

Se uma imagem ajuda: uma biblioteca é uma caixa de ferramentas ao seu lado enquanto você constrói, e você põe a mão dentro dela sempre que uma ferramenta é útil. Um framework se parece mais com a estrutura de um prédio, já em pé quando você chega. As paredes, a fiação e o encanamento já têm seus lugares definidos, e o seu trabalho entra nos cômodos que tornam o prédio seu. Os dois economizam esforço; a diferença é quem decide a forma da construção.

A estrutura vem com expectativas, e isso é uma vantagem. A maioria dos frameworks pratica a convenção sobre configuração: coloque os arquivos onde o framework espera, nomeie as coisas do jeito que ele espera, e tudo se conecta sozinho, sem código de configuração. O Rails popularizou essa expressão, e a maioria dos frameworks modernos segue alguma versão dela. O ganho é que qualquer desenvolvedor que conheça o framework consegue abrir qualquer projeto construído nele e saber onde procurar. O preço é que as convenções são mais uma coisa a aprender antes que qualquer coisa funcione, e ir contra elas é quase sempre mais doloroso do que seguir.

A inversão de controle muda a forma como você lê e depura um programa. Em um script simples, a pilha de chamadas começa no seu código, e tudo nela é seu. Dentro de um framework, a pilha começa nas profundezas do próprio framework, e as suas funções aparecem como entradas que o framework escolheu chamar: hooks, handlers, métodos de ciclo de vida. A piada antiga descreve isso perfeitamente: "não nos chame, nós te chamamos." Na prática, isso significa que aprender um framework tem menos a ver com a superfície da sua API e mais com o seu timing — quais das suas funções ele chama, quando, e o que espera de volta. Quando o comportamento te surpreende, a resposta geralmente está nesse timing, e a documentação do ciclo de vida do framework é o mapa que vale a pena manter sempre aberto.

JunoFrameworks e bibliotecas Uma biblioteca é uma caixa de ferramentas: o seu programa toma as decisões e pega uma ferramenta quando precisa dela. Um framework se parece mais com a estrutura de um prédio: a construção já está de pé, e você constrói os seus cômodos dentro dela. O resumo que fez isso fazer sentido para mim é que você chama uma biblioteca, mas um framework chama você.

JunoFrameworks e bibliotecas Você chama uma biblioteca; um framework chama você, e essa inversão se chama inversão de controle. Os frameworks combinam isso com convenções: coloque o código onde o framework espera e ele se conecta sozinho. Seguir as convenções, em vez de ir contra elas, é a maior parte da habilidade de usar bem um framework.

JunoFrameworks e bibliotecas A inversão de controle significa que a pilha de chamadas começa no framework, e o seu código aparece como hooks que ele invoca. Então a verdadeira coisa a aprender é o timing: quais das suas funções são chamadas, quando, e o que o framework espera de volta. Depurar uma aplicação baseada em framework é ler o seu ciclo de vida, e quanto antes isso parar de parecer mágica, melhor.

O que um framework te dá, e o que ele custa

O argumento a favor de um framework é concreto. Problemas que te tomariam semanas chegam já resolvidos, e resolvidos por pessoas que enfrentaram primeiro os casos mais difíceis: tratamento de senhas, validação de formulários, roteamento, renderização. O seu projeto ganha uma estrutura que um novo colega de equipe reconhece em minutos, porque é a mesma estrutura de qualquer outro projeto naquele framework. E você herda um ecossistema: plugins, tutoriais, perguntas já respondidas, e um grupo de profissionais que já conhecem bem aquele terreno.

Os custos são igualmente concretos, e merecem o mesmo olhar direto. Um framework é uma dependência grande que você não controla, com os próprios bugs, o próprio ritmo e as próprias opiniões. Existe uma curva de aprendizado antes que a sua primeira página seja renderizada, e parte do que você aprende é conhecimento sobre o framework, não sobre programação em si. O seu código se molda às formas dele, o que torna sair mais difícil quanto mais tempo você fica. E os frameworks mudam: versões importantes chegam, padrões são repensados, e se manter atualizado é um trabalho contínuo que não existia com código simples.

Nenhuma das duas listas ganha por si só. O equilíbrio depende inteiramente do projeto, então a pergunta a fazer sobre qualquer framework é "esse framework torna este projeto mais simples". Um framework justifica o seu lugar quando torna o seu projeto mais simples. Quando isso acontece, use-o com prazer. Quando não acontece, os próximos dois capítulos são sobre reconhecer isso a tempo.

O efeito do ecossistema é o item subestimado do lado positivo. Em um framework maduro, a chance de o seu problema ser novo é próxima de zero: autenticação, upload de arquivos, envio de e-mail, deploy — alguém já empacotou ou documentou cada um deles. Isso transforma muitos dias de construção em horas de montagem. O item espelhado do lado negativo é que essa fluência fica denominada em termos do framework: parte do que você sabe é "como o Django faz isso", em vez de "como servidores web funcionam". Fique atento à ideia geral por trás de cada conveniência, que é justamente para isso que esta documentação existe.

Dois custos só aparecem em produção. Primeiro, as abstrações vazam: a superfície conveniente do framework esconde a mecânica real, e no dia em que essa "mágica" se comporta mal, você acaba depurando a mecânica de qualquer jeito, agora através de uma camada extra que você não escreveu. Reserve tempo para entender o que o seu framework faz por debaixo dos panos, porque eventualmente você vai precisar disso. Segundo, a esteira de atualizações é um item de custo real: migrações de versão importante em uma base de código grande podem consumir semanas, e pular essas migrações silenciosamente se transforma em problemas de segurança não corrigidos. Pese os dois lados contra a alternativa de código simples, que tem menos peças em movimento e nada para migrar, mas reabre todo problema já resolvido para você resolver de novo, por sua conta e risco. Essa troca é o assunto de Escolhendo e aprendendo um framework.

JunoO que os frameworks dão e custam Um framework te entrega problemas resolvidos, uma estrutura reconhecível e todo um ecossistema de ajuda. Em troca, você assume uma dependência grande, uma curva de aprendizado, e o jeito próprio dele de fazer as coisas. Os dois lados são reais, então a pergunta a levar com você é se ele torna o seu projeto específico mais simples. Às vezes a resposta é um sim feliz, e às vezes código simples é o caminho mais tranquilo!

JunoO que os frameworks dão e custam O ecossistema é a metade subestimada da troca: em um framework maduro, quase nenhum problema que você encontra é novo. Mesmo assim, continue percebendo a ideia geral por trás de cada conveniência, ou o seu conhecimento se torna "como esse framework faz isso" em vez de como a coisa realmente funciona. O framework deveria tornar o projeto mais simples; esse é o teste inteiro.

JunoO que os frameworks dão e custam Dois custos te cobram depois: as abstrações vazam, então um dia você depura a mecânica do framework através de uma camada que você não escreveu, e migrações de versão importante são trabalho real que não pode ser postergado para sempre. Calcule isso desde o início, ao lado do próprio preço do código simples, que é resolver de novo problemas que o framework já tinha resolvido. Eu já paguei as duas contas; nenhuma delas é divertida, e nenhuma é motivo para dogmatismo.

Para onde ir a partir daqui

Com a ideia estabelecida, a próxima pergunta natural é o que realmente existe por aí: Os tipos de frameworks percorre as principais famílias, da web aos jogos e aos testes, com as opções mais populares em cada uma. Depois disso, Escolhendo e aprendendo um framework entra na prática de escolher um, aprender um, e saber quando você não precisa de nenhum. E se os exemplos de JavaScript acima pareceram estranhos, a trilha de JavaScript cobre a linguagem em si, o que é o primeiro passo certo antes de qualquer framework construído sobre ela.