Escolhendo e aprendendo um framework

docs.scrimba.com

Os dois últimos capítulos cobriram o que são frameworks e o que existe. Este é o lado prático: se usar um, qual usar, e como aprendê-lo. A ordem importa, porque a primeira pergunta é a que mais frequentemente é pulada.

Você deveria usar um framework?

Imagine dois projetos. O primeiro é um app com contas, formulários e telas que reagem a dados compartilhados. Construir isso manualmente significa reconstruir exatamente o trabalho que um framework já aperfeiçoou, e a versão vanilla acaba sendo um framework espalhado e meio testado de sua própria invenção que ninguém quer herdar. Recorrer a Django ou React ali é escolher menos partes móveis que a alternativa.

O segundo é uma página de apresentação, um site de conteúdo, um script pequeno, um formulário que envia para algum lugar. HTML, CSS e um pouco de JavaScript cobrem esses casos sem passo de build, sem atualizações de dependências, e nada para migrar no próximo ano. Envolver uma página assim em um framework completo adiciona maquinário que só o tooling se beneficia. Muitos desenvolvedores experientes colocam vanilla em produção de propósito, e é uma resposta profissional, nunca um compromisso de iniciante.

Engenharia tem uma regra antiga e direta que cobre ambos os casos: KISS, "keep it simple, stupid". O insulto é dirigido ao design e não ao designer, e a ideia é que a melhor solução é aquela com a menor maquinaria que ainda faz o trabalho. Ambos os projetos acima obedecem isso, e chegam em respostas opostas.

Isso torna o teste uma pergunta, feita fresca para cada projeto: escolha qualquer opção que deixe você com menos maquinaria para manter. Quando o trabalho técnico enorme o produto, esse é o framework. Quando o produto é quase tudo o que existe, esse é vanilla.

Alguns sinais tornam a decisão concreta. Inclinando para framework: muitas telas compartilhando dados em tempo real, contas e permissões de usuários, formulários que validam e salvam, várias pessoas trabalhando no mesmo codebase por anos. Inclinando para vanilla: principalmente conteúdo, pouca interatividade, um tempo de vida medido em meses, um ou dois mantenedores, ou uma página onde a velocidade de carregamento é a única funcionalidade. E o tamanho do projeto pode mudar a resposta ao longo do tempo em ambas as 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 ambas vêm de pular a pergunta. A primeira falha é a página de apresentação em forma de framework: um pipeline de build, uma árvore de dependências, e eventuais migrações anexadas a quatro telas de conteúdo, onde cada hora gasta em tooling é uma hora que o produto não precisava. A segunda é o framework acidental: um codebase vanilla que cresce seu próprio router, seu próprio state store, e seu próprio sistema de componentes, cada um escrito uma vez, testado nunca, e entendido por uma pessoa. Esse segundo projeto paga custos de framework sem benefícios de framework. Ambas as falhas parecem convicção de dentro; o conserto em ambos os casos é o mesmo movimento prosaico de redecisão baseado no que o projeto se tornou.

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

JunoVocê precisa de um framework? Estado compartilhado em tempo real, contas, formulários, e uma longa vida multi-pessoa apontam para um framework; páginas pesadas em conteúdo, de curta duração, ou críticas em velocidade apontam para vanilla. Refaça a pergunta quando o projeto muda de forma em vez de defender a decisão original, e faça por projeto todas as vezes.

JunoVocê precisa de um framework? Observe as duas falhas clássicas: a página de apresentação em forma de framework pagando custos de tooling para nada, e o app vanilla que silenciosamente cresceu um framework não mantido de seu próprio. Ambos vêm de tratar a escolha como liquidada. Eu redecido em cada inflexão do projeto, e isso me salvou de ambas as armadilhas mais de uma vez.

Como escolher um

Quando a resposta é sim, escolha com critérios prosaicos. Benchmarks e comparações de funcionalidades são as entradas menos úteis, porque dentro de uma família as opções populares são todas rápidas o suficiente e capazes o suficiente. O que realmente molda sua vida diária:

O ecossistema e comunidade: documentação madura, perguntas respondidas, e pacotes para os problemas que você vai enfrentar. O time e codebase que você está entrando: o melhor framework geralmente é aquele que seu projeto já usa, e consistência bate novidade dentro de um time. O mercado de trabalho, se aprender para trabalhar: números de uso puro importam, o que é em grande parte por que React é a primeira escolha racional de muita gente. E a linguagem que você conhece: um desenvolvedor Python alcança Django mais rápido que Rails por razões que nada têm a ver com qualidade.

Mantenha a opção vanilla na lista até o final. Se a tabela de comparação se enche e nenhum dos candidatos bate "nenhuma das anteriores" no teste de simplicidade, essa é a resposta te dizendo algo.

Para um olhar mais próximo de um candidato, uma hora de avaliação de primeira mão bate uma semana de leitura de opiniões: percorra o tutorial oficial e julgue se a documentação explica ou apenas aponta; verifique o histórico de releases para um ritmo constante e tranquilo; procure por "migrating from version X to Y" e veja se esses guias parecem uma tarde ou uma temporada; e veja se as perguntas que você teria já têm boas respostas. Um framework é um relacionamento longo, e esses são os testes de compatibilidade.

Dois hábitos sênior completam isso. Primeiro, aposte no bem-estabelecido: uma tecnologia que tem sido amplamente usada por anos tem modos de falha conhecidos, pools de contratação, e respostas, e "provado e ligeiramente desfashionable" sobrevive "novo e excitante" muito mais frequentemente que o contrário. Churn é um custo em compounding, e os frameworks que sobreviveram uma década já o pagaram. Segundo, mantenha build-versus-adopt como uma opção real no nível de componente: às vezes a quantidade certa de framework é uma biblioteca de roteamento e nada mais, adotada para o um problema difícil enquanto o resto fica simples. Adotar um framework não é tudo ou nada, e a menor dependência que resolve o problema real atual é uma arquitetura respeitável.

JunoEscolhendo um Escolha com critérios práticos: o que seu time já usa, como é a qualidade da documentação e comunidade, o que o mercado de trabalho quer, e qual linguagem você já conhece. Dentro de uma família, cada opção popular é boa, então as apostas são menores do que parecem. Suas habilidades vão transferir para qualquer que seja o caminho.

JunoEscolhendo um Dê a um candidato uma hora focada: leia seu tutorial, verifique seu ritmo de release, e leia um guia de migração de versão, já que esse é o futuro que você está assinando. Comunidade, ajuste de time, e hiring batem benchmarks sempre. E mantenha "nenhum framework" na shortlist até o final de propósito.

JunoEscolhendo um Aposte no bem-estabelecido: sobreviver uma década é o benchmark mais informativo que um framework pode apresentar. E lembre-se adoção não é binária; às vezes uma pequena biblioteca para um problema difícil é a quantidade certa de framework. O objetivo é um produto que funciona e continua funcionando.

Como aprender qualquer framework

Aprenda a linguagem primeiro. Um framework assume sua linguagem em todo lugar: código React é JavaScript da cabeça aos pés, e cada linha confusa de um app Django é Python por baixo. Aprendizes que pulam para o framework acabam debugando dois mistérios ao mesmo tempo, o comportamento do framework e a sintaxe da linguagem, sem forma de saber qual é qual. Se React é seu objetivo, o JavaScript track é o passo primeiro real; para Django ou pytest, o Python track desempenha o mesmo papel. Linguagem primeiro é o atalho único maior que existe, porque é a parte que transfere para todo lugar.

Depois construa algo pequeno e real. Um pequeno projeto que você realmente quer, construído enquanto se apoia no tutorial oficial, ensina mais que qualquer quantidade de assistir e ler, porque a forma do framework só faz sentido sob suas próprias mãos. Mantenha o primeiro projeto modesto de propósito: seu único trabalho é apresentá-lo às ideias do framework, e a obra-prima pode vir depois.

E conforme você prossegue, continue perguntando o que o framework está fazendo por você. Cada funcionalidade conveniente está no lugar de algo real: uma rota no lugar de parsing de URL, um componente no lugar de atualizações de DOM, um model no lugar de SQL. Você não precisa dominar essas camadas de antemão, mas saber que existem, e aproximadamente o que o framework faz com elas, é o que separa usar um framework de depender cegamente dele.

A armadilha comum neste estágio é o loop de tutorial: terminar curso após curso enquanto nunca inicia um projeto não guiado, porque tutoriais parecem produtivos e arquivos em branco parecem arriscados. Quebre deliberadamente. Após um tutorial oficial, inicie o pequeno projeto real e deixe seus problemas dirigir o que você procura; documentação lida com um problema ao vivo em mão gruda de uma forma que documentação lida como lição de casa nunca faz. Ficar preso e se desembaraçar em seu próprio projeto é a habilidade real sendo treinada.

Dois hábitos tornam o conhecimento de framework durável. Aprenda as saídas de emergência cedo: todo framework tem formas sancionadas de cair abaixo de suas abstrações (SQL cru além do ORM, acesso direto ao DOM além do renderizador), e saber onde elas estão diz os limites da máquina mesmo se raramente as usar. E invista na plataforma sob o framework, HTTP, o DOM, SQL, o runtime da linguagem, em um fluxo constante. Frameworks são como a plataforma está sendo mantida atualmente; a plataforma é o que endura. Desenvolvedores que conheciam a plataforma cruzaram cada transição de framework dos últimos vinte anos intactos, o que é um histórico que vale a pena copiar.

JunoAprendendo um 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 terminado bate grande e abandonado, e tudo que você aprender sobre a linguagem mantém seu valor para sempre!

JunoAprendendo um Escape do loop de tutorial de propósito: um tutorial oficial, depois um pequeno projeto não guiado cujos problemas decidem o que você lê depois. Docs estudados com um problema ao vivo em mão realmente grudam. Ficar preso e se desembaraçar em seu próprio trabalho é a habilidade que você está realmente treinando.

JunoAprendendo um Encontre as saídas de emergência cedo; elas marcam as verdadeiras arestas da máquina. E continue alimentando seu conhecimento da plataforma por baixo, HTTP, o DOM, SQL, porque frameworks giram e a plataforma fica. Pessoas de plataforma sobrevivem cada transição de framework; observei várias e o padrão não faltou ainda.

Onde isso te deixa

Esse é o primer completo: simplicidade como o teste, critérios prosaicos para a escolha, linguagem antes de framework para o aprendizado. Quando um framework específico aparece depois, nestes docs ou por aí, The kinds of frameworks é o mapa para colocá-lo, e What is a framework é a definição por baixo.