O que é jQuery e por que as pessoas dizem que ele foi esquecido?

jQuery em um minuto

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.”

O que este artigo vai cobrir

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.

O que as pessoas querem dizer com “esquecido”

Quando as pessoas dizem que jQuery está “esquecido”, geralmente não querem dizer que desapareceu. Querem dizer:

• É usado com menos frequência em projetos novos, porque navegadores modernos agora suportam muitos recursos que o jQuery costumava oferecer.
• Ainda é comum em sites antigos (e em alguns plugins, temas e painéis administrativos) porque funciona, é familiar e substituí‑lo leva tempo.

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.

Por que jQuery foi tão importante

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.

Como era o desenvolvimento front‑end antes do jQuery

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.

Diferenças entre navegadores e por que importavam

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.

A lacuna que o jQuery preencheu para tarefas do dia a dia

jQuery se tornou relevante porque oferecia uma API consistente e amigável que amenizava essas diferenças.

Tornou tarefas comuns dramaticamente mais simples:

• Selecionar e manipular elementos do DOM com seletores no estilo CSS
• Lidar com eventos de forma cross‑browser
• Animações e efeitos sem implementar timers manualmente
• Requisições Ajax com uma interface única e previsível

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.

Coisas centrais que o jQuery ajuda a fazer

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.

1) Seleção e travessia do DOM (a ideia da função $)

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.

2) Eventos: padrões click/submit/ready

jQuery facilitou responder a ações do usuário:

• click para botões e links
• submit para formulários
• ready para rodar código quando a página carregava

També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.

3) Noções básicas de AJAX (carregar dados sem recarregar)

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.

4) Efeitos/animações e helpers simples de UI

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.

Um exemplo simples: jQuery vs JavaScript moderno

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.

Selecionar um elemento e lidar com um clique

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!';
});

Legibilidade: menos linhas vs APIs mais explícitas

À 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).
• Encadeamento opcional (?.) e checagens nulas deixam claro o que acontece se elementos não existirem.

Qual é “melhor”?

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.

O JavaScript nativo alcançou o jQuery

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.

APIs do DOM ficaram mais simples e consistentes

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.

Requisições de rede migraram para fetch

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.

Melhor estrutura com Promises, async/await e módulos

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.

Frameworks mudaram a forma de construir UIs

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.

Apps de página única e UI baseada em componentes

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.

Ferramentas de build e bundlers mudaram a forma como o código é enviado

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.

Por que jQuery pode parecer estranho em apps baseados em componentes

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.

Tamanho do bundle e pressão de manutenção

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.

Downloads maiores, mais trabalho para o navegador

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.

O custo oculto: estilos mistos e sobrecarga mental

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:

• Duas maneiras de selecionar elementos e atualizar o DOM
• Modelos de evento e suposições de ciclo de vida diferentes
• Soluções concorrentes para estado (DOM como estado vs estado do componente)

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.

A pressão de manutenção aumenta

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.

Por que você ainda vê jQuery em sites antigos

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á.

Está integrado em plugins e temas antigos

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 herdou e manteve isso

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.

Sistemas legados priorizam estabilidade em vez de mudança

Sites mais antigos frequentemente priorizam “não quebrar o que funciona”. Manter jQuery pode ser a opção mais segura quando:

• o site é estável e crítico para receita
• o tempo é limitado e testes de regressão são caros
• a base de código tem anos de pequenos consertos que ninguém quer reauditar

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.

Quando jQuery ainda faz sentido

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.

Você precisa suportar navegadores legados

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.

Você precisa de correções rápidas em uma base de código jQuery existente

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.

Sites pequenos sem etapa de build

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.

Uso de plugins antigos que dependem dele

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.

Como se afastar do jQuery com segurança

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.

1) Faça uma auditoria do que você realmente usa

Comece respondendo três perguntas práticas:

• Quais páginas carregam jQuery?
• Quais plugins dependem dele (sliders, date pickers, validação, etc.)?
• Quais recursos do jQuery aparecem na sua base de código (seleção do DOM, eventos, AJAX, animações)?

Essa auditoria evita substituir coisas desnecessárias e identifica dependências “ocultas” como um plugin que usa $.ajax() silenciosamente.

2) Substitua o que for mais fácil primeiro

A maioria das equipes consegue ganhos rápidos trocando padrões simples:

• Seletores: $(".card") → document.querySelectorAll(".card")
• Classes: .addClass() / .removeClass() → classList.add() / classList.remove()
• Eventos: .on("click", ...) → addEventListener("click", ...)

Faça isso em PRs pequenos para que seja fácil revisar e reverter.

3) Planeje a transição do AJAX

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);

4) Reduza risco com testes e rollouts graduais

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.

Armadilhas comuns na migração

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.

Tentar reescrever tudo de uma vez

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.

Misturar jQuery com um framework de componentes na mesma área da UI

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:

• Mantenha jQuery em um container legado e monte o framework em outro lugar, ou
• Migre esse widget inteiro como uma unidade antes de adicionar novos comportamentos.

Diferenças em delegação de eventos

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:

• Qual elemento deve ser considerado o “botão clicado” (closest() costuma ser necessário)
• Se eventos eram namespaced anteriormente (jQuery suporta isso; nativo precisa de outra estratégia)

Regressões de acessibilidade ao substituir efeitos

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:

• Gerenciamento de foco (para onde vai o foco do teclado após abrir/fechar)
• Estados ARIA (por exemplo, aria-expanded em botões de disclosure)
• Preferência por movimento reduzido (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.

Principais conclusões e próximos passos

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.

Por que o jQuery declinou

Algumas forças o empurraram de “escolha padrão” para “dependência legada”:

• APIs DOM modernas melhoraram: selecionar elementos, mudar classes e lidar com eventos ficaram simples no JavaScript nativo.
• Consistência entre navegadores aumentou: menos quirks significam menos valor em uma camada de compatibilidade.
• Frameworks mudaram expectativas: React/Vue/Angular incentivam UIs baseadas em componentes e renderização guiada por estado, onde manipulação direta do DOM (força do jQuery) é menos central.
• Pressão por performance e manutenção: equipes passaram a se importar mais com tamanho de bundle, atualizações de dependências e reduzir “código misterioso” em apps grandes.

Próximos passos práticos

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:

• Fundamentos do DOM e padrões comuns: /blog/vanilla-js-dom-basics
• Substituir padrões AJAX antigos por requisições modernas: /blog/fetch-api-beginners

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