jQuery: usar ou não usar?

Esta é uma questão frequente quando se começa um projeto web, originando por vezes discussões acesas. A resposta rápida é que sim; provavelmente o que se está a desenvolver justifica o seu uso.


Artigo originalmente publicado na Revista PROGRAMAR, edição n.º 46, Setembro 2014.

Quando pondera a utilização de qualquer framework ou biblioteca (em qualquer projeto de software) deve questionar se os ganhos compensam o peso extra, ou seja, se a complexidade do problema o justifica:

CodeCogsEqn

Assim, há que considerar:

  1. Curva de aprendizagem: instalação, primeiros passos, …;
  2. Peso antes de runtime: impactos nos tempos iniciais (ex: de deploy, de download) e noutros recursos;
  3. Peso em runtime: gastos extra de memória (RAM), de rede e de processador: colocar uma camada à frente, por mais “fina” que seja, no cômputo geral, pode ser significativo;
  4. Liberdade do uso: a instalação e/ou adição de uma biblioteca não deve forçar o seu uso;
  5. Abstração indevida: ao se fazer tudo em alto nível, perde-se a noção do que se passa “por baixo”, o que é imprudente.

No que toca ao jQuery:

  1. Curva de aprendizagem: para começar a usar jQuery basta incluir um ficheiro JavaScript; as suas instruções de código são coerentes e simples e portanto de aprendizagem muito natural;
  2. Peso antes de runtime: cerca de 90KB (versão minified). Além disso, o uso de CDN (servidores que permitem ao browser reutilizar ficheiros em cache) tornam isso quase irrelevante;
  3. Peso em runtime: na grande maioria dos casos, o preço a pagar são apenas alguns milisegundos extra (poupam-se horas de desenvolvimento); é certo que se devem aplicar boas práticas (ex. caching de variáveis, boa utilização de seletores, …) mas são quase as mesmas que em JavaScript puro. Onde o uso direto de JavaScript for determinante em termos de velocidade, pode-se sempre fazê-lo…
  4. Liberdade do uso: após ser incluida, a biblioteca jQuery só é usada se se quiser; se nunca se usar, o único peso extra é o do seu download (se se usar um CDN, nem isso);
  5. Abstração indevida: asumindo que ninguém deve aprender jQuery sem estar fluente em JavaScript e que o código jQuery é aberto e disponível (para não falar das ferramentas de desenvolvimento dos browsers), não há desculpa para se fazerem as coisas sem se ter noção dos seus impactos… De qualquer forma, mais tarde ou mais cedo, o programador irá lidar com os problemas de baixo nível.

Algumas das vantagens que o jQuery traz, como o suporte cross-browser (onde se incluem browsers mobile), podem ser colmatadas com microframeworks, pollyfills ou scripts do próprio programador (ou até uma abordagem declarativa, usando por exemplo o AngularJS), mas as principais vantagens: coerência, simplicidade, expansibilidade via plugins (ex: jQuery UI), suporte da comunidade, uma API fluida, constantes atualizações, entre outras… ficam pelo caminho.

É verdade que com o jQuery está a simplificar muitas tarefas, muito por culpa da sua API de alto nível; os ganhos para o programador são elevados, sendo difícil negar o seu uso (podemos até argumentar que ajudou a democratizar o desenvolvimento web, permitindo a todos “fazer sites”). Para os fãs, poupa muitas horas de trabalho (ex: mudar a cor dos elementos com uma classe pode passar de 5 linhas para 1); tanto para um amador fazer um pequeno site informativo (com algumas animações), como para um profissional desenvolver um backoffice, o jQuery pode ser de grande ajuda.

Contudo, em software, a complexidade não se elimina, apenas se transfere. Ao usar jQuery, está a aumentar a complexidade para o browser, que tem de realizar mais operações, gastando mais tempo e memória. A questão é: será isso desprezível? Para os puristas, o peso, muitas vezes, não compensa o seu uso. Mas se fôssemos a pensar nos “6 ou 7 milisegundos” ganhos pelo uso direto de uma linguagem, nunca se tinham inventado linguagens de alto nível como o Java ou o C# e ainda estaríamos a programar em Assembly. Num mundo de sites e aplicações web tendencialmente mais complexas, o programador tem de se munir de ferramentas que lhe permitam evitar reinventar a roda, focando-se mais nos problemas do negócio e menos nos dos computadores. De qualquer forma, isto não quer dizer que a velocidade não seja importante. O programador deve saber os impactos das suas decisões, fazendo testes de velocidade, quando em dúvida.

O Flash, durante muitos anos tomou conta das animações da web. Contudo, trazia atrás os seus inúmeros problemas ligados a consumo extra, portabilidade, integração, SEO, usabilidade e acessibilidade. O jQuery e os seus plugins deram um enorme contributo para que se fizessem uso dos standards da web. Hoje, pode afirmar-se que a web está praticamente livre do Flash.

Há que ser pragmático: na maioria dos projetos web as vantagens do jQuery suplantam de longe as desvantagens: até para as coisas mais simples pode ser uma lufada de ar fresco, poupando muitas linhas de código e algumas dores de cabeça. “Usar sempre” ou “nunca usar” jQuery são argumentos extremos a evitar. Cada caso é um caso e raramente há soluções universais. Considere alternativas consoante a situação (por exemplo, o AngularJS). É por esta não ser uma resposta trivial que surgiram alguns mitos jQuery

Saber mais…

Livro que escrevi sobre jQuery


O uso de jQuery nos principais sites

O uso de jQuery perante outras bibliotecas JavaScript

O jQuery no Google Trends


O jQuery em ofertas de emprego

One thought on “jQuery: usar ou não usar?

Deixar uma resposta