A diferença entre bibliotecas e frameworks JavaScript

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.
  • Qualitativo: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. Os outros sites parecem usar códigos de terceiros nos 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 estrutura hoje?" é uma pergunta incomum. Bibliotecas e frameworks são duas coisas muito diferentes. No entanto, bibliotecas e frameworks são frequentemente 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 encontrar códigos de terceiros com outros nomes, como widgets, plug-ins, polyfills ou pacotes. No entanto, todos eles geralmente se enquadram na categoria de uma biblioteca ou um framework. Basicamente, a diferença entre os dois pode ser resumida da seguinte forma:

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. Há muito pouca mágica envolvida:

  1. Uma instrução import importa a biblioteca lodash para o programa JavaScript.
  2. O método capitalize() é invocado.
  3. Um único argumento é transmitido para o método.
  4. 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 da biblioteca anterior, vai 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 a Vue escreve a string 'Hello, world' na página é ocultada de você.
  • 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.
  • A estrutura determina um sistema de modelo HTML específico em vez de usar seu próprio sistema.
  • 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ê vai começar a entender quando usar uma ou outra:

  • Um framework pode reduzir a complexidade para você, 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 nelas.
  • 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 a biblioteca ou o 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. Pode ser necessário trocar um pacote quando:

  • É necessário fazer atualizações em um pacote que não está mais sendo 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ê trabalha nesse código e precisa substituir o pacote de terceiros, é necessário atualizar o código em três locais.

Outra opção é simplificar a manutenção e abstrair o uso da biblioteca em um só 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.
  • A estrutura é mal documentada e requer muitas tentativas e erros para resolver os problemas.
  • O framework usa técnicas que não são familiares para você e sua equipe.

Os frameworks podem mitigar esses desafios usando 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 gratuitos. Depois de consumir este conteúdo, você estará produtivo com a estrutura.
  • O framework oferece uma API que segue convenções de codificação comuns. Você é produtivo com o framework porque aprendeu essas convenções e está mais familiarizado com os estilos de codificação.

Embora esses pontos sejam normalmente 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 workshops, guias e documentação, entre outros recursos, o que afeta 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 um aspecto da performance da Web, mas tem um grande efeito na performance, 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 código JavaScript, há uma etapa útil conhecida como tree shaking, uma ferramenta valiosa de otimização de desempenho que pode ser feita no código, embora seja mais fácil de fazer com bibliotecas do que 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 todos combinados no arquivo output.js, que é o arquivo de saída carregado no app da Web.

Para entender melhor o tree shaking, 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 um aspecto da performance da Web, mas tem um grande efeito na performance, especialmente com bibliotecas maiores. Normalmente, o tree shaking é mais simples 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, menor será o desempenho do seu app e maior será o efeito de desempenho na experiência do usuário.

Se uma biblioteca aumentar de tamanho, você poderá usar o tree shaking para reduzir o crescimento. Como alternativa, você pode usar uma alternativa menor para a biblioteca JavaScript. Para mais informações, consulte Troca.

Se um framework crescer de tamanho, não apenas o tree shaking será um desafio, mas também será mais difícil trocar um framework por outro. Para mais informações, consulte Possibilidade de 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. Essa é a realidade de muitos empregos, certo ou errado.

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 tendo em mente estas considerações:

  • 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 da 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, isso pode causar esgotamento. Por exemplo, talvez seja necessário refatorar o código ou ajustar o desempenho porque ele é lento.
  • Quando você aprender sobre desenvolvimento na Web, o melhor caminho é começar com um grande foco nos fundamentos do desenvolvimento Web, desenvolvimento de software e engenharia de software. Uma base tão sólida ajuda você a adotar qualquer estrutura de JavaScript de maneira 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 a performance.