O que é um framework?

docs.scrimba.com

Digamos que você está construindo um pequeno aplicativo web: contas, um feed, uma página de configurações. Antes de qualquer ideia sua aparecer na tela, você precisa de código que transforme URLs em páginas, código que fale 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 maioria é a mesma de projeto para projeto.

Você poderia escrever toda essa encanação você mesmo, e as pessoas fizeram, por anos. É lento, é onde os bugs sutis vivem, e cada equipe acabava com uma versão ligeiramente diferente e ligeiramente quebrada da mesma maquinaria. Um framework é a resposta acumulada: a encanação compartilhada, escrita uma vez e endurecida por milhares de projetos, empacotada com uma estrutura que te diz onde seu próprio código vai. Você constrói as partes que tornam seu projeto o seu; o framework lida com as partes que todo projeto repete.

Frameworks não são uma coisa 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 qualquer campo.

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.
export default function OrdersPage() {
  return listOfOrders();
}

A primeira linha é você direcionando: seu programa roda, e ele pede emprestada uma ferramenta para um trabalho. A segunda é diferente em tipo. Você nunca chama OrdersPage você mesmo. Você a escreve, coloca onde o framework espera, e o framework a chama no momento certo, aqui, quando um visitante abre a página de pedidos.

Esse flip tem um nome: inversão de controle. Com uma biblioteca, seu código controla o fluxo do programa e pede ferramentas emprestadas. Com um framework, o framework controla o fluxo, e seu código preenche os espaços em branco que ele deixa para você. Uma forma útil de resumir: você chama uma biblioteca; um framework chama você.

A mesma forma aparece em todos os cantos da programação. Django recebe a solicitação web e chama sua função de view. Flutter executa o app e pergunta a seus widgets o que desenhar. Unity executa o game loop e chama seus scripts a cada frame. pytest encontra suas funções de teste e as executa para você. Campos diferentes, uma ideia: o framework possui o mecanismo, e você fornece as partes para as quais foi construído.

Se uma imagem ajudar: uma biblioteca é uma caixa de ferramentas ao seu lado enquanto você constrói, e você pega uma ferramenta sempre que ela é útil. Um framework é mais como o quadro de um edifício, já de pé quando você chega. As paredes, fiação e encanação têm seus lugares, e seu trabalho vai para os quartos que tornam o edifício seu. Ambos economizam seu esforço; a diferença é quem decide a forma da construção.

A estrutura vem com expectativas, e isso é um recurso. A maioria dos frameworks pratica convenção sobre configuração: coloque arquivos onde o framework espera, nomeie as coisas como ele espera, e tudo se conecta sozinho sem código de configuração. Rails popularizou a frase, e a maioria dos frameworks modernos segue alguma versão dela. O benefício é que qualquer desenvolvedor que conhece o framework pode abrir qualquer projeto construído nele e saber onde procurar. O preço é que as convenções são uma coisa a mais para aprender antes que qualquer coisa funcione, e lutar contra elas é quase sempre mais doloroso do que segui-las.

A inversão de controle muda como você lê e depura um programa. Em um script simples, a pilha de chamadas começa em seu código e tudo nela é seu. Dentro de um framework, a pilha começa profundamente nos internals do framework, e suas funções aparecem como entradas que o framework escolheu chamar: hooks, handlers, métodos de ciclo de vida. A piada antiga descreve exatamente: "não nos chame, nós chamaremos você." Na prática, isso significa que aprender um framework é menos sobre sua superfície de API e mais sobre seu timing, qual de suas funções ele chama, quando, e o que espera de volta. Quando o comportamento o surpreende, a resposta geralmente vive nesse timing, e a documentação do ciclo de vida do framework é o mapa que vale a pena manter aberto.

JunoFrameworks e bibliotecas Uma biblioteca é uma caixa de ferramentas: seu programa comanda o espetáculo e pega uma ferramenta quando precisa. Um framework é mais como o quadro de um edifício: a estrutura já está de pé, e você constrói seus quartos dentro dela. O resumo que me fez entender foi que você chama uma biblioteca, mas um framework chama você.

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

JunoFrameworks e bibliotecas A inversão de controle significa que a pilha de chamadas começa no framework e seu código aparece como hooks que ele invoca. Então a coisa real para aprender é timing: qual de suas funções é chamada, quando, e o que o framework espera de volta. Depurar um app framework é ler seu ciclo de vida, e quanto mais cedo isso deixa de parecer magia, melhor.

O que um framework traz para você e o que custa

O caso para um framework é concreto. Problemas que levariam semanas para você resolver chegam já resolvidos, e resolvidos por pessoas que enfrentaram os casos extremos primeiro: tratamento de senhas, validação de formulários, roteamento, renderização. Seu projeto ganha uma estrutura que um colega novo pode reconhecer em minutos, porque é a mesma estrutura de todos os outros projetos nesse framework. E você herda um ecossistema: plugins, tutoriais, perguntas respondidas, e um pool de contratação de pessoas que já conhecem o caminho.

Os custos são igualmente concretos, e merecem o mesmo olhar direto. Um framework é uma grande dependência que você não controla, com seus próprios bugs, seu próprio ritmo, e suas próprias opiniões. Há uma curva de aprendizado antes de sua primeira página renderizar, e parte do que você aprende é conhecimento sobre o framework em vez de sobre programação. Seu código se dobra às suas formas, o que torna deixar mais difícil quanto mais tempo você fica. E frameworks se movem: versões principais chegam, padrões são repensados, e se manter atualizado é trabalho contínuo que você não tinha como código simples.

Nenhuma lista vence por si própria. O equilíbrio depende inteiramente do projeto, então a pergunta a fazer de qualquer framework é "este torna este projeto mais simples". Um framework merece seu lugar tornando seu projeto mais simples. Quando o faz, use-o de bom grado. Quando não, os próximos dois capítulos são sobre reconhecer isso cedo.

O efeito do ecossistema é a entrada subestimada no lado positivo. Em um framework maduro, as chances de que seu problema seja novo são próximas de zero: autenticação, uploads de arquivos, envio de e-mail, deploy, alguém empacotou ou documentou cada um. Isso converte muitos dias de construção em horas de montagem. A entrada espelhada no lado negativo é que essa fluência é denominada no framework: parte do que você sabe é "como Django faz" em vez de "como servidores web funcionam". Mantenha um olho na ideia geral por baixo de cada conveniência, que é o que estes docs são para.

Dois custos só aparecem em produção. Primeiro, abstrações vazam: a superfície conveniente do framework esconde maquinaria real, e no dia em que a magia se comporta mal, você acaba depurando a maquinaria mesmo assim, agora através de uma camada extra que você não escreveu. Planeje para entender o que seu framework faz por baixo, porque eventualmente você precisará. Segundo, a esteira de upgrade é um item real: migrações de versão maior de uma base de código grande podem absorver semanas, e pular silenciosamente se torna problemas de segurança não corrigidos em vez disso. Pese ambos contra a alternativa de código simples, que tem menos partes móveis e nada para migrar, mas reabre cada problema resolvido para você resolver novamente, por sua conta e risco. Esse trade é o assunto de Escolhendo e aprendendo um framework.

JunoO que frameworks trazem e custam Um framework te entrega problemas resolvidos, uma estrutura reconhecível, e um ecossistema inteiro de ajuda. Em troca você assume uma grande dependência, uma curva de aprendizado, e seu jeito de fazer as coisas. Ambos os lados são reais, então a pergunta a carregar é se torna seu projeto particular mais simples. Às vezes a resposta é um sim feliz, e às vezes código simples é o caminho mais calmo!

JunoO que frameworks trazem e custam O ecossistema é a metade subestimada do trade: em um framework maduro quase nenhum problema que você enfrenta é novo. Continue notando a ideia geral por baixo de cada conveniência embora, ou seu conhecimento fica "como este framework faz" em vez de como a coisa funciona. O framework deve tornar o projeto mais simples; esse é o teste inteiro.

JunoO que frameworks trazem e custam Dois custos cobram você depois: abstrações vazam, então um dia você depura a maquinaria do framework através de uma camada que você não escreveu, e migrações de versão maior são trabalho real que não pode ser pulado para sempre. Coloque preço neles adiantado, ao lado do preço próprio do código simples de re-resolver problemas que o framework havia terminado. Paguei ambas as faturas; nenhuma é diversão, e nenhuma é razão para dogma.

Para onde isso vai em seguida

Com a ideia em vigor, a próxima pergunta natural é o que está realmente aí: Os tipos de frameworks faz um tour pelas principais famílias, da web para jogos para testes, com as opções mais populares em cada. Depois disso, Escolhendo e aprendendo um framework fica prático sobre escolher um, aprender um, e saber quando você não precisa de nenhum. E se os exemplos JavaScript acima sentiram desconhecidos, o track de JavaScript cobre a própria linguagem, que é o primeiro passo certo antes de qualquer framework construído nela.