Escolhendo e aprendendo um framework

docs.scrimba.com

Os dois últimos capítulos cobriram o que são frameworks e quais existem. Este é a parte prática: se você deve usar um, qual usar e como aprendê-lo. A ordem importa, porque a primeira pergunta é justamente a que costuma ser pulada.

Você precisa de um framework?

Imagine dois projetos. O primeiro é um app com contas, formulários e telas que reagem todas a dados compartilhados. Construir isso na mão significa recriar exatamente a estrutura que um framework já aperfeiçoou, e a versão sem framework acaba se tornando um framework improvisado seu, espalhado e mal testado, que ninguém vai querer herdar. Recorrer a Django ou React nesse caso é optar por menos peças móveis do que a alternativa.

O segundo é uma landing page, um site de conteúdo, um script pequeno, um formulário que envia dados para algum lugar. HTML puro, CSS e um pouco de JavaScript resolvem isso sem build, sem atualizações de dependências e sem nada para migrar no ano seguinte. Envolver uma página assim em um framework completo adiciona uma estrutura da qual só as ferramentas se beneficiam. Muitos desenvolvedores experientes optam por código puro de propósito, e essa é uma decisão profissional, nunca uma concessão de principiante.

A engenharia tem uma regra antiga e direta que cobre os dois casos: KISS, "keep it simple, stupid" (mantenha simples, estúpido). A crítica é dirigida ao design, não a quem projeta, e a ideia é que a melhor solução é a que tem menos engrenagens e ainda assim faz o trabalho. Os dois projetos acima seguem essa regra, e chegam a respostas opostas.

Isso transforma a decisão em uma única pergunta, feita de novo para cada projeto: escolha a opção que deixa menos estrutura para você manter. Quando a estrutura de suporte supera em muito o produto, a resposta é o framework. Quando o produto é praticamente tudo o que existe, a resposta é o código puro.

Alguns sinais tornam a decisão mais concreta. Pesa a favor do framework: muitas telas compartilhando dados em tempo real, contas e permissões de usuário, formulários que validam e salvam, várias pessoas trabalhando na mesma base de código por anos. Pesa a favor do código puro: principalmente conteúdo, pouca interatividade, vida útil medida em meses, um ou dois mantenedores, ou uma página em que a velocidade de carregamento é praticamente toda a funcionalidade. E o tamanho do projeto pode mudar a resposta ao longo do tempo, nas duas direções, então o hábito útil é refazer a pergunta sempre que o projeto muda de forma.

Essa decisão falha de duas maneiras reconhecíveis, e as duas vêm de pular a pergunta. O primeiro erro é a landing page com estrutura de framework: um pipeline de build, uma árvore de dependências e migrações futuras acopladas a quatro telas de conteúdo, em que cada hora gasta com ferramentas é uma hora que o produto não precisava. O segundo é o framework acidental: uma base de código em JavaScript puro que desenvolve seu próprio roteador, seu próprio gerenciador de estado e seu próprio sistema de componentes, cada um escrito uma única vez, nunca testado, e compreendido por uma só pessoa. Esse segundo projeto paga os custos de um framework sem receber os benefícios de um. As duas falhas parecem convicção por dentro; a correção, nos dois casos, é o mesmo movimento nada glamouroso de decidir de novo com base no que o projeto se tornou.

JunoVocê precisa de um framework? Faça uma pergunta por projeto: qual opção deixa menos coisa para construir e manter? Para um app interativo com contas e dados compartilhados, um framework geralmente ganha. Para uma página de conteúdo ou um script pequeno, código puro geralmente ganha. As duas respostas são respeitáveis, e escolher código puro nunca é um retrocesso!

JunoVocê precisa de um framework? Estado compartilhado em tempo real, contas, formulários e uma vida longa com várias pessoas envolvidas apontam para um framework; páginas cheias de conteúdo, de vida curta ou em que a velocidade é crítica apontam para código puro. Refaça a pergunta quando o projeto mudar de forma, em vez de defender a decisão original, e trate cada projeto de forma independente.

JunoVocê precisa de um framework? Fique atento às duas falhas clássicas: a landing page com estrutura de framework pagando custos de ferramentas por nada, e o app em código puro que discretamente desenvolveu seu próprio framework não mantido. As duas vêm de tratar a escolha como definitiva. Eu redecido em cada ponto de inflexão do projeto, e isso já me salvou dos dois problemas mais de uma vez.

Como escolher um

Quando a resposta é sim, escolha com critérios nada glamourosos. Benchmarks e comparações de recursos são as informações menos úteis, porque dentro de uma mesma família as opções populares já são todas rápidas o suficiente e capazes o suficiente. O que realmente molda o seu dia a dia:

O ecossistema e a comunidade: documentação madura, perguntas já respondidas e pacotes para os problemas que você vai encontrar. A equipe e a base de código que você está entrando: o melhor framework geralmente é o que o seu projeto já usa, e consistência vence novidade dentro de uma equipe. O mercado de trabalho, se você está aprendendo para conseguir emprego: os números de uso puro e simples importam, o que explica boa parte de por que React é a escolha racional inicial de muita gente. E a linguagem que você já conhece: um desenvolvedor Python chega ao Django mais rápido do que ao Rails, por razões que não têm nada a ver com qualidade.

Mantenha a opção de código puro na lista até o fim. Se a tabela de comparação se encher e nenhum dos candidatos superar a opção "nenhum dos anteriores" no teste de simplicidade, isso já é uma resposta dizendo algo.

Para avaliar mais de perto um candidato, uma hora de avaliação em primeira mão vale mais que uma semana lendo opiniões: passe os olhos pelo tutorial oficial e julgue se a documentação explica ou só aponta vagamente; verifique o histórico de versões buscando um ritmo estável e sem pressa; procure por "migrando da versão X para Y" e veja se esses guias parecem coisa de uma tarde ou de uma temporada inteira; e observe se as perguntas que você faria já têm boas respostas. Um framework é um relacionamento longo, e essas são as checagens de compatibilidade.

Dois hábitos de quem já tem experiência completam esse quadro. Primeiro, aposte no que já é bem estabelecido: uma tecnologia usada amplamente por anos tem modos de falha conhecidos, mão de obra disponível e respostas prontas, e "comprovado e um pouco fora de moda" sobrevive mais que "novo e empolgante" muito mais vezes do que o contrário. Trocar de tecnologia é um custo que se acumula, e os frameworks que sobreviveram uma década já pagaram esse preço. Segundo, mantenha construir-versus-adotar como uma opção real no nível de componente: às vezes a quantidade certa de framework é uma biblioteca de rotas e nada mais, adotada só para resolver o problema difícil, enquanto o resto continua em código puro. Adotar um framework não é tudo ou nada, e a menor dependência que resolve a parte realmente difícil já é uma arquitetura respeitável.

JunoEscolhendo um Escolha com critérios práticos: o que a sua equipe já usa, quão boas são a documentação e a comunidade, o que o mercado de trabalho pede, e qual linguagem você já conhece. Dentro de uma mesma família, toda opção popular é boa, então a aposta é menor do que parece. As suas habilidades vão se transferir independentemente do caminho escolhido.

JunoEscolhendo um Dê a um candidato uma hora bem focada: leia o tutorial dele, verifique o ritmo de lançamentos e leia um guia de migração de versão, porque esse é o futuro que você está assinando. Comunidade, encaixe com a equipe e demanda no mercado ganham de benchmarks sempre. E mantenha "sem framework" na lista de candidatos até o fim, de propósito.

JunoEscolhendo um Aposte no que já é bem estabelecido: sobreviver a uma década é o indicador mais informativo que um framework pode apresentar. E lembre-se de que adotar não é binário; às vezes uma biblioteca pequena para o problema difícil é a quantidade certa de framework. O objetivo é um produto que sai do papel e continua saindo.

Como aprender qualquer framework

Aprenda a linguagem primeiro. Um framework pressupõe sua linguagem em todo lugar: código React é JavaScript do começo ao fim, e cada linha confusa de um app Django é Python por baixo. Quem pula direto para o framework acaba depurando dois mistérios ao mesmo tempo, o comportamento do framework e a sintaxe da linguagem, sem conseguir distinguir um do outro. Se React é seu objetivo, a trilha de JavaScript é o verdadeiro primeiro passo; para Django ou pytest, a trilha de Python cumpre o mesmo papel. Linguagem primeiro é o maior atalho que existe, porque é a parte que se aplica em qualquer lugar.

Depois, construa algo pequeno e real. Um projetinho que você realmente queira fazer, construído com o tutorial oficial ao lado, ensina mais do que qualquer quantidade de vídeos e leitura, porque a forma do framework só faz sentido quando você mesmo põe a mão na massa. Mantenha o primeiro projeto modesto de propósito: o único trabalho dele é te apresentar às ideias do framework, e a obra-prima pode vir depois.

E, ao longo do caminho, continue perguntando o que o framework está fazendo por você. Todo recurso conveniente está substituindo algo real: uma rota substitui a análise de URL, um componente substitui atualizações do DOM, um model substitui SQL. Você não precisa dominar essas camadas desde já, mas saber que elas existem, e ter uma ideia aproximada do que o framework faz com elas, é o que separa usar um framework de depender dele às cegas.

A armadilha comum nessa fase é o ciclo de tutoriais: terminar curso após curso sem nunca começar um projeto sem orientação, porque tutoriais parecem produtivos e arquivos em branco parecem arriscados. Rompa esse ciclo de propósito. Depois de um tutorial oficial, comece o pequeno projeto real e deixe que os problemas dele guiem o que você vai pesquisar; documentação lida com um problema real em mãos fica na memória de um jeito que documentação lida como dever de casa nunca fica. Ficar travado e se destravar por conta própria no seu projeto é a habilidade que realmente está sendo treinada.

Dois hábitos tornam o conhecimento de um framework duradouro. Aprenda cedo as saídas de emergência: todo framework tem formas oficialmente aceitas de descer abaixo das suas abstrações (SQL puro em vez do ORM, acesso direto ao DOM em vez do renderizador), e saber onde elas estão te mostra os limites da máquina, mesmo que você raramente as use. E invista, em pequenas doses constantes, na plataforma que sustenta o framework: HTTP, o DOM, SQL, o runtime da linguagem. Frameworks são a forma como a plataforma está sendo manuseada no momento; a plataforma é o que permanece. Desenvolvedores que conheciam a plataforma atravessaram intactos todas as transições de framework dos últimos vinte anos, e esse é um histórico que vale a pena reproduzir.

JunoAprendendo um framework Aprenda a linguagem antes do framework, sempre: JavaScript antes de React, Python antes de Django. Depois, construa um pequeno projeto real com o tutorial oficial aberto ao lado. Pequeno e concluído vale mais que grande e abandonado, e tudo o que você aprender sobre a linguagem mantém seu valor para sempre!

JunoAprendendo um framework Escape do ciclo de tutoriais de propósito: um tutorial oficial, depois um pequeno projeto sem orientação, cujos problemas decidem o que você lê a seguir. Documentação estudada com um problema real em mãos realmente fica na memória. Ficar travado e se destravar no seu próprio trabalho é a habilidade que você está de fato treinando.

JunoAprendendo um framework Encontre as saídas de emergência desde cedo; elas marcam os limites reais da máquina. E continue alimentando o seu conhecimento da plataforma que sustenta tudo, HTTP, o DOM, SQL, porque frameworks se sucedem e a plataforma permanece. Quem conhece a plataforma sobrevive a toda transição de framework; já vi várias, e o padrão nunca falhou.

Onde isso te deixa

Esse é o resumo completo: simplicidade como critério de decisão, critérios nada glamourosos para a escolha, linguagem antes do framework para o aprendizado. Quando um framework específico aparecer pela frente, nesta documentação ou no mundo real, Os tipos de frameworks é o mapa para posicioná-lo, e O que é um framework é a definição que sustenta tudo isso.