Escolher um framework ou uma biblioteca JavaScript

Umar Hansa

Este artigo compartilha insights sobre como escolher uma biblioteca ou um framework para usar no seu aplicativo da Web. As discussões aqui irão ajudá-lo a ponderar os prós e contras ao encontrar a biblioteca JavaScript ou estrutura certa para o problema de negócios que você está tentando resolver. Entender quais prós e contras se aplicam a diferentes situações é fundamental para avaliar o grande número de opções de biblioteca JavaScript disponíveis.

O que são bibliotecas e frameworks JavaScript

O que é uma biblioteca JavaScript? Na forma mais simples, uma biblioteca JavaScript é um código pré-escrito que pode ser chamado no código do projeto para realizar uma tarefa específica.

Esta postagem menciona principalmente "bibliotecas". No entanto, muitas das discussões também são aplicáveis a frameworks. Basicamente, a diferença entre os dois pode ser resumida da seguinte maneira:

  • Para uma biblioteca, o código do aplicativo chama o código da biblioteca.
  • No caso de um framework, o código do aplicativo é chamado por ele.

Os exemplos práticos a seguir ajudam a ilustrar as diferenças.

Exemplo de chamada para uma biblioteca JavaScript

Uma biblioteca JavaScript executa uma tarefa específica e retorna o controle ao aplicativo. Ao usar uma biblioteca, você controla o fluxo do aplicativo e escolhe quando chamar a biblioteca.

No exemplo abaixo, o código do aplicativo importa um método da biblioteca lodash. Depois que a função é concluída, o controle é retornado ao aplicativo.

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

Quando o método lodash.capitalize é executado, ele chama o código JavaScript pré-escrito que torna o primeiro caractere de uma string em maiúsculas.

Exemplo de uso de um framework JavaScript

Um framework JavaScript é um modelo de código predefinido em que você constrói o comportamento do seu aplicativo. Ou seja, quando você usa um framework, ele controla o fluxo do aplicativo. Para usar um framework, você escreve o código do aplicativo personalizado e, em seguida, o framework chama o código do aplicativo.

O exemplo a seguir mostra um snippet de código que usa o framework JavaScript Preact:

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

No exemplo, observe que o framework tem muito mais controle sobre o código que você escreve e, em alguns casos, até mesmo controla quando executar o código.

Por que usar uma biblioteca?

O uso de uma biblioteca JavaScript pode ajudar a evitar a repetição de código desnecessária. As bibliotecas podem abstrair a lógica complexa, como a manipulação de datas ou cálculos financeiros. Uma biblioteca também pode ajudar a lançar seu produto inicial, em vez de ter que escrever todo o código do zero, o que pode levar tempo.

Algumas bibliotecas JavaScript do lado do cliente ajudam a abstrair peculiaridades da plataforma da Web. Uma biblioteca também pode servir como uma ferramenta de aprendizagem. Por exemplo, se você não conhece as funções de transição de animação, o código-fonte de uma biblioteca pode ensinar como elas funcionam.

Algumas bibliotecas são apoiadas por grandes empresas que investem tempo e dinheiro para manter as bibliotecas atualizadas e seguras. Muitas bibliotecas são acompanhadas de uma documentação extensa, que oferece a você e sua equipe uma maneira rápida de se familiarizar com o uso da biblioteca.

No fim das contas, usar uma biblioteca JavaScript economiza tempo.

Por que o uso da biblioteca é importante?

Tecnicamente, é possível desenvolver seu aplicativo da Web do zero, mas por que se dar ao trabalho se você pode usar softwares gratuitos (de código aberto) ou comprar uma solução que, a longo prazo, pode economizar tempo e dinheiro? Há um grande número de bibliotecas e frameworks JavaScript disponíveis, cada um com uma abordagem única para resolver problemas e características diferentes. Exemplo:

  • Uma biblioteca pode ser gravada e mantida internamente, em vez de por terceiros.
  • Uma biblioteca pode ter licenças legais específicas que a tornam adequada ou inadequada para seu aplicativo da Web.
  • Uma biblioteca pode estar desatualizada ou sem manutenção.
  • Uma biblioteca pode simplificar um conjunto de tarefas complexas e economizar muito tempo e dinheiro.
  • Uma biblioteca pode ser amplamente usada na comunidade e pode ser bem conhecida entre os desenvolvedores.

Como você pode imaginar, características diferentes podem afetar seu aplicativo da Web de maneiras diferentes. Às vezes, a decisão não é tão profunda, e você pode trocar uma biblioteca com segurança se não gostar dela. No entanto, às vezes, uma biblioteca pode ter um efeito significativo no seu trabalho e no seu aplicativo da Web, o que sugere que uma abordagem mais informada pode ser necessária.

Existem alguns ambientes JavaScript que não são do lado do cliente, como no servidor (executado em um ambiente de nuvem) ou em um Raspberry Pi, em que talvez seja necessário ajustar os critérios usados para verificar bibliotecas e frameworks.

Desempenho

O efeito de desempenho de uma biblioteca JavaScript em um aplicativo da Web do lado do cliente não deve ser ignorado. Uma biblioteca JavaScript grande pode atrapalhar o desempenho de carregamento da página. Lembre-se de que milissegundos geram milhões.

Considere um cenário em que você usa uma biblioteca JavaScript para animação. Algumas bibliotecas podem adicionar facilmente dezenas de kilobytes e, em alguns casos, até centenas de kilobytes. Recursos JavaScript como esse podem causar um atraso significativo no carregamento da página, já que o navegador precisa fazer o download, analisar, compilar e executar o código.

Quanto maior a biblioteca JavaScript, maior o efeito de desempenho nos usuários.

Ao avaliar ou usar uma biblioteca ou framework de JavaScript, considere as seguintes sugestões para melhorar o desempenho:

  • Se você tiver uma biblioteca JavaScript grande, considere usar uma alternativa menor. Por exemplo, date-fns oferece muitas funcionalidades em um tamanho mais razoável do que algumas outras opções.
  • Seguindo o exemplo anterior de funções de data, importe apenas as funções necessárias, como import { format } from 'date-fns'. Combine essa abordagem com o tree shaking para que um payload mínimo do JavaScript seja criado e enviado aos usuários.
  • Use ferramentas de teste de desempenho, como o Lighthouse, para observar o efeito de desempenho de uma determinada biblioteca JavaScript. Se uma biblioteca adicionar um atraso de um segundo ao tempo de carregamento da página (não se esqueça de limitar sua rede e CPU durante os testes), talvez seja necessário reavaliar sua biblioteca preferida. Além de verificar o carregamento da página, faça o perfil de qualquer comportamento da página da Web que invoque o código da biblioteca em questão. O desempenho do carregamento da página não conta toda a história.
  • Se o autor da biblioteca aceitar comentários, envie suas observações de desempenho, sugestões e até mesmo contribuições para o projeto. É aqui que a comunidade de código aberto brilha! Se você decidir fazer uma contribuição, talvez precise consultar seu empregador primeiro.
  • Use uma ferramenta automatizada de rastreamento de pacotes, como o bundlesize, para procurar atualizações grandes e inesperadas em uma biblioteca. É comum que uma biblioteca JavaScript cresça com o tempo. Adições de recursos, correções de bugs, casos extremos e outros podem aumentar o tamanho do arquivo de uma biblioteca. Depois que você ou sua equipe concordarem em usar uma biblioteca, atualizá-la pode ser menos um problema e pode gerar poucas ou nenhuma pergunta. É aqui que vale a pena confiar na automação.
  • Analise seus requisitos para uma biblioteca e avalie se a plataforma da Web oferece ou não a mesma funcionalidade de forma nativa. Por exemplo, a plataforma da Web já oferece um seletor de cores, que elimina a necessidade de usar uma biblioteca JavaScript de terceiros para implementar a mesma funcionalidade.

Segurança

O uso de um módulo de terceiros envolve alguns riscos de segurança inerentes. Um pacote malicioso na base de código do seu aplicativo da Web pode comprometer a segurança da equipe de desenvolvimento e dos usuários.

Considere uma biblioteca publicada no ecossistema do NPM. Esse pacote pode ser legítimo. No entanto, com o tempo, o pacote pode ser comprometido.

Confira algumas dicas de segurança para usar ou avaliar códigos de terceiros:

  • Se você usa o GitHub, considere as ofertas de segurança do código, como o Dependabot. Ou considere serviços alternativos que verificam vulnerabilidades no código, como o snyk.io.
  • Considere usar serviços de auditoria de código, uma equipe de engenheiros que pode auditar manualmente o código de terceiros que você está usando.
  • Avalie se você precisa bloquear as dependências para uma versão específica ou confirmar o código de terceiros no controle de versões. Isso pode ajudar a bloquear sua dependência em uma versão específica, que provavelmente é considerada segura. Ironicamente, isso pode ter um efeito contrário na segurança, já que você pode perder atualizações importantes da biblioteca.
  • Verifique a página inicial do projeto ou a página do GitHub, se houver. Verifique se há problemas de segurança pendentes e se os problemas anteriores foram resolvidos em um período razoável.
  • O código de terceiros que usa outros códigos de terceiros pode apresentar mais riscos do que uma biblioteca com zero dependências. Tenha cuidado com esse risco.

Acessibilidade

Você pode estar se perguntando como as bibliotecas de software estão relacionadas à acessibilidade da Web. Embora uma biblioteca de software possa ser usada em diferentes ambientes, no contexto de uma biblioteca baseada em JavaScript do lado do cliente, a acessibilidade da Web é de grande importância.

Uma biblioteca (ou framework) baseada em JavaScript do lado do cliente pode aumentar ou diminuir a acessibilidade do seu site. Considere uma biblioteca JavaScript de terceiros que adiciona um controle deslizante de imagem a uma página. Se o controle deslizante de imagens não considerar a acessibilidade da Web, você, como desenvolvedor da Web, poderá ignorar esse recurso importante e lançar um produto que não tem recursos essenciais, como a navegação pelo teclado.

  • O plug-in de tipografia responsiva oferece suporte a usuários que aumentam ou diminuem o zoom da página?
  • O plug-in do envio de arquivos oferece suporte a envios de arquivos de dispositivos com recursos de acessibilidade?
  • A biblioteca de animação oferece suporte a usuários que preferem movimentos reduzidos?
  • O plug-in de mapas interativos oferece suporte ao uso apenas com teclado?
  • A biblioteca do player de áudio oferece uma experiência adequada em leitores de tela?

É razoável esperar que você, desenvolvedor da Web, precise de algum nível de envolvimento para atender a esses requisitos de acessibilidade. Exemplo:

  • Para recursos ausentes, você pode implementar esses recursos na sua base de código, mesmo que continue usando a biblioteca em questão.
  • Com o apoio do seu empregador, você pode contribuir com esse recurso ausente na biblioteca, se o autor da biblioteca permitir essa contribuição.
  • Você pode abrir uma caixa de diálogo com o autor da biblioteca. Por exemplo, esses recursos específicos de acessibilidade estão no seu roteiro? Você concorda que elas pertencem à biblioteca?
  • Para casos de uso comuns, você pode conferir opções de biblioteca alternativas mais acessíveis, que podem existir, mas são mais difíceis de encontrar.
  • Em casos extremos, talvez seja necessário abandonar uma biblioteca completamente e implementar seus recursos do zero. Isso pode acontecer quando uma biblioteca ou framework tem uma experiência de acessibilidade prejudicada no uso inicial, e você precisa desfazer muito do que a biblioteca ou framework supostamente oferece sem custo financeiro.

Convenções

É mais fácil trabalhar com uma biblioteca de software que usa convenções de programação estabelecidas. Se uma biblioteca usa uma convenção de codificação inédita, pode ser difícil para você e sua equipe trabalharem com ela.

Se uma biblioteca não seguir convenções de programação comuns (por exemplo, um guia de estilo comum), não há muito que você possa fazer como correção imediata. No entanto, ainda existem algumas opções:

  • Faça a distinção entre o código-fonte da biblioteca e a API exposta a você, o usuário da biblioteca. Embora o código-fonte interno possa usar convenções desconhecidas, se a API (a parte da biblioteca com que você interage) usar convenções conhecidas, talvez não haja motivos para preocupação.
  • Se a API da biblioteca não seguir convenções de programação comuns, use um padrão de design JavaScript, como o padrão de proxy, para agrupar e conter todas as interações com a biblioteca em um único arquivo na base de código. O proxy pode oferecer uma API mais intuitiva para outras partes do código na base de código.

As convenções desempenham um papel importante na facilidade de uso. Uma biblioteca que inclui uma API intuitiva pode economizar muitas horas de trabalho ou até mesmo dias de trabalho, quando comparada a uma API não intuitiva que precisa de muita experimentação para ser compreendida.

Atualizações

Por exemplo, para uma biblioteca totalmente funcional que realiza alguns cálculos matemáticos, essa biblioteca raramente precisa de atualizações. Na verdade, uma biblioteca completa é uma descoberta rara no mundo em constante mudança do desenvolvimento da Web. No entanto, há momentos em que você quer que o autor da biblioteca seja responsivo e esteja disposto a fazer atualizações. Novas pesquisas e descobertas podem revelar maneiras melhores de fazer as coisas, então as técnicas usadas em bibliotecas e frameworks estão sempre sujeitas a mudanças.

Ao escolher uma biblioteca ou framework, preste atenção em como as atualizações são processadas e saiba que essas decisões podem afetar você:

  • A biblioteca tem um cronograma de lançamento razoável? Por exemplo, as atualizações do repositório de código-fonte podem acontecer com frequência, mas, se elas não forem "publicadas" ou "lançadas", pode ser difícil fazer o download delas.
  • A biblioteca lança atualizações com um esquema razoável de versão de software? Uma biblioteca deve economizar seu tempo. Se você tiver que alterar inesperadamente o código sempre que atualizar a versão da biblioteca, isso pode anular o propósito de usar essa biblioteca em primeiro lugar. Às vezes, as mudanças de ruptura são inevitáveis, mas, no mundo ideal, elas são raras e não são forçadas aos consumidores da biblioteca.
  • A biblioteca investe esforços na compatibilidade com versões anteriores? Às vezes, as atualizações de software podem trazer mudanças importantes, mas também oferecem uma camada de compatibilidade com versões anteriores. Isso permite que o consumidor da biblioteca use a versão mais recente com mudanças mínimas no código.

Licenciamento

A licença de software é um aspecto importante do uso de bibliotecas de software de terceiros. O autor de uma biblioteca pode atribuir uma licença a ela. Se você está pensando em usar a biblioteca, a escolha de licença dele pode afetar você.

Por exemplo, uma biblioteca JavaScript pode ter uma licença de software que permite o uso em um ambiente não comercial. Para um projeto pessoal, essa pode ser uma ótima escolha. Se o projeto tiver um elemento comercial, talvez seja necessário considerar uma licença empresarial.

Em caso de dúvida, procure orientação jurídica profissional ou consulte a equipe jurídica da sua empresa.

Comunidade

Uma biblioteca ou framework com uma grande comunidade de usuários/colaboradores pode ser benéfico, mas isso não é garantia. Em geral, quanto mais usuários uma biblioteca ou framework tiver, maior será o benefício. Considere os seguintes prós e contras da participação em uma comunidade de desenvolvimento:

Vantagens:

  • Uma base de usuários grande pode significar uma maior chance de bugs serem detectados cedo e com frequência.
  • Uma comunidade grande e ativa pode significar mais tutoriais, guias, vídeos e até cursos sobre a biblioteca ou framework em questão.
  • Uma grande comunidade ativa pode significar mais suporte em fóruns e sites de perguntas e respostas, aumentando a probabilidade de que perguntas de suporte sejam respondidas.
  • Uma comunidade engajada pode significar mais colaboradores externos para a biblioteca ou o framework. Eles podem ajudar a entregar recursos que não estão no cronograma do autor.
  • Quando uma biblioteca ou framework é popular em uma comunidade, é mais provável que seus colegas e colegas de trabalho tenham ouvido falar ou até mesmo conheçam essa biblioteca ou framework.

Desvantagens:

  • Um projeto com uma base de usuários grande e diversificada pode ficar inchado com a adição constante de recursos. Bibliotecas inchadas podem prejudicar a performance da Web.
  • Um projeto com uma comunidade ativa e engajada pode ser estressante para os autores e mantenedores e exigir uma moderação intensa.
  • Um projeto que cresce rapidamente, mas não conta com o apoio adequado, pode começar a exibir sinais de ter uma comunidade tóxica. Por exemplo, desenvolvedores web iniciantes ou júnior podem se sentir indesejáveis em uma determinada comunidade por conta do controle de acesso.

Documentação

Não importa o quão simples ou complexa seja uma biblioteca ou framework JavaScript, a documentação do software sempre pode ajudar. Até mesmo desenvolvedores muito experientes usam a documentação em vez de descobrir o código por conta própria. A documentação esclarece qual API você precisa usar e como usá-la.

A documentação pode até mesmo fornecer exemplos de código, facilitando os primeiros passos. Ao avaliar uma biblioteca ou framework, você pode fazer algumas destas perguntas:

  • A biblioteca inclui documentação? Se não tiver, você precisará se sentir confortável para descobrir as coisas por conta própria.
  • A documentação é clara, fácil de entender e sem ambiguidades? Muitos desenvolvedores gastam muito tempo na documentação. Pode parecer pouco, mas a clareza na documentação textual pode ter um grande efeito na sua produtividade.
  • A documentação é gerada completamente de forma automática? Essa documentação pode ser mais difícil de entender e nem sempre oferece orientações claras sobre como usar uma API.
  • A documentação está atualizada? Às vezes, a manutenção da documentação é tratada como uma etapa posterior. Se a biblioteca for atualizada, mas a documentação não, isso pode levar a um tempo de desenvolvimento desperdiado.
  • A documentação é abrangente e está disponível em vários formatos? Guias do usuário, exemplos de código, documentação de referência, demonstrações ao vivo e tutoriais são formatos de documentação valiosos que podem ajudar você a usar uma biblioteca ou framework.

A documentação nem sempre pode ser completa, e tudo bem. Você vai precisar avaliar as necessidades da sua organização, os requisitos do projeto e a complexidade do software e usar isso para determinar o nível de documentação necessário.

Conclusão

É normal se sentir sobrecarregado ao escolher uma biblioteca ou framework pela primeira vez. Assim como tudo, quanto mais você aprende e pratica uma tarefa, melhor você fica. Consulte esta postagem na próxima vez que escolher uma biblioteca ou framework. Você pode usar os títulos desta postagem como uma lista de verificação. Por exemplo: essa biblioteca tem bom desempenho? A biblioteca atende aos padrões de acessibilidade na Web dos meus negócios?

Há outros aspectos de bibliotecas e frameworks que você pode considerar e que não foram muito discutidos neste post:

  • Extensibilidade: quão fácil é estender a biblioteca com lógica e/ou comportamento personalizado?
  • Ferramentas:se aplicável, a biblioteca tem ferramentas como plug-ins de editor de código, ferramentas de depuração e plug-ins do sistema de build?
  • Arquitetura: um código limpo é importante, mas a arquitetura geral da biblioteca é sensata?
  • Testes: o projeto tem um conjunto de testes? O site do projeto usa selos ou indicadores de que o pacote de teste está sendo aprovado na confirmação mais recente?
  • Compatibilidade: a biblioteca funciona bem com outras bibliotecas e/ou frameworks que você está usando?
  • Custo: qual é o custo de um framework? É de código aberto ou está disponível para compra?
  • Métricas de vaidade:elas devem estar na parte de baixo da lista de critérios ou até mesmo ser ignoradas. No entanto, você pode considerar os "votos" do projeto, as contas de mídia social que representam o projeto e/ou quantos bugs/problemas abertos há na página do projeto.