07 set 2025·8 min
Cos'è jQuery e perché si dice che sia dimenticato?
jQuery ha semplificato JavaScript con selezione DOM, eventi e AJAX facili. Scopri cos'è, perché è declinato e quando ha ancora senso oggi.
jQuery ha semplificato JavaScript con selezione DOM, eventi e AJAX facili. Scopri cos'è, perché è declinato e quando ha ancora senso oggi.
jQuery è una piccola libreria JavaScript che rende più semplici le attività comuni su una pagina web—cose come selezionare elementi, reagire ai clic, cambiare testo, mostrare/nascondere parti della pagina e inviare richieste a un server.
Se hai mai visto codice come $("button").click(...), quello è jQuery. Il $ è solo un'abbreviazione per “trova qualcosa sulla pagina e fai qualcosa con esso.”
Questa guida è pratica e non tecnica: cos'è jQuery, perché è diventato popolare, perché i progetti più recenti non lo usano tanto e come gestirlo se il tuo sito lo usa ancora. È intenzionalmente più lunga per includere esempi chiari e consigli reali invece di opinioni veloci.
Quando si dice che jQuery è “dimenticato”, di solito non si intende che sia sparito. Si vuol dire:
Quindi la storia non è “jQuery è morto.” È più: jQuery è passato dall'essere lo strumento predefinito per il front-end a diventare una dipendenza legacy che potresti ereditare—e che occasionalmente si sceglie ancora apposta.
Prima di jQuery, il lavoro di front-end spesso significava scrivere gli stessi piccoli e fastidiosi pezzi di codice più e più volte—poi testarli in più browser e scoprire che si comportavano in modo diverso. Anche obiettivi semplici come “trova questo elemento”, “attacca un gestore di click” o “invia una richiesta” potevano trasformarsi in una montagna di casi speciali.
Gran parte del JavaScript iniziale riguardava meno il costruire funzionalità e più il lottare con l'ambiente. Si scriveva codice che funzionava in un browser, poi si aggiungeva un ramo extra per farlo funzionare in un altro. I team mantenevano le proprie “mini librerie” interne di funzioni helper solo per sopravvivere ai cambiamenti quotidiani dell'interfaccia.
Il risultato: sviluppo più lento, più bug e la costante paura che una piccola modifica rompesse un browser più vecchio su cui gli utenti contavano ancora.
I browser non erano d'accordo su dettagli importanti. Metodi di selezione del DOM, gestione degli eventi e persino come ottenere le dimensioni di un elemento potevano variare. Internet Explorer, in particolare, aveva API diverse per gli eventi e per le richieste XMLHTTP, quindi il codice “standard” non era sempre davvero portabile.
Questo contava perché i siti non venivano costruiti per un solo browser. Se il tuo form di checkout, il menu di navigazione o un dialogo modale falliva in un browser popolare, era un problema reale per il business.
jQuery diventò importante perché offriva un'API coerente e amichevole che livellava quelle differenze.
Resse le attività comuni molto più semplici:
Ancora più importante, lo stile “scrivi meno, fai di più” di jQuery aiutava i team a rilasciare più rapidamente con meno sorprese specifiche del browser—soprattutto in un'epoca in cui le API DOM moderne non erano così capaci o ampiamente supportate come ora.
La vera forza di jQuery non era introdurre idee completamente nuove—era rendere le attività comuni del browser coerenti e semplici attraverso i diversi browser. Se leggi codice front-end più vecchio, tipicamente vedrai jQuery usato per quattro lavori quotidiani.
$)La funzione $() permetteva di “prendere” elementi usando selettori in stile CSS e poi lavorare con essi come gruppo.
Invece di destreggiarsi con le stranezze dei browser e API verbose, potevi selezionare tutti gli elementi, trovare un figlio o salire al genitore con chiamate brevi e concatenabili.
jQuery rendeva semplice rispondere alle azioni dell'utente:
click per bottoni e linksubmit per i formready per eseguire codice quando la pagina era caricataHa anche smussato le differenze nel modo in cui i browser gestivano gli oggetti evento e il binding, cosa che contava molto quando il supporto browser era disomogeneo.
Prima che fetch() diventasse standard, $.ajax(), $.get() e $.post() di jQuery erano un modo semplice per richiedere dati a un server e aggiornare la pagina senza ricaricarla.
Questo abilitò pattern che ora sembrano normali—ricerche live, pulsanti “carica altro”, aggiornamenti parziali della pagina—usando un'API unica e familiare.
jQuery ha reso popolari tocchi UI rapidi come hide(), show(), fadeIn(), slideToggle() e animate(). Erano comodi per menu, notifiche e transizioni di base—soprattutto quando il supporto CSS era meno affidabile.
Messi insieme, questi comfort spiegano perché il codice legacy spesso inizia con $( e perché jQuery è rimasto lo strumento di default per così tanto tempo.
Gran parte della reputazione di jQuery deriva da quanto poco codice serviva per svolgere compiti UI comuni—soprattutto quando le differenze tra browser erano dolorose. Un confronto rapido aiuta a capire.
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
JavaScript moderno (vanilla)
// 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!';
});
A prima vista, la versione jQuery sembra “più pulita”: una catena seleziona l'elemento, attacca un handler e aggiorna il testo. Questa compattezza era un punto di forza importante.
Il JavaScript moderno è leggermente più verboso, ma anche più esplicito:
querySelector e addEventListener dicono esattamente cosa succede.textContent è una proprietà standard del DOM (nessun wrapper di libreria coinvolto).?.) e i controlli null rendono più chiaro cosa succede se gli elementi non esistono.Dipende dal contesto. Se stai mantenendo un codebase vecchio che già usa jQuery ovunque, lo snippet jQuery può essere più coerente e veloce da usare. Se scrivi codice nuovo, le API DOM moderne sono ampiamente supportate, riducono le dipendenze e si integrano meglio con gli strumenti e i framework odierni.
Per molto tempo, il vantaggio più grande di jQuery era la prevedibilità. Si poteva scrivere in un modo per selezionare elementi, attaccare eventi o fare una richiesta—e funzionava nella maggior parte dei casi.
Col passare degli anni, i browser si sono standardizzati e migliorati. Molte delle comodità “must-have” che jQuery offriva sono ora integrate in JavaScript stesso, quindi spesso non serve una libreria extra solo per le operazioni di base.
I metodi DOM moderni coprono i pattern jQuery più comuni:
document.querySelector() / document.querySelectorAll() sostituiscono $(...) per molte selezioni.element.classList.add() / .remove() / .toggle() coprono la manipolazione delle classi.element.addEventListener() ha rimpiazzato il wrapper degli eventi di jQuery per la maggior parte dei casi.Invece di ricordare helper specifici di jQuery, puoi fare affidamento su API standard che funzionano sui browser moderni.
Dove una volta $.ajax() era la soluzione, fetch() gestisce molte richieste quotidiane con meno cerimonie, specialmente se combinato con JSON:
const res = await fetch('/api/items');
const data = await res.json();
Serve comunque gestire errori e timeout esplicitamente, ma l'idea di base—fare richieste senza un plugin—è ora nativa.
jQuery ha introdotto molte persone al codice asincrono tramite callback e $.Deferred. Oggi, Promises e async/await rendono i flussi asincroni più leggibili, e i moduli ES chiariscono l'organizzazione del codice.
Questa combinazione—API DOM moderne + fetch + feature del linguaggio moderno—ha rimosso gran parte della ragione originaria per cui i team sceglievano jQuery di default.
jQuery è cresciuto nell'era dei “siti multipagina”: il server renderizzava HTML, il browser caricava la pagina e si aggiungeva comportamento—handler di click, animazioni, chiamate Ajax—sopra al markup esistente.
I framework moderni hanno ribaltato quel modello. Invece di arricchire le pagine, le app spesso generano la maggior parte dell'interfaccia nel browser e la tengono in sync con i dati.
React, Vue e Angular hanno reso popolare l'idea di costruire interfacce da componenti—pezzi piccoli e riutilizzabili che gestiscono il loro markup, comportamento e stato.
In questo scenario, il framework vuole essere la fonte di verità per ciò che è sullo schermo. Tiene traccia dello stato, renderizza di nuovo parti dell'interfaccia quando lo stato cambia e si aspetta che tu esprima i cambiamenti in modo dichiarativo (“quando X è vero mostra Y”).
jQuery, invece, incoraggia la manipolazione imperativa del DOM (“trova questo elemento, cambia il suo testo, nascondilo”). Questo può entrare in conflitto con il ciclo di rendering di un framework. Se cambi manualmente nodi del DOM che un componente “controlla”, il render successivo può sovrascrivere i tuoi cambiamenti—o puoi finire a debugare incoerenze.
Con la diffusione delle SPA, i team hanno adottato strumenti di build e bundler (Webpack, Rollup, Vite). Invece di includere qualche script tag, importi moduli, bundle solo ciò che usi e ottimizzi per le performance.
Questo ha reso le persone più sensibili alle dipendenze e alla dimensione dei bundle. Includere jQuery “per sicurezza” sembrava meno naturale quando ogni kilobyte e aggiornamento di terze parti diventava parte della pipeline.
Si può usare jQuery dentro un framework, ma spesso diventa un'isola a sé—più difficile da testare, da comprendere e più incline a rompere durante i refactor. Di conseguenza, molti team hanno scelto pattern nativi del framework anziché scripting DOM nello stile jQuery.
jQuery di per sé non è “enorme”, ma spesso arriva con bagagli. Molti progetti che si affidano a jQuery accumulano anche plugin (slider, date picker, modal, validatori), ognuno aggiungendo altro codice di terze parti da scaricare e parsare. Col tempo, una pagina può finire per spedire diverse utility sovrapposte—soprattutto quando le funzionalità sono state aggiunte in fretta e mai riviste.
Più JavaScript significa generalmente più lavoro per il browser per scaricare, parsare ed eseguire prima che la pagina sia usabile. Questo effetto è più evidente su dispositivi mobili, reti lente e hardware più vecchio. Anche se gli utenti alla fine avranno un'esperienza fluida, il “tempo per essere utilizzabile” può peggiorare quando la pagina aspetta script extra e relative dipendenze.
Un pattern comune nei siti di lunga vita è il codebase ibrido: alcune funzionalità scritte con jQuery, parti più nuove costruite con un framework (React, Vue, Angular) e qualche frammento di JavaScript puro. Questa mescolanza può diventare confusa:
Quando coesistono più stili, le piccole modifiche diventano più rischiose. Uno sviluppatore aggiorna un componente, ma uno script jQuery vecchio raggiunge lo stesso markup e lo modifica, causando bug difficili da riprodurre.
I team si allontanano gradualmente da jQuery non perché “smetta di funzionare”, ma perché i progetti moderni ottimizzano per bundle più piccoli e una proprietà più chiara del comportamento UI. Man mano che i siti crescono, ridurre il codice di terze parti e standardizzare un approccio facilita tuning delle performance, debugging e onboarding.
jQuery non è stato solo popolare—è diventato di default. Per anni è stato il modo più semplice per rendere le pagine interattive funzionare in modo affidabile attraverso i browser, quindi è finito integrato in innumerevoli template, snippet, tutorial e soluzioni copia-incolla.
Una volta successo ciò, jQuery è diventato difficile da evitare: anche se un sito usava solo una piccola funzionalità, spesso caricava tutta la libreria perché tutto il resto la assumeva presente.
Una grande ragione per cui jQuery compare ancora è semplice: il suo successo lo ha reso “ovunque” nel codice di terze parti. Widget UI più vecchi, slider, lightbox, validatori di form e script di tema erano comunemente scritti come plugin jQuery. Se un sito dipende da uno di quei componenti, rimuovere jQuery può significare riscrivere o sostituire quella dipendenza—non solo cambiare poche righe.
WordPress è una grande fonte di “jQuery legacy.” Molti temi e plugin—specialmente quelli creati anni fa—usano jQuery per il frontend e, storicamente, anche le schermate di amministrazione di WordPress spesso si sono basate su di esso. Anche quando le versioni più nuove si muovono verso JavaScript moderno, la lunga coda delle estensioni esistenti mantiene jQuery presente su molte installazioni.
I siti più vecchi spesso danno priorità al “non rompere ciò che funziona.” Tenere jQuery può essere l'opzione più sicura quando:
In breve, jQuery non è sempre “dimenticato”—spesso fa parte delle fondamenta su cui è stato costruito un sito, e le fondamenta non si sostituiscono a cuor leggero.
jQuery non è “cattivo” come software—è semplicemente meno necessario rispetto a prima. Ci sono ancora situazioni reali in cui mantenere (o aggiungere) un po' di jQuery è la scelta più pratica, specialmente quando si ottimizza per tempo, compatibilità o stabilità invece che per purezza architetturale.
Se hai requisiti che includono browser più vecchi (specialmente versioni datate di Internet Explorer), jQuery può ancora semplificare selezione DOM, gestione eventi e AJAX in modi che le API native non eguagliano senza polyfill aggiuntivi.
La domanda chiave è il costo: supportare browser legacy di solito significa comunque scrivere codice extra. In quel contesto, jQuery può essere una parte accettabile del pacchetto di compatibilità.
Se un sito è già costruito attorno a jQuery, piccole correzioni UI sono spesso più veloci e sicure se fatte nello stesso stile del resto del codice. Mischiare approcci crea confusione (due pattern per gli eventi, due modi per manipolare il DOM) e complica la manutenzione.
Una regola ragionevole: se tocchi una o due schermate e l'app è altrimenti stabile, intervenire con jQuery va bene—evita solo di espandere l'uso di jQuery in nuovi “sistemi” che poi dovrai disfare.
Per un sito marketing semplice o uno strumento interno—niente bundler, niente transpiler, niente framework a componenti—jQuery può ancora essere un comodo helper con “un unico script”. È particolarmente utile quando vuoi poche interazioni (menu toggle, comportamenti di form semplici) e non vuoi introdurre una pipeline di build.
Molti plugin maturi (date picker, tabelle, lightbox) erano costruiti su jQuery. Se un plugin più vecchio è critico per il business e stabile, mantenere jQuery come dipendenza può essere l'opzione a minor rischio.
Prima di impegnarti, verifica se esiste un'alternativa mantenuta non basata su jQuery—o se aggiornare il plugin forzerebbe una riscrittura più ampia di quella che il progetto può permettersi ora.
Allontanarsi da jQuery riguarda meno una grande riscrittura e più la riduzione graduale della dipendenza senza rompere il comportamento su cui la gente conta. L'approccio più sicuro è incrementale: mantieni le pagine funzionanti mentre sostituisci i pezzi sotto il cofano.
Inizia rispondendo a tre domande pratiche:
Quest'audit ti aiuta a evitare di sostituire cose che non servono e individua dipendenze “nascoste” come un plugin che usa silenziosamente $.ajax().
La maggior parte dei team ottiene vittorie rapide scambiando i pattern più semplici e comuni:
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)Fai tutto in PR piccole per facilitare la revisione e il rollback.
Se usi $.ajax(), migra quelle chiamate a fetch() (o a un piccolo helper HTTP) un endpoint alla volta. Mantieni le shape delle risposte uguali in modo che il resto dell'interfaccia non debba cambiare subito.
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r => r.json())
.then(renderItems);
Prima di rimuovere jQuery, aggiungi copertura dove conta: flussi utente chiave, invio dei form e qualsiasi UI dinamica. Anche controlli leggeri (smoke test con Cypress o una checklist QA) possono catturare regressioni presto. Rilascia le modifiche dietro feature flag quando possibile e conferma che analytics/tassi di errore rimangono stabili.
Se vuoi sicurezza extra durante i refactor, aiuta usare tooling che supporti snapshot e rollback. Per esempio, team che modernizzano front end legacy a volte prototipano sostituzioni in Koder.ai e usano il workflow snapshot/rollback per iterare senza perdere una versione “nota come buona”.
Se ti serve aiuto per organizzare il piano generale, vedi /blog/jquery-vs-vanilla-js per un confronto di base da usare durante i refactor.
Migrare via da jQuery riguarda più il districare anni di assunzioni che il semplice “sostituire sintassi”. Ecco le trappole che rallentano i team—e come evitarle.
Una riscrittura totale suona pulita, ma spesso crea un branch a vita lunga, molte regressioni e pressione per rilasciare lavoro incompleto. Un approccio più sicuro è incrementale: sostituisci una feature o una pagina alla volta, mantieni il comportamento identico e aggiungi test alle parti che tocchi.
Se introduci React/Vue/Svelte (o anche un sistema di componenti leggero) mentre jQuery continua a manipolare gli stessi nodi del DOM, puoi avere una “tira e molla” dell'interfaccia: il framework renderizza di nuovo e sovrascrive i cambi jQuery, mentre jQuery aggiorna elementi che il framework pensa di controllare.
Regola pratica: definisci un confine chiaro. O:
Molto codice vecchio si basa su eventi delegati come:
$(document).on('click', '.btn', handler)
La DOM API nativa può farlo, ma il matching e le aspettative su this/event.target possono cambiare. Bug comuni includono handler che scattano per l'elemento sbagliato (a causa di icone/span annidati) o che non scattano per elementi aggiunti dinamicamente perché il listener è attaccato all'antenato sbagliato. Quando sostituisci eventi delegati, conferma:
closest() è spesso necessario)Gli effetti di jQuery UI e le animazioni custom talvolta nascondevano problemi di accessibilità per caso—o li introducevano. Quando sostituisci fade, slide e toggle, ricontrolla:
aria-expanded sui bottoni di disclosure)prefers-reduced-motion)Individuare queste insidie presto rende la migrazione più rapida e la UI più affidabile—anche prima che l'ultimo $() sparisca.
jQuery non è “cattivo.” Ha risolto problemi reali—specialmente quando i browser si comportavano in modo diverso e costruire pagine interattive significava scrivere molto codice ripetitivo. Ciò che è cambiato è che oggi di solito non serve più per i progetti nuovi.
Alcune forze l'hanno portato da “scelta predefinita” a “dipendenza legacy”:
Se mantieni un sito più vecchio, jQuery può ancora essere uno strumento perfettamente ragionevole—soprattutto per piccole correzioni, plugin stabili o pagine che non giustificano una riscrittura completa. Se costruisci nuove funzionalità, punta prima al JavaScript nativo e conserva jQuery solo dove risparmia chiaramente tempo.
Per continuare a imparare in modo pratico, prosegui con:
Se stai valutando come modernizzare più velocemente, considera strumenti che aiutano a prototipare e rilasciare in modo incrementale. Koder.ai può essere utile: descrivi il comportamento desiderato in chat, genera un UI basato su React e, se serve, un backend Go/PostgreSQL, ed esporta il codice sorgente quando sei pronto per integrarlo nel tuo codebase.
Se stai valutando tool o opzioni di supporto, puoi anche rivedere le alternative qui: /pricing
jQuery è una libreria JavaScript che semplifica attività comuni nel browser come selezionare elementi, gestire eventi, fare richieste Ajax e applicare effetti base (show/hide, fade, slide). Il suo pattern caratteristico usa la funzione $() per trovare elementi e concatenare azioni su di essi.
$ è semplicemente una funzione scorciatoia (di solito fornita da jQuery) che trova elementi nella pagina—simile a document.querySelectorAll()—e restituisce un oggetto jQuery su cui puoi concatenare metodi.
Se vedi $() in codice più vecchio, spesso significa “seleziona qualcosa, poi fai qualcosa con esso.”
È diventato popolare perché rendeva il comportamento incoerente dei browser più prevedibile. Nei primi anni, operazioni semplici come eventi, traversamento del DOM e Ajax richiedevano spesso workaround specifici per browser.
jQuery forniva una singola API prevedibile così i team potevano consegnare più velocemente con meno sorprese cross-browser.
Perché i browser e JavaScript moderno hanno colmato il divario. Oggi puoi spesso sostituire le attività classiche di jQuery con funzionalità native:
querySelector / querySelectorAll per la selezioneNo. Molti siti esistenti lo usano ancora e continua a funzionare. “Legacy” di solito significa che è più comune nei codebase più datati che in quelli nuovi.
La domanda pratica è se valga la pena mantenerlo in base a performance, manutenzione e dipendenze correnti (soprattutto plugin).
Perché è radicato in ecosistemi più vecchi—specialmente temi e plugin. Un esempio comune è WordPress, dove molte estensioni storicamente assumevano la presenza di jQuery.
Se il tuo sito dipende da un plugin jQuery-only (slider, date picker, lightbox, validator), rimuovere jQuery spesso significa sostituire quel plugin, non solo riscrivere poche righe.
Sì, in alcune situazioni pratiche:
In questi casi stabilità e velocità possono valere più della riduzione delle dipendenze.
Inizia in modo incrementale e misura l'impatto:
La delega degli eventi è un caso comune. Codice jQuery come:
$(document).on('click', '.btn', handler)
La DOM API nativa può fare lo stesso, ma l'aspettativa su this/event.target e il matching può cambiare. Quando sostituisci eventi delegati, verifica:
Sì—effetti e riscritture del DOM possono inavvertitamente rompere l'accessibilità. Quando sostituisci hide()/show() o effetti di slide/fade, ricontrolla:
aria-expandedprefers-reduced-motion)Mantenere il comportamento identico non è solo visivo; riguarda interazione e flusso da tastiera.
classListaddEventListener per gli eventifetch + async/await per le richiesteQuindi nei progetti nuovi non serve quasi più uno strato di compatibilità per le basi.
$.ajax()fetch()PR piccoli e rollout staged riducono il rischio di regressioni.
closest())Testa i casi di contenuto dinamico (elementi aggiunti dopo il caricamento).