Este artigo ensina sobre as diferenças entre frameworks e bibliotecas no contexto de um ambiente JavaScript do lado do cliente, que é o código executado no navegador da Web. No entanto, alguns dos pontos abordados neste artigo também se aplicam a outros ambientes, porque as bibliotecas e frameworks fazem parte de muitos campos de engenharia de software, como o desenvolvimento de apps para dispositivos móveis nativos.
As discussões nesta postagem se concentram nas diferenças qualitativas, e não nas quantitativas, entre bibliotecas e frameworks. Exemplo:
- Quantitativo:os frameworks geralmente aderem ao princípio da inversão de controle.
- Qualitativa:a experiência com o framework pode atrair mais futuros empregadores quando você estiver procurando emprego.
Por que aprender sobre bibliotecas e frameworks?
O uso de bibliotecas e frameworks JavaScript é comum na Web. Todos os outros sites parecem usar algum código de terceiros como parte dos recursos JavaScript. O peso da página da Web está piorando com o tempo, o que afeta os usuários. O JavaScript é um fator que contribui muito para o peso geral da página, e é esse mesmo JavaScript que geralmente inclui bibliotecas e frameworks de terceiros.
Não é bom o suficiente dizer "Pare de usar frameworks JavaScript", porque os frameworks oferecem um grande benefício para os desenvolvedores. Os frameworks podem ajudar você a programar de forma eficiente e entregar recursos rapidamente, entre outros benefícios. Em vez disso, você precisa se informar para tomar uma decisão consciente quando chegar a hora.
"Devo usar uma biblioteca ou framework hoje?" é uma pergunta incomum. Bibliotecas e frameworks são duas coisas muito diferentes. No entanto, bibliotecas e frameworks costumam ser confundidos, e quanto mais conhecimento você tiver sobre os dois, mais provável será que você tome decisões fundamentadas sobre o uso deles.
Exemplos de bibliotecas e frameworks
Você pode notar o código de terceiros por outros nomes, como widgets, plug-ins, polyfills ou pacotes. No entanto, geralmente, todos eles se enquadram na categoria de biblioteca ou framework. Basicamente, a diferença entre os dois pode ser resumida da seguinte maneira:
- Para uma biblioteca, o código do app chama o código da biblioteca.
- Em um framework, o código do app é chamado pelo framework.
Biblioteca
As bibliotecas tendem a ser mais simples que os frameworks e oferecem um escopo de funcionalidade mais estreito. Se você transmitir uma entrada para um método e receber uma saída, provavelmente usou uma biblioteca.
Confira este exemplo da biblioteca lodash
:
import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello
Como acontece com muitas bibliotecas, é prático ler esse código e entender o que ele faz. Não há nada de mágico:
- Uma instrução
import
importa a biblioteca lodash para o programa JavaScript. - O método
capitalize()
é invocado. - Um único argumento é transmitido para o método.
- O valor de retorno é capturado em uma variável.
Framework
Os frameworks tendem a ser maiores do que as bibliotecas e contribuem mais para o peso geral da página. Na verdade, um framework pode incluir uma biblioteca.
Este exemplo mostra um framework simples sem uma biblioteca e usa o Vue, que é um framework JavaScript conhecido:
<!-- index.html -->
<div id="main">
{{ message }}
</div>
<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';
new Vue({
el: '#main',
data: {
message: 'Hello, world'
}
});
</script>
Se você comparar este exemplo de framework com o exemplo de biblioteca anterior, poderá notar estas diferenças:
- O código do framework abrange várias técnicas e as abstrai na própria API opinativa.
- Os desenvolvedores não têm controle total sobre como e quando as operações ocorrem. Por exemplo, como e quando o Vue grava a string
'Hello, world'
na página é abstrato. - A instanciação da classe
Vue
tem alguns efeitos colaterais, que são comuns ao usar frameworks, enquanto uma biblioteca pode oferecer funções puras. - O framework prescreve um sistema de modelo HTML específico em vez de usar o seu.
- Se você ler mais sobre a documentação do framework Vue ou da maioria das outras documentações, vai notar como os frameworks prescrevem padrões de arquitetura que podem ser usados. Os frameworks JavaScript aliviam um pouco da carga cognitiva, porque você não precisa descobrir tudo por conta própria.
Quando usar uma biblioteca em vez de um framework
Depois de ler as comparações entre bibliotecas e frameworks, você pode começar a entender quando usar um ou outro:
- Um framework pode reduzir a complexidade para você, o desenvolvedor. Como discutido, um framework pode abstrair lógica, comportamento e até padrões de arquitetura. É especialmente útil quando você começa um novo projeto. Uma biblioteca pode ajudar com a complexidade, mas normalmente se concentra na reutilização de código.
- Os autores de frameworks querem que você seja produtivo e, com frequência, desenvolvem ferramentas extras, softwares de depuração e guias abrangentes, entre outros recursos, para ajudar você a usar um framework de maneira eficaz. Os autores de bibliotecas também querem que você seja produtivo, mas ferramentas especializadas são raras em bibliotecas.
- A maioria dos frameworks oferece um ponto de partida funcional, como um esqueleto ou modelo, para ajudar você a criar apps da Web rapidamente. Uma biblioteca se torna parte da sua base de código já estabelecida.
- Em geral, os frameworks aumentam um pouco a complexidade da base de código. A complexidade nem sempre é óbvia no início, mas pode se revelar com o tempo.
Não é comum comparar uma biblioteca com um framework, porque eles são coisas diferentes que realizam tarefas diferentes. No entanto, quanto mais conhecimento você tiver sobre os dois, mais capacitado estará para decidir qual é o melhor para você. A decisão de usar um framework ou biblioteca depende dos seus requisitos.
Troca
Você não vai mudar sua biblioteca ou framework toda semana. No entanto, é recomendável entender as desvantagens de um pacote que bloqueia você no ecossistema dele. Também é recomendável entender que o desenvolvedor que decide usar um pacote de terceiros é responsável pela criação de um acoplamento flexível entre o pacote e o código-fonte do app.
Um pacote vinculado ao código-fonte é mais difícil de remover e trocar por outro. Talvez seja necessário trocar um pacote quando:
- Você precisa fazer atualizações em um pacote que não é mais mantido.
- Você descobre que o pacote tem muitos bugs.
- Você descobre um novo pacote que atende melhor às suas necessidades.
- Os requisitos do produto mudam e o pacote não é mais necessário.
Por exemplo,
// header.js file
import color from '@package/set-color';
color('header', 'dark');
// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');
// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');
O exemplo anterior usa o pacote @package/set-color
de terceiros em três arquivos separados. Se você trabalhar nesse código e precisar substituir o pacote de terceiros, atualize o código em três lugares.
Como alternativa, você pode simplificar a manutenção e abstrair o uso da biblioteca para um único lugar, como neste exemplo:
// lib/set-color.js file
import color from '@package/set-color';
export default function color(element, theme = 'dark') {
color(element, theme);
}
// header.js file
import color from './lib/set-color.js';
color('header');
// article.js file
import color from './lib/set-color.js';
color('.article-post');
// footer.js file
import color from './lib/set-color.js';
color('.footer-container');
No exemplo anterior, o uso direto da biblioteca é abstrato. Assim, se você precisar trocar o pacote de terceiros, atualize apenas um arquivo. Além disso, o código agora é mais fácil de trabalhar porque o arquivo set-color.js
interno define um tema de cores padrão a ser usado.
Facilidade de uso
Um framework pode ter uma API complexa, mas pode oferecer ferramentas para desenvolvedores que facilitam o uso geral. A facilidade de uso é baseada em muitos fatores e pode ser altamente subjetiva. Um framework pode ser difícil de usar porque:
- O framework tem uma API inerentemente complexa.
- O framework está mal documentado e exige muitas tentativas e erros para resolver problemas.
- O framework usa técnicas que não são familiares para você e sua equipe.
Os frameworks podem atenuar esses desafios com práticas recomendadas comuns, como estas:
- O framework oferece ferramentas de desenvolvimento e diagnóstico para facilitar a depuração.
- O framework tem uma comunidade ativa de desenvolvedores que colaboram em documentação, guias, tutoriais e vídeos sem custo financeiro. Depois de consumir esse conteúdo, você vai ser produtivo com o framework.
- O framework oferece uma API que segue convenções de programação comuns. Você é produtivo com o framework porque aprendeu essas convenções anteriormente e tem mais familiaridade com os estilos de programação.
Embora esses pontos sejam comumente atribuídos a frameworks, eles também podem ser atribuídos a bibliotecas. Por exemplo, a biblioteca JavaScript D3.js é poderosa e tem um grande ecossistema que oferece oficinas, guias e documentação, entre outros recursos, que afetam a facilidade de uso.
Além disso, um framework geralmente prescreve uma arquitetura para seu app da Web, enquanto uma biblioteca é compatível com a arquitetura atual, seja ela qual for.
Desempenho
Em geral, os frameworks podem afetar a performance mais do que as bibliotecas, embora haja exceções. A performance da Web é uma área enorme com muitos tópicos. Por isso, estas seções abordam dois temas importantes: o tremor de árvore e as atualizações de software.
Tree shaking
O agrupamento é apenas uma faceta do desempenho da Web, mas tem um grande efeito no desempenho, especialmente com bibliotecas maiores. O uso do tree shaking durante a importação e exportação ajuda no desempenho porque encontra e remove o código desnecessário do app.
Ao agrupar o código JavaScript, há uma etapa útil conhecida como eliminação de árvores, que é uma otimização de desempenho valiosa que você pode fazer no código, embora seja mais fácil fazer isso com bibliotecas do que com frameworks.
Ao importar o código de terceiros para o código-fonte, você normalmente agrupa o código em um ou alguns arquivos de saída. Por exemplo, os arquivos header.js
, footer.js
e sidebar.js
são combinados no arquivo output.js
, que é o arquivo de saída carregado no seu app da Web.
Para entender melhor o shake de árvore, considere estes exemplos de código:
// library.js file
export function add(a, b) {
return a + b;
}
export function subtract(a, b) {
return a - b;
}
// main.js file
import {add} from './library.js';
console.log(add(7, 10));
Para fins de demonstração, o exemplo de código library.js
é intencionalmente pequeno em comparação com o que você pode encontrar no mundo real, em que a biblioteca pode ter milhares de linhas.
Um processo de pacote simples pode exportar o código com esta saída:
// output.js file
function add(a, b) {
return a + b;
}
function subtract(a, b) {
return a - b;
}
console.log(add(7, 10));
Embora a função subtract()
não seja necessária neste app, ela ainda é incluída no pacote final. Códigos desnecessários como esse aumentam o tamanho do download, o tempo de análise e compilação e os custos de execução que os usuários precisam pagar. Uma abordagem básica de tree shaking remove o código inoperante e produz esta saída:
// output.js file
function add(a, b) {
return a + b;
}
console.log(add(7, 10));
O código é mais curto e sucinto. Neste exemplo, a melhoria de desempenho é insignificante, mas em um app real em que a biblioteca tem milhares de linhas, o efeito de desempenho pode ser muito mais significativo. Curiosamente, as ferramentas de pacotes modernas, como Parcel, Webpack e Rollup, vão além porque combinam a minificação e o tree shaking para criar um pacote altamente otimizado. Para demonstrar a eficácia das ferramentas de pacote, usamos o Parcel para criar um arquivo de pacote com os exemplos de código anteriores. O Parcel removeu todo o código não utilizado e exportou este único módulo:
console.log(7+10);
O Parcel é inteligente o suficiente para remover declarações de importação, definições de função e comportamento entre outros itens para criar um código altamente otimizado.
O agrupamento é apenas uma faceta do desempenho da Web, mas tem um grande efeito no desempenho, especialmente com bibliotecas maiores. O tree shaking geralmente é mais simples de fazer com bibliotecas do que com frameworks.
Atualizações de software
Para muitas bibliotecas e frameworks, as atualizações de software adicionam funcionalidades, corrigem bugs e aumentam de tamanho ao longo do tempo. Não é sempre necessário fazer o download de atualizações, mas se elas incluem correções de bugs, melhorias de recursos ou correções de segurança, provavelmente você precisa atualizar. No entanto, quanto mais dados você enviar pela rede, menos desempenho seu app terá e maior será o efeito na experiência do usuário.
Se uma biblioteca aumentar de tamanho, use a agitação de árvore para reduzir o crescimento. Como alternativa, use uma alternativa menor à biblioteca JavaScript. Para mais informações, consulte Troca.
Se um framework crescer, não apenas o teste de estresse será mais desafiador, mas também será mais difícil trocar um framework por outro. Para mais informações, consulte Troca.
Empregabilidade
É um segredo aberto que muitas empresas têm requisitos rígidos para desenvolvedores que conhecem um framework específico. Eles podem ignorar seus conhecimentos de fundamentos da Web e se concentrar apenas no que você sabe sobre um determinado framework JavaScript. Certo ou errado, essa é a realidade de muitos empregos.
O conhecimento de algumas bibliotecas JavaScript não vai prejudicar sua candidatura, mas não há garantia de que isso vai fazer você se destacar. Se você conhece bem alguns frameworks JavaScript conhecidos, há uma boa chance de os empregadores considerarem esse conhecimento favorável no mercado de trabalho atual para desenvolvedores Web. Algumas organizações corporativas grandes estão presas a frameworks JavaScript muito antigos e podem até estar desesperadas por candidatos que se sintam confortáveis com esses frameworks.
Você pode usar esse segredo aberto a seu favor. No entanto, aborde o mercado de trabalho com cautela e com estas considerações em mente:
- Lembre-se de que, se você passar muito tempo na sua carreira com apenas um framework, pode perder experiências de aprendizado com outros frameworks mais modernos.
- Considere um desenvolvedor que não entende bem os fundamentos do desenvolvimento de software ou de Web, mas é contratado como desenvolvedor de framework. Esse desenvolvedor não escreve código eficaz, e você pode achar que trabalhar em uma base de código assim é muito difícil. Em alguns casos, esse cenário pode levar ao esgotamento. Por exemplo, talvez seja necessário refatorar o código ou ajustar o desempenho porque ele é lento.
- Quando você aprende desenvolvimento da Web, o melhor caminho é começar com um foco intenso nos fundamentos do desenvolvimento da Web, do desenvolvimento de software e da engenharia de software. Essa base sólida ajuda você a escolher qualquer framework JavaScript de forma rápida e eficaz.
Conclusão
Parabéns por entender como as bibliotecas e frameworks JavaScript se comparam. Você não vai escolher frameworks ou bibliotecas com frequência, a menos que trabalhe em projetos greenfield ou como consultor. No entanto, quando essas decisões surgem, quanto mais conhecimento você tiver sobre o assunto, mais informada será sua decisão.
Como você aprendeu, a escolha do framework e, em alguns casos, da biblioteca, pode afetar significativamente sua experiência de desenvolvimento e os usuários finais, como no desempenho.