O jQuery tornou o JavaScript mais fácil com seleção DOM simples, eventos e AJAX. Saiba o que é, por que decaiu e quando ainda faz sentido hoje.

jQuery é uma pequena biblioteca JavaScript que facilita tarefas comuns em uma página web — coisas como selecionar elementos, reagir a cliques, alterar texto, mostrar/ocultar partes da página e enviar requisições a um servidor.
Se você já viu código como $("button").click(...), isso é jQuery. O $ é apenas um atalho para “encontrar algo na página e fazer algo com isso.”
Este guia é prático e não‑técnico: o que é jQuery, por que ficou popular, por que projetos mais novos não o adotam tanto, e como lidar com ele se seu site ainda o usa. É propositalmente mais longo para incluir exemplos claros e orientações do mundo real em vez de opiniões rápidas.
Quando as pessoas dizem que jQuery está “esquecido”, geralmente não querem dizer que desapareceu. Querem dizer:
Então a história não é “jQuery está morto.” É mais: jQuery deixou de ser a ferramenta padrão de front‑end e virou uma dependência legada que você pode herdar — e, ocasionalmente, ainda optar por usar de propósito.
Antes do jQuery, o trabalho de front‑end muitas vezes significava escrever os mesmos trechos pequenos e irritantes repetidas vezes — e então testá‑los em vários navegadores e descobrir que se comportavam de forma diferente. Mesmo objetivos simples como “encontrar este elemento”, “anexar um manipulador de clique” ou “enviar uma requisição” podiam se transformar em uma pilha de casos especiais.
Muito do JavaScript inicial focava menos em construir funcionalidades e mais em lidar com o ambiente. Você escrevia código que funcionava em um navegador e então adicionava ramos extras para fazê‑lo funcionar em outro. Equipes mantinham suas próprias “mini bibliotecas” de funções auxiliares só para sobreviver às mudanças diárias de UI.
O resultado: desenvolvimento mais lento, mais bugs e um medo constante de que uma mudança mínima quebrasse um navegador antigo que seus usuários ainda usavam.
Os navegadores não concordavam sobre detalhes importantes. Métodos de seleção do DOM, tratamento de eventos e até como obter o tamanho de um elemento podiam variar. O Internet Explorer, em particular, tinha APIs diferentes para eventos e requisições XMLHTTP, então código “padrão” nem sempre era realmente portátil.
Isso importava porque sites não eram construídos para um único navegador. Se seu formulário de checkout, menu de navegação ou diálogo modal falhasse em um navegador popular, era um problema real de negócio.
jQuery se tornou relevante porque oferecia uma API consistente e amigável que amenizava essas diferenças.
Tornou tarefas comuns dramaticamente mais simples:
Igualmente importante, o estilo “write less, do more” do jQuery ajudou equipes a entregar mais rápido com menos surpresas específicas de navegador — especialmente numa época em que as “APIs DOM modernas” não eram tão capazes ou amplamente suportadas como hoje.
O verdadeiro superpoder do jQuery não foi introduzir ideias totalmente novas — foi tornar tarefas comuns do navegador consistentes e fáceis entre diferentes navegadores. Se você lê código front‑end antigo, normalmente verá jQuery usado para quatro tarefas do dia a dia.
$)A função $() permitia “pegar” elementos usando seletores parecidos com CSS e depois trabalhar com eles em grupo.
Em vez de lidar com peculiaridades de navegador e APIs verbosas, você podia selecionar todos os itens, encontrar um elemento filho ou subir até o pai com chamadas curtas e encadeáveis.
jQuery facilitou responder a ações do usuário:
click para botões e linkssubmit para formuláriosready para rodar código quando a página carregavaTambém suavizava diferenças em como navegadores tratavam objetos de evento e ligação, o que era muito importante quando o suporte entre navegadores era desigual.
Antes do fetch() ser padrão, $.ajax(), $.get() e $.post() do jQuery eram uma maneira direta de solicitar dados a um servidor e atualizar a página sem recarregar.
Isso tornou possíveis padrões que hoje parecem normais — busca ao digitar, botões “carregar mais”, atualizações parciais de página — usando uma API única e familiar.
jQuery popularizou toques rápidos de UI como hide(), show(), fadeIn(), slideToggle() e animate(). Eram convenientes para menus, notificações e transições básicas — especialmente quando o suporte a CSS era menos confiável.
Somadas, essas conveniências explicam por que código JavaScript legado frequentemente começa com $( e por que jQuery permaneceu uma ferramenta padrão por tanto tempo.
Boa parte da reputação do jQuery vem de quanto pouco código era necessário para tarefas comuns de UI — sobretudo quando diferenças entre navegadores eram dolorosas. Um comparativo ajuda a ver isso.
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
Moderno (vanilla) JavaScript
// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');
saveButton?.addEventListener('click', (e) => {
e.preventDefault();
if (status) status.textContent = 'Saved!';
});
À primeira vista, a versão jQuery parece “mais limpa”: um encadeamento seleciona o elemento, anexa um handler e atualiza o texto. Essa concisão foi um grande ponto de venda.
O JavaScript moderno é um pouco mais verboso, mas também mais explícito:
querySelector e addEventListener dizem exatamente o que está acontecendo.textContent é uma propriedade padrão do DOM (sem wrapper de biblioteca).?.) e checagens nulas deixam claro o que acontece se elementos não existirem.Depende do contexto. Se você mantém uma base de código antiga que já usa jQuery por toda parte, o trecho em jQuery pode ser mais consistente e mais rápido de trabalhar. Se você está escrevendo código novo, APIs DOM modernas são amplamente suportadas, reduzem dependências e se integram melhor com as ferramentas e frameworks atuais.
Durante muito tempo a maior vantagem do jQuery foi previsibilidade. Você podia escrever de uma forma para selecionar elementos, anexar eventos ou fazer uma requisição — e isso funcionava na maioria dos lugares.
Com o tempo, os navegadores padronizaram e melhoraram. Muitas das conveniências que o jQuery agrupava agora estão no próprio JavaScript, então muitas vezes você não precisa de uma biblioteca extra apenas para o básico.
Métodos modernos do DOM cobrem muitos padrões comuns do jQuery:
document.querySelector() / document.querySelectorAll() substituem $(...) para muitas seleções.element.classList.add() / .remove() / .toggle() cuidam da manipulação de classes.element.addEventListener() substituiu o wrapper de eventos do jQuery para a maioria dos casos de uso.Em vez de lembrar helpers específicos do jQuery, você pode confiar em APIs padrão que funcionam nos navegadores modernos.
Onde $.ajax() costumava ser a solução, fetch() agora lida com muitas requisições do dia a dia com menos cerimônia, especialmente quando combinado com JSON:
const res = await fetch('/api/items');
const data = await res.json();
Ainda é preciso tratar erros e timeouts explicitamente, mas a ideia central — fazer requisições sem plugin — é agora nativa.
jQuery apresentou muita gente ao código assíncrono via callbacks e $.Deferred. Hoje, Promises e async/await tornam fluxos assíncronos mais legíveis, e módulos ES tornam mais claro como o código é organizado.
Essa combinação — APIs DOM modernas + fetch + recursos de linguagem modernos — removeu grande parte do motivo original pelo qual equipes recorriam ao jQuery por padrão.
jQuery cresceu na era dos “sites multi‑página”: o servidor renderizava HTML, o navegador carregava a página, e você “polvilhava” comportamento — handlers de clique, animações, chamadas AJAX — sobre o markup existente.
Frameworks modernos inverteram esse modelo. Em vez de apenas enriquecer páginas, apps muitas vezes geram a maior parte da UI no navegador e a mantêm sincronizada com os dados.
React, Vue e Angular popularizaram a ideia de construir interfaces a partir de componentes — pequenas peças reutilizáveis que possuem seu próprio markup, comportamento e estado.
Nesse cenário, o framework quer ser a fonte da verdade para o que está na tela. Ele acompanha estado, re‑renderiza partes da UI quando o estado muda e espera que você expresse mudanças de forma declarativa (“quando X for true, mostre Y”).
jQuery, por outro lado, incentiva manipulação imperativa do DOM (“encontre este elemento, mude seu texto, esconda‑o”). Isso pode conflitar com o ciclo de renderização de um framework. Se você muda manualmente nós do DOM que um componente controla, a próxima re‑renderização pode sobrescrever suas alterações — ou você pode acabar depurando inconsistências.
Com a popularização de SPAs, equipes adotaram ferramentas de build e bundlers (como Webpack, Rollup, Vite). Em vez de apenas colocar algumas tags de script em uma página, você importa módulos, bundleia só o que usa e otimiza para performance.
Essa mudança também tornou as pessoas mais sensíveis a dependências e ao tamanho do bundle. Puxar jQuery “só por precaução” passou a soar menos natural quando cada kilobyte e cada atualização de terceiros faz parte do pipeline.
Você PODE usar jQuery dentro de um framework, mas frequentemente ele vira uma ilha de casos especiais — mais difícil de testar, de raciocinar e mais sujeito a quebrar durante refatores. Como resultado, muitas equipes preferiram padrões nativos do framework em vez de scripts DOM ao estilo jQuery.
jQuery em si não é “enorme”, mas frequentemente vem acompanhado de bagagem. Muitos projetos que dependem de jQuery acumulam também plugins (sliders, date pickers, bibliotecas de modal, validadores), cada um adicionando mais código de terceiros para baixar e parsear. Com o tempo, uma página pode acabar servindo várias utilidades sobrepostas — especialmente quando recursos foram adicionados rapidamente e nunca revisados.
Mais JavaScript geralmente significa mais para o navegador buscar, parsear e executar antes que a página pareça responsiva. Esse efeito é mais perceptível em dispositivos móveis, redes lentas e hardware mais antigo. Mesmo que os usuários eventualmente tenham uma experiência suave, o “tempo até usável” pode sofrer quando a página espera por scripts extras e suas dependências.
Um padrão comum em sites de longa duração é a base de código “híbrida”: algumas funcionalidades escritas com jQuery, partes novas com um framework (React, Vue, Angular) e alguns trechos de JavaScript puro espalhados. Essa mistura pode ficar confusa:
Quando múltiplos estilos coexistem, pequenas mudanças ficam mais arriscadas. Um desenvolvedor atualiza um componente, mas um script jQuery antigo ainda mexe no mesmo markup e causa bugs difíceis de reproduzir.
Equipes tendem a se afastar do jQuery não porque ele “pare de funcionar”, mas porque projetos modernos otimizam por bundles menores e propriedade clara do comportamento da UI. À medida que sites crescem, reduzir código de terceiros e padronizar uma abordagem geralmente torna ajuste de performance, depuração e onboarding mais fáceis.
jQuery não só ficou popular — tornou‑se o padrão. Por anos, foi a forma mais fácil de fazer páginas interativas funcionarem de forma confiável entre navegadores, então acabou embutido em inúmeros templates, snippets, tutoriais e soluções de copiar/colar.
Quando isso acontece, jQuery fica difícil de evitar: mesmo que um site use só um recurso pequeno, frequentemente ele carregava toda a biblioteca porque o resto do código assumia que ela estava lá.
Uma grande razão para jQuery ainda aparecer é simples: seu sucesso o deixou “em todo lugar” no código de terceiros. Widgets de UI antigos, sliders, lightboxes, validadores de formulários e scripts de tema eram comumente escritos como plugins jQuery. Se um site depende de um desses componentes, remover o jQuery pode significar reescrever ou substituir essa dependência — não apenas trocar algumas linhas.
O WordPress é uma grande fonte de “jQuery legado”. Muitos temas e plugins — especialmente criados anos atrás — usam jQuery para comportamento front‑end e, historicamente, telas administrativas do WordPress também dependiam bastante dele. Mesmo quando versões mais novas se movem para JavaScript moderno, a longa cauda de extensões existentes mantém o jQuery presente em muitas instalações.
Sites mais antigos frequentemente priorizam “não quebrar o que funciona”. Manter jQuery pode ser a opção mais segura quando:
Em resumo, jQuery nem sempre é “esquecido” — muitas vezes faz parte da fundação sobre a qual o site foi construído, e fundações não se substituem levianamente.
jQuery não é “ruim”. Ele resolveu problemas reais — especialmente quando navegadores se comportavam de formas diferentes e construir páginas interativas significava escrever muito código repetitivo. O que mudou é que normalmente você não precisa dele para projetos novos. Ainda assim, há situações reais onde manter (ou mesmo adicionar) um pouco de jQuery é a escolha mais prática, especialmente quando o objetivo é tempo, compatibilidade ou estabilidade, não pureza arquitetural.
Se você tem requisitos que incluem navegadores antigos (especialmente versões antigas do Internet Explorer), o jQuery ainda pode simplificar seleção do DOM, tratamento de eventos e AJAX de formas que APIs nativas não cobrem sem polyfills extras.
A questão chave é custo: suportar navegadores legados geralmente significa enviar código extra de qualquer jeito. Nesse contexto, jQuery pode ser parte aceitável do pacote de compatibilidade.
Se um site já foi construído em torno do jQuery, pequenos ajustes de UI são frequentemente mais rápidos e seguros quando feitos no mesmo estilo do restante do código. Misturar abordagens pode gerar confusão (duas formas para eventos, duas formas para manipular o DOM), o que dificulta a manutenção.
Uma regra razoável: se você está mexendo em uma ou duas telas e o app está estável, consertar com jQuery é aceitável — só evite expandir o uso de jQuery para novos “sistemas” que você terá que desfazer depois.
Para um site de marketing simples ou ferramenta interna — sem bundler, sem transpiler, sem framework de componentes — jQuery ainda pode ser um ajudante conveniente via “uma única tag de script”. É especialmente útil quando você quer algumas interações (menus toggle, comportamentos simples de formulário) e não quer introduzir um pipeline de build.
Muitos plugins maduros (date pickers, tabelas, lightboxes) foram construídos sobre jQuery. Se um plugin antigo é crítico para o negócio e estável, manter o jQuery como dependência pode ser a opção de menor risco.
Antes de se comprometer, verifique se existe uma alternativa mantida e sem jQuery — ou se atualizar o plugin for exigir uma reescrita maior do que o projeto pode bancar agora.
Sair do jQuery é menos sobre uma grande reescrita e mais sobre reduzir dependência sem quebrar comportamentos que as pessoas usam. A abordagem mais segura é incremental: mantenha páginas funcionando enquanto troca partes por baixo.
Comece respondendo três perguntas práticas:
Essa auditoria evita substituir coisas desnecessárias e identifica dependências “ocultas” como um plugin que usa $.ajax() silenciosamente.
A maioria das equipes consegue ganhos rápidos trocando padrões simples:
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)Faça isso em PRs pequenos para que seja fácil revisar e reverter.
Se você usa $.ajax(), migre essas chamadas para fetch() (ou um pequeno helper HTTP) um endpoint de cada vez. Mantenha o formato de resposta igual para que o restante da UI não precise mudar imediatamente.
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r => r.json())
.then(renderItems);
Antes de remover o jQuery, adicione cobertura onde importa: fluxos de usuário chave, envios de formulários e qualquer UI dinâmica. Mesmo checagens leves (smoke tests com Cypress ou uma lista de verificação de QA) podem capturar regressões cedo. Lance mudanças por feature flag quando possível e confirme que métricas/erros se mantêm estáveis.
Se quiser segurança extra durante refatores, use ferramentas que suportem snapshots e rollback. Por exemplo, equipes que modernizam front ends legados às vezes prototipam substituições em Koder.ai e usam seu fluxo de snapshot/rollback para iterar sem perder uma versão “conhecida e boa”.
Se precisar de ajuda para organizar o plano geral, veja /blog/jquery-vs-vanilla-js para um comparativo que você pode usar durante refatores.
Migrar longe do jQuery costuma ser menos sobre “trocar sintaxe” e mais sobre desvencilhar anos de suposições. Aqui estão os truques que atrasam equipes — e como evitá‑los.
Uma reescrita completa soa limpa, mas costuma gerar uma branch de longa duração, muitas regressões e pressão para entregar trabalho inacabado. Abordagem mais segura: incremental — substitua uma funcionalidade ou página por vez, mantenha o comportamento idêntico e adicione testes nas partes que tocar.
Se você introduz React/Vue/Svelte (ou mesmo um sistema leve de componentes) enquanto jQuery ainda manipula diretamente os mesmos nós do DOM, pode ocorrer uma “guerra de puxões da UI”: o framework re‑renderiza e sobrescreve mudanças do jQuery, enquanto o jQuery atualiza elementos que o framework acha que controla.
Regra prática: defina um limite claro. Ou:
Muito código antigo depende de eventos delegados como:
$(document).on('click', '.btn', handler)
O DOM nativo pode fazer isso, mas o matching e as expectativas sobre this/event.target mudam. Bugs comuns incluem handlers disparando para o elemento errado (por causa de ícones/spans aninhados) ou não disparando para itens adicionados dinamicamente porque o listener foi anexado ao ancestral errado. Ao substituir eventos delegados, confirme:
closest() costuma ser necessário)Efeitos do jQuery UI e animações customizadas às vezes escondiam problemas de acessibilidade por acidente — ou os introduziam. Ao substituir fades, slides e toggles, verifique:
aria-expanded em botões de disclosure)prefers-reduced-motion)Detectar essas armadilhas cedo torna sua migração mais rápida e sua UI mais confiável — mesmo antes do último $() desaparecer.
jQuery não é “ruim.” Ele resolveu problemas reais — especialmente quando navegadores se comportavam de forma diferente e construir páginas interativas significava escrever muito código repetitivo. O que mudou é que geralmente você não precisa dele mais para projetos novos.
Algumas forças o empurraram de “escolha padrão” para “dependência legada”:
Se você mantém um site antigo, jQuery ainda pode ser uma ferramenta perfeitamente razoável — especialmente para correções pequenas, plugins estáveis ou páginas que não justificam uma reconstrução completa. Se você está construindo novas funcionalidades, prefira JavaScript nativo e mantenha jQuery só onde ele realmente economiza tempo.
Para seguir aprendendo de modo aplicável:
Se você estiver avaliando como modernizar mais rápido, considere ferramentas que ajudam a prototipar e entregar incrementalmente. Koder.ai pode ser útil: descreva o comportamento desejado em chat, gere uma UI baseada em React e um backend Go/PostgreSQL quando necessário, e exporte o código-fonte quando estiver pronto para integrar com a base existente.
Se estiver avaliando ferramentas ou opções de suporte, você também pode rever opções aqui: /pricing
jQuery é uma biblioteca JavaScript que simplifica tarefas comuns no navegador, como selecionar elementos, lidar com eventos, fazer requisições Ajax e aplicar efeitos básicos (mostrar/ocultar, fade, slide). Seu padrão característico é usar a função $() para encontrar elementos e encadear ações sobre eles.
$ é apenas uma função atalho (normalmente fornecida pelo jQuery) que encontra elementos na página — similar a document.querySelectorAll() — e retorna um objeto jQuery no qual você pode encadear métodos.
Se você vê $() em código antigo, geralmente significa “selecionar algo e então fazer algo com isso”.
Ele ficou popular porque tornou um comportamento inconsistente entre navegadores algo previsível. No início, tarefas simples como eventos, travessia do DOM e Ajax frequentemente exigiam soluções específicas por navegador.
jQuery oferecia uma API única e previsível para que equipes pudessem entregar mais rápido com menos surpresas entre navegadores.
Principalmente porque os navegadores e o JavaScript evoluíram. Hoje você costuma substituir tarefas clássicas do jQuery por recursos nativos:
querySelector / querySelectorAll para seleçãoNão. Muitos sites existentes ainda o usam e ele continua funcionando. “Legado” normalmente significa que é mais comum em codebases antigas do que em projetos novos.
A questão prática é se vale a pena mantê-lo considerando desempenho, manutenção e dependências atuais (especialmente plugins).
Porque ele ficou integrado em muitos ecossistemas antigos — especialmente temas e plugins. Um exemplo comum é o WordPress, onde muitas extensões assumiam que o jQuery estava presente.
Se seu site depende de um plugin que só funciona com jQuery (sliders, date pickers, lightboxes, validadores), remover o jQuery muitas vezes significa substituir esse plugin, não apenas reescrever algumas linhas.
Sim, em algumas situações práticas:
Nesses casos, estabilidade e tempo de entrega podem prevalecer sobre reduzir dependências.
Comece incrementalmente e meça o impacto:
Delegação de eventos é um clássico. Código jQuery como $(document).on('click', '.btn', handler) costuma depender do comportamento do jQuery em matching e no this.
No DOM nativo normalmente você precisa:
event.target.closest('.btn') para identificar o elemento pretendidoSim — efeitos e reescritas do DOM podem quebrar a acessibilidade. Ao substituir hide()/show() ou animações, verifique:
aria-expandedprefers-reduced-motion)Manter o comportamento idêntico não é só visual; é também fluxo de interação e navegação por teclado.
classListaddEventListener para eventosfetch + async/await para requisiçõesPortanto, em projetos novos, muitas vezes não é necessário uma camada de compatibilidade adicional só para o básico.
$.ajax() para fetch() endpoint a endpoint.PRs pequenos e rollouts graduais reduzem o risco de regressões.
Teste casos com conteúdo dinâmico (elementos adicionados depois do carregamento).