Os tipos de frameworks

docs.scrimba.com

O que é um framework cobriu a ideia: estrutura mais plumbing resolvido, com o framework chamando seu código. Este capítulo é o mapa do que realmente existe: um tour com uma garantia embutida, porque ninguém conhece todos esses. Desenvolvedores que trabalham sabem uma ou duas famílias bem e reconhecem o resto, e esse é o objetivo aqui também. Famílias importam mais que nomes: aprenda bem um membro e seus irmãos vêm rapidamente.

A web: front-end e back-end

Frameworks web se dividem na linha em que a própria web se divide. Frameworks de front-end rodam no navegador e gerenciam o que o usuário vê; frameworks de back-end rodam em um servidor e gerenciam dados, contas e tudo nos bastidores. Se você está entrando em desenvolvimento web, um de cada lado provavelmente se tornará uma ferramenta diária, e qual é geralmente decidido pelo time ou projeto que você entra em vez de por você.

Os nomes de front-end que você encontrará:

• React: o mais usado por uma grande margem, com o maior ecossistema e mercado de trabalho. Tecnicamente uma biblioteca UI em vez de um framework completo, uma distinção com um núcleo útil coberto abaixo.
• Vue: conhecido por uma curva de aprendizado suave e documentação que as pessoas realmente gostam; um caminho do meio completo e bem organizado.
• Angular: o framework com todas as baterias incluídas do Google, opinativo sobre tudo; mais em casa em grandes organizações que querem uma forma sancionada para fazer cada coisa.
• Svelte: faz seu trabalho no tempo de build e envia menos código para o navegador; comunidade menor, frequentemente admirada pelas pessoas nela.

E os nomes de back-end, onde o framework é geralmente vinculado a uma linguagem:

• Django (Python): com todas as baterias incluídas, de banco de dados a interface de admin; um parceiro frequente do Python que você já pode conhecer.
• Rails (Ruby): o framework que popularizou convenção sobre configuração; suas ideias ecoam através da maioria dos frameworks web modernos, Laravel incluído.
• Laravel (PHP): o padrão moderno do mundo PHP, que ainda executa uma parcela muito grande da web.
• Express (JavaScript): deliberadamente minimalista, mais próximo de um toolkit do que um framework completo; você monta o resto você mesmo.
• Spring (Java): o cavalo de trabalho corporativo; sprawling, profundamente estabelecido, e em todo lugar em grandes empresas.

Uma vez que você consegue ver além dos logos, as mesmas ideias se repetem em todos esses. Frameworks front-end todos convergiram para componentes: pequenas, reutilizáveis peças de interface que possuem seu próprio look e comportamento. Frameworks back-end todos oferecem roteamento (qual URL executa qual código), alguma forma de falar com um banco de dados (frequentemente um ORM, que permite trabalhar com linhas de banco de dados como objetos ordinários), e um espaço para sua lógica de negócios. Aprenda para que essas ideias servem em um framework e você já aprendeu a maioria do próximo framework; mover entre eles principalmente significa nova sintaxe e novos nomes de pastas sobre os mesmos conceitos.

O front-end atual tem uma camada a mais. React, Vue e Svelte cuidam da interface mas deixam roteamento, carregamento de dados e renderização de servidor para você, então cada um cresceu um meta-framework: um framework construído em cima da biblioteca que fornece essas peças que faltam. Next.js desempenha esse papel para React, Nuxt para Vue, e SvelteKit para Svelte, e na prática a maioria dos novos apps de produção alcançam o meta-framework em vez da biblioteca nua. Isso também resolve o velho argumento "React é um framework ou uma biblioteca" de forma útil: React em si apenas renderiza UI e inverte controle sobre nada além de seus componentes, o que o torna uma biblioteca pela definição do último capítulo; envolva-o em Next.js e o par se comporta exatamente como um framework. O rótulo importa menos que saber qual camada é responsável por qual decisão, porque é onde você procura quando algo não funciona bem.

JunoFrameworks web Frameworks front-end como React e Vue rodam no navegador e cuidam do que as pessoas veem; frameworks back-end como Django e Rails rodam em servidores e cuidam de dados e contas. Você não precisa escolher o perfeito hoje, e definitivamente não precisa de todos eles. A maioria das pessoas aprende aquele que seu primeiro time usa, e isso funciona bem!

JunoFrameworks web Os nomes web diferem, as ideias se repetem: componentes no front-end; roteamento, um ORM, e slots de lógica de negócios no back-end. Aprenda as ideias através de um framework e o próximo é principalmente nova sintaxe sobre formas familiares. Essa transferência é por que escolher "o errado" primeiro custa menos do que as pessoas temem.

JunoFrameworks web O trabalho de front-end moderno geralmente significa um meta-framework: Next.js sobre React, Nuxt sobre Vue, SvelteKit sobre Svelte, fornecendo o roteamento e renderização de servidor que a biblioteca base deixa de fora. Mantenha claro qual camada é responsável por qual decisão, já que é onde o debug começa. E React realmente é uma biblioteca pela nossa definição; Next.js é o que torna o par um framework.

Apps e games

Desenvolvimento mobile tem sua própria história de framework, e se centra em uma pergunta: construir separadamente para iPhone e Android, ou uma vez para ambos? Dois frameworks dominam a resposta de construir-uma-vez. Flutter (do Google, usando a linguagem Dart) desenha sua própria interface pixel por pixel, então apps parecem idênticos em todo lugar. React Native traz o modelo de componentes do React para mobile e dirige as peças de interface nativa de cada plataforma, que é uma continuação natural se você já conhece React.

Game engines são frameworks em seu mais total: eles possuem o loop que roda sessenta vezes por segundo, e seu código preenche o que cada objeto faz dentro disso. Unity (C#) é o padrão para games indie e de médio porte e muito do gaming mobile. Unreal (C++) lidera onde a fidelidade visual é o ponto, de games de grande orçamento a produção de filmes. Godot é o engine livre e open-source cuja comunidade cresceu rapidamente, e um lugar amigável para começar.

O comércio multiplataforma merece sua etiqueta de preço lida em voz alta. Um codebase significa metade do trabalho e um time, que é por que empresas amam isso. O custo é uma camada entre você e a plataforma: quando um recurso novo do iPhone se torna disponível, o framework precisa suportá-lo antes que você possa usá-lo confortavelmente, e extrair completamente a sensação nativa leva cuidado extra. Times que precisam de cada detalhe nativo ainda constroem separadamente com o kit próprio de cada plataforma; times que precisam enviar em ambos com um time pequeno pegam Flutter ou React Native e raramente se arrependem.

Game engines levam a inversão de controle tão longe quanto vai, o que os torna um caso extremo esclarecedor. O engine possui o tempo em si: ele chama seus scripts a cada frame, executa física entre seus callbacks, e decide quando seu objeto até existe. Você também não escreve código principalmente "em" um engine; você trabalha dentro de seu editor, e scripts são um asset entre cenas, materiais e prefabs. Essa propriedade total é exatamente por que engines existem: renderização, física e pipelines de assets são anos de trabalho especializado que nenhum time de game quer reconstruir. A mesma lógica se escala para baixo: sempre que o plumbing ofusca o produto, um framework para de ser uma conveniência e se torna o único caminho sensato.

JunoApps e games Flutter e React Native permitem que um codebase se torne tanto um app iPhone quanto Android, que é por que tantos times as usam. Games têm engines como Unity, Unreal e Godot, que cuidam de gráficos e física enquanto seu código diz o que cada objeto faz. A mesma ideia de framework que a web, usando roupas diferentes.

JunoApps e games Mobile multiplataforma troca um pouco de polonês nativo por metade do trabalho, um negócio que a maioria dos times aceita felizmente, enquanto kits totalmente nativos permanecem a resposta quando a sensação de plataforma é tudo. Game engines são a ideia de framework em força total: eles rodam o show sessenta vezes por segundo e seus scripts preenchem o comportamento.

JunoApps e games Engines são o extremo que explica a regra: quando o plumbing (renderização, física, pipelines de assets) é anos de trabalho e ofusca seu game real, entregar o controle é o único comércio sensato. Mantenha essa razão em sua mente, plumbing versus produto, e a maioria das decisões de framework em qualquer campo fica mais fácil.

Os quietos: testes e dados

Nem todo framework é sobre construir um produto; alguns organizam o trabalho ao redor disso. Frameworks de testes são o caso mais claro, e o exemplo mais puro da definição do último capítulo: pytest (Python), Jest (JavaScript), e JUnit (Java) cada um encontra suas funções de teste, as executa, e relata, com você nunca escrevendo um programa que chama seus próprios testes. Você encontrará um desses em quase toda base de código profissional, geralmente aquele correspondendo à linguagem do projeto.

Dados e machine learning têm frameworks também. PyTorch domina pesquisa e cada vez mais produção; TensorFlow é o ecossistema do Google com ferramental de produção profundo. Ambos cuidam da maquinaria matemática do treinamento de modelos para que seu código descreva o modelo em vez do cálculo. Se a trilha How AI Works o interessou, essas são as ferramentas que esse mundo constrói.

Test runners são inversão de controle em miniatura, e merecem um minuto de apreciação por essa razão. Você escreve funções nomeadas test_something, e o framework as descobre por nome, executa cada uma em uma configuração fresca, captura falhas sem parar o resto, e imprime o resumo. Ninguém escreve essa orquestração por projeto, que é a proposição de valor do framework em seu menor e menos controverso: até desenvolvedores que evitam frameworks de produto em princípio felizmente usam um framework de teste.

O par de ML é onde a linha biblioteca-versus-framework fica útil e borrada. Escrever um loop de treinamento customizado em PyTorch parece usar uma biblioteca: seu código dirige, e fornece math rápido. Usar camadas de nível mais alto, trainers e callbacks o inverte de volta para forma de framework, com seu código entrando em um loop que a ferramenta possui. O limite depende de qual camada da ferramenta você dirige. Esse framing viaja bem além de ML: muitas ferramentas grandes são bibliotecas em uma altitude e frameworks em outra, e saber em qual altitude você está voando diz quem possui o fluxo de controle hoje.

JunoFrameworks de testes e dados Frameworks de testes como pytest e Jest encontram suas funções de teste e as executam para você, um pequeno exemplo cotidiano de um framework chamando seu código. Em machine learning, PyTorch e TensorFlow cuidam da matemática pesada do treinamento de modelos. Frameworks organizam todos os tipos de trabalho de programação, bem além de construir apps.

JunoFrameworks de testes e dados Um test runner é a ideia de framework em seu menos controverso: descoberta, isolamento e relatório que ninguém deveria reconstruir por projeto. Note que até desenvolvedores céticos de framework usam um sem reclamação; o comércio é diminuto e o payoff é constante. Essa assimetria é uma boa lente para julgar qualquer framework.

JunoFrameworks de testes e dados PyTorch é uma biblioteca quando você escreve o loop de treinamento e um framework quando seu trainer o executa, e essa é a lição geral: ferramentas grandes mudam de categoria dependendo de qual camada você dirige. Pergunte quem possui o fluxo de controle na altitude em que você está trabalhando, e a pergunta biblioteca-ou-framework responde a si mesma.

Aonde isso vai depois

Esse é o mapa: web em ambos os lados do fio, mobile, games, testes e dados, a mesma ideia usando uniformes diferentes. A pergunta restante é a prática, e tem duas metades: qual, e se um em tudo. Choosing and learning a framework enfrenta ambas, e se as definições aqui pareciam instáveis, What is a framework é uma leitura curta de volta.