jQuery è una libreria JavaScript open source nata per rendere più semplici operazioni come la selezione e modifica degli elementi HTML, la gestione degli eventi, le richieste AJAX e alcuni effetti visivi. Non è un linguaggio di programmazione e non sostituisce JavaScript: funziona attraverso JavaScript e ne fornisce un’API più compatta per svolgere determinate operazioni.
Per molti anni è stata quasi uno standard nello sviluppo front-end, soprattutto perché permetteva di gestire con un’unica sintassi le differenze fra browser che rendevano il JavaScript dell’epoca più difficile da mantenere.
Oggi il contesto è cambiato. Le API native dei browser coprono direttamente molte funzioni per cui in passato si ricorreva automaticamente alla libreria. Il progetto, però, non è scomparso né abbandonato: continua a essere mantenuto e la release stabile corrente è jQuery 4.0.0. Il punto, quindi, non è stabilire se jQuery sia “morta”, ma capire quando ha ancora senso utilizzarla e quando JavaScript nativo è una scelta più semplice.
Se non conosci ancora le basi del linguaggio, conviene partire dalla nostra guida su JavaScript. Anche la documentazione ufficiale raccomanda di avere una conoscenza funzionante di JavaScript prima di imparare la libreria.
Cos’è jQuery e perché è stata creata
jQuery è una libreria JavaScript, cioè un insieme di funzioni e metodi già pronti che possono essere utilizzati all’interno del proprio codice.
Invece di costruire ogni operazione partendo dalle API native del browser, lo sviluppatore può usare l’interfaccia fornita dalla libreria.
Un esempio molto semplice chiarisce il concetto.
Puoi selezionare un elemento HTML e modificarne il testo in questo modo:
$("#messaggio").text("Operazione completata");
Il simbolo $ è normalmente un alias della funzione jQuery(). In questo caso:
$("#messaggio")seleziona l’elemento con IDmessaggio;- viene restituito un oggetto che rappresenta l’elemento selezionato;
.text()modifica il contenuto testuale.
Non significa che JavaScript non sia in grado di fare la stessa cosa. Con le API native moderne puoi scrivere, ad esempio:
document.querySelector("#messaggio").textContent = "Operazione completata";
La differenza è quindi nel livello di astrazione e nell’API utilizzata, non nella possibilità di eseguire l’operazione.
jQuery è una libreria JavaScript, non un framework
Viene ancora definita talvolta un “framework JavaScript”, ma è più corretto considerarla una libreria.
Un framework normalmente impone o suggerisce una struttura più ampia all’applicazione: componenti, stato, routing, rendering, lifecycle o altre convenzioni architetturali.
Qui l’obiettivo è molto più circoscritto. La libreria permette di interrogare e modificare il DOM, gestire eventi, effettuare richieste di rete e utilizzare una serie di utility, senza definire l’architettura generale dell’applicazione.
Questo è anche il motivo per cui confrontarla direttamente con React, Vue o Angular può essere fuorviante: affrontano problemi in parte differenti.
Il problema che jQuery risolveva nel web
Per capire perché ebbe tanto successo bisogna tornare al problema originale.
Quando la libreria fu presentata da John Resig nel 2006, i browser potevano comportarsi in modo molto diverso nell’esecuzione di JavaScript. Operazioni apparentemente banali richiedevano controlli, workaround e codice specifico per browser differenti.
La soluzione introdusse un livello comune sopra queste differenze.
Lo sviluppatore poteva scrivere qualcosa come:
$(".menu").hide();
e lasciare alla libreria buona parte della gestione delle differenze sottostanti.
Questo approccio rese più accessibili anche selezione degli elementi, eventi, animazioni e richieste asincrone. La celebre filosofia “write less, do more” descriveva bene il vantaggio: non nuove capacità impossibili da ottenere in JavaScript, ma un modo più uniforme e compatto per utilizzarle.
Il contesto dei browser moderni è molto diverso. Molte API sono ormai standardizzate e disponibili direttamente, quindi una parte dell’astrazione che rese indispensabile jQuery è meno necessaria.
A cosa serve jQuery
Le funzionalità fondamentali della libreria possono essere ricondotte a pochi gruppi: selezione e manipolazione del DOM, eventi, richieste AJAX, gestione di classi e attributi, effetti e alcune utility.
Selezionare e modificare gli elementi del DOM
Il DOM, Document Object Model, è la rappresentazione strutturata del documento HTML che JavaScript può interrogare e modificare.
Se vuoi approfondire il rapporto fra struttura della pagina e JavaScript, trovi una spiegazione più completa nella guida a HTML.
La funzione $() è uno dei punti centrali:
$(".prodotto")
seleziona gli elementi con classe prodotto.
Puoi poi concatenare un metodo:
$(".prodotto").addClass("in-evidenza");
oppure modificare attributi:
$("#logo").attr("alt", "Logo aziendale");
o contenuti:
$("#titolo").text("Nuovo titolo");
Una caratteristica utile è il method chaining, cioè la possibilità di concatenare più operazioni sullo stesso insieme di elementi:
$(".notifica")
.addClass("attiva")
.text("Hai un nuovo messaggio")
.show();
Questa sintassi è una delle ragioni per cui la libreria può ancora risultare comoda quando si lavora su codice esistente che ne fa un uso intenso.
Gestire eventi e interazioni
La libreria semplifica anche la registrazione degli eventi.
Per esempio:
$(".js-toggle").on("click", function () {
$("#messaggio").toggleClass("is-visible");
});
Quando l’utente fa clic sull’elemento con classe js-toggle, viene aggiunta o rimossa la classe is-visible.
Il metodo .on() è preferibile ai vecchi shorthand che si incontrano ancora in numerosi tutorial, come:
$("button").click(function () {
// ...
});
Questa sintassi storica può ancora comparire nel vecchio codice, ma per nuove implementazioni .on() rende più esplicita e flessibile la gestione degli eventi.
Con JavaScript nativo, lo stesso tipo di operazione può essere eseguito con addEventListener():
document.querySelector(".js-toggle").addEventListener("click", () => {
document.querySelector("#messaggio").classList.toggle("is-visible");
});
È un esempio concreto di come le API native abbiano ridotto la distanza che esisteva un tempo fra JavaScript puro e jQuery.
Richieste AJAX
Un altro elemento importante nella storia della libreria è AJAX.
La sua API ha reso molto più semplice effettuare richieste HTTP asincrone attraverso metodi come $.ajax(), $.get(), $.post() e $.getJSON().
Per esempio:
$.getJSON("/api/prodotti", function (dati) {
console.log(dati);
});
La pagina può ricevere dati dal server senza dover eseguire un normale caricamento completo.
Se vuoi capire meglio il meccanismo, abbiamo una guida dedicata a cos’è AJAX e come funziona.
Anche in questo caso il web moderno offre un’alternativa nativa molto diffusa:
const risposta = await fetch("/api/prodotti");
const dati = await risposta.json();
console.log(dati);
Questo non rende inutili le API AJAX della libreria nei progetti che già ne dipendono. Significa semplicemente che aggiungere una dipendenza esclusivamente per effettuare richieste HTTP è molto meno necessario rispetto al passato.
Effetti e animazioni
Sono disponibili metodi come:
$("#box").hide();
$("#box").show();
$("#box").fadeIn();
$("#box").slideToggle();
e il metodo .animate() per animazioni basate su proprietà numeriche.
Queste funzioni hanno avuto un ruolo importante quando le possibilità offerte dai CSS erano molto più limitate.
Oggi animazioni e transizioni puramente visuali vengono normalmente gestite meglio attraverso CSS, mentre JavaScript può essere utilizzato per applicare o rimuovere classi in base allo stato dell’interfaccia.
Per questo non utilizzerei jQuery come prima scelta solo per creare un fade, una transizione o un menu animato in un progetto nuovo.
Come installare e usare jQuery
Puoi utilizzare la libreria in diversi modi: scaricando il file nel progetto, caricandolo da una CDN oppure installandolo tramite un package manager come npm.
La documentazione ufficiale mantiene una pagina con la release stabile e le modalità di download.
Caricare jQuery come file locale
Puoi scaricare la versione compressa e inserirla nel progetto:
<script src="/js/jquery-4.0.0.min.js"></script> <script src="/js/app.js"></script>
L’ordine è importante: se app.js contiene codice che utilizza $ o jQuery, la libreria deve essere disponibile prima che quel codice venga eseguito.
Per una pagina semplice, il file JavaScript può essere caricato in fondo al body oppure si può progettare correttamente la strategia di caricamento degli script.
Utilizzare una CDN
È possibile caricare la libreria anche da una CDN.
Una Content Delivery Network distribuisce file attraverso un’infrastruttura di server, evitando di ospitare direttamente la risorsa sul proprio server.
Questo però non significa che una CDN renda automaticamente più veloce ogni sito. Il risultato dipende da caching, protocollo, origine del file, infrastruttura, numero di richieste e configurazione della pagina.
Il sito ufficiale mette a disposizione un proprio CDN e fornisce anche tag completi con Subresource Integrity (SRI), che permette al browser di verificare che il file ricevuto corrisponda a quello previsto.
Se utilizzi un CDN esterno in produzione, evita quindi di copiare casualmente uno script da un tutorial vecchio: prendi il tag della release desiderata dalla fonte ufficiale.
Installare jQuery con npm
Nei progetti che utilizzano un sistema di build puoi installare la libreria con:
npm install jquery
e poi importarla nel codice:
import $ from "jquery";
È generalmente un approccio più coerente quando il progetto gestisce le dipendenze attraverso npm anziché attraverso script aggiunti manualmente alla pagina.
Un primo esempio completo
Supponiamo di avere questo HTML:
<button class="js-toggle">Mostra o nascondi</button>
<p id="messaggio" class="messaggio">
Questo contenuto può essere mostrato o nascosto.
</p>
Il codice può essere:
$(function () {
$(".js-toggle").on("click", function () {
$("#messaggio").toggleClass("is-visible");
});
});
$(function () { ... }) esegue la funzione quando il DOM è pronto.
La forma storica:
$(document).ready(function () {
// ...
});
esprime lo stesso concetto, ma la sintassi abbreviata è normalmente sufficiente.
In molti progetti moderni il caricamento degli script viene già organizzato in modo da eseguirli quando il DOM è disponibile. Non è quindi necessario trasformare ready() in un rituale da inserire automaticamente in qualsiasi file JavaScript.
jQuery 4: cosa cambia rispetto alle versioni precedenti
La serie 4 rappresenta un aggiornamento importante perché elimina una parte del codice e delle API mantenute per ragioni di compatibilità storica.
Al momento dell’ultimo aggiornamento di questa guida, jQuery 4.0.0 è la release stabile indicata dal progetto ufficiale. È la prima major release dopo la serie 3.x e contiene modifiche che possono rompere codice scritto per versioni precedenti.
Le release notes ufficiali di jQuery 4.0.0 sono quindi particolarmente importanti se devi aggiornare un sito o un’applicazione esistente.
API legacy rimosse e supporto browser aggiornato
La major release elimina API deprecate che disponevano ormai di equivalenti JavaScript nativi.
Tra gli esempi:
jQuery.isArray() jQuery.parseJSON() jQuery.trim() jQuery.now()
Per questi casi possono essere utilizzate rispettivamente API native come:
Array.isArray() JSON.parse() String.prototype.trim() Date.now()
Il significato del cambiamento è più importante della singola funzione: lo stesso progetto sta eliminando parte delle astrazioni che non servono più nei browser moderni.
Anche la compatibilità è stata aggiornata. La versione 4 elimina il supporto per Internet Explorer 10 e precedenti e per varie generazioni di browser ormai legacy. IE 11 rimane supportato nella linea 4.x secondo l’attuale policy ufficiale.
Se mantieni un progetto vincolato a browser molto vecchi, quindi, non puoi semplicemente sostituire una vecchia release con quella nuova senza verificare i requisiti.
Trusted Types, CSP e modernizzazione del progetto
La nuova major release non consiste soltanto nella rimozione di vecchio codice.
Introduce supporto per Trusted Types in operazioni di manipolazione HTML e modifica alcuni meccanismi di caricamento degli script per lavorare meglio con configurazioni Content Security Policy.
Anche il codice sorgente del progetto è stato migrato verso gli ES modules, rendendo la base di sviluppo più coerente con i moderni strumenti JavaScript.
Non significa che devi utilizzare ES modules per aggiungere la libreria a una normale pagina HTML. È soprattutto un segnale della direzione del progetto: il core viene modernizzato senza trasformarsi in un framework front-end differente.
Aggiornare da jQuery 3 a jQuery 4 con jQuery Migrate
Se devi aggiornare un progetto esistente, non sostituire la versione in produzione e aspettare che gli errori compaiano.
Il progetto mette a disposizione jQuery Migrate proprio per individuare API e comportamenti incompatibili.
La guida ufficiale all’upgrade a jQuery 4 raccomanda l’utilizzo di Migrate durante il processo.
Un flusso prudente è:
- verificare la versione effettivamente utilizzata;
- aggiornare prima plugin, temi o componenti che dipendono dalla libreria;
- effettuare l’upgrade in ambiente di sviluppo o staging;
- caricare la versione non compressa di jQuery Migrate durante i test;
- controllare e correggere gli avvisi nella console;
- testare le interazioni principali del sito;
- rimuovere Migrate quando il vecchio comportamento non è più necessario.
Se il progetto utilizza una versione molto precedente alla serie 3.x, il percorso può richiedere migrazioni intermedie, non un salto diretto.
Questo è particolarmente importante nei siti che hanno accumulato negli anni plugin e script di terze parti.
jQuery o JavaScript moderno: quale conviene usare?
La domanda più utile oggi non è “quale dei due è migliore?”, ma quale dipendenza serve realmente al progetto.
La libreria e JavaScript nativo possono risolvere molti degli stessi problemi, ma partono da condizioni differenti.
| Criterio | jQuery | JavaScript nativo moderno |
|---|---|---|
| Selezione DOM | API $() compatta e coerente | querySelector() e querySelectorAll() sono native e ampiamente disponibili |
| Eventi | .on() e sistema eventi dedicato | addEventListener() copre direttamente i casi comuni |
| Classi CSS | .addClass(), .removeClass(), .toggleClass() | classList offre API native equivalenti |
| Richieste HTTP | $.ajax(), $.get(), $.post() | fetch() è normalmente sufficiente per nuove implementazioni |
| Animazioni | effetti incorporati come fade e slide | CSS transitions/animations sono spesso preferibili per effetti visuali |
| Dipendenza | richiede il caricamento della libreria | nessuna libreria aggiuntiva |
| Progetti esistenti | molto utile se il codice è già costruito su jQuery | una riscrittura completa può non avere alcun vantaggio reale |
| Browser legacy | continua ad astrarre varie differenze | dipende dalle API utilizzate e dal supporto richiesto |
| Apprendimento | richiede comunque comprensione di JavaScript | insegna direttamente le API della piattaforma web |
La tabella non dice che il codice nativo sia sempre più corto o che la libreria sia sempre più semplice. Dipende dall’operazione e dal progetto.
La differenza più importante è un’altra: JavaScript è già presente nel browser; jQuery è una dipendenza che devi decidere di aggiungere.
Quando jQuery ha ancora senso
Può essere una scelta perfettamente ragionevole quando:
- stai mantenendo un sito o un’applicazione che la utilizza già;
- plugin o componenti fondamentali dipendono dalla libreria;
- il team conosce bene il codice esistente e una riscrittura non produrrebbe un beneficio proporzionato;
- devi correggere o estendere funzionalità legacy;
- lavori in un ecosistema in cui è già caricata e utilizzata.
In questi scenari rimuoverla soltanto perché “vecchia” può produrre più complessità che valore.
Una dipendenza esistente va giudicata in base a costo di manutenzione, compatibilità, sicurezza, prestazioni reali e valore della migrazione, non alla sua età.
Quando JavaScript nativo è una scelta migliore
Per un progetto nuovo, semplice e rivolto ai browser moderni partirei invece dal JavaScript nativo.
Se devi soltanto:
- selezionare elementi;
- modificare classi;
- ascoltare eventi;
- fare richieste HTTP;
- aggiornare contenuti;
- controllare animazioni CSS;
le API native coprono già molto bene questi casi.
Aggiungere jQuery avrebbe senso solo se emerge una necessità concreta che giustifica la dipendenza.
Questa distinzione è importante anche per chi sta imparando: conoscere prima JavaScript rende molto più semplice capire cosa sta facendo la libreria dietro la propria API, diagnosticare gli errori e lavorare anche in progetti che non la utilizzano.
jQuery, React, Vue e altri framework non sono la stessa cosa
React, Vue, Angular e jQuery vengono spesso messi nella stessa lista perché appartengono all’ecosistema JavaScript, ma non sono alternative perfettamente sovrapponibili.
Il modello classico della libreria è prevalentemente imperativo.
In pratica dici al browser cosa modificare:
$("#totale").text(nuovoTotale);
$(".carrello").addClass("aggiornato");
Se l’interfaccia cresce, sei tu a coordinare le modifiche al DOM e lo stato che le determina.
Le moderne librerie e i framework orientati ai componenti lavorano invece generalmente a un livello architetturale superiore: l’interfaccia viene descritta in funzione dello stato e il sistema coordina gli aggiornamenti necessari.
Non significa che sia sempre meglio costruire un piccolo sito con React o Vue. Sarebbe l’errore opposto.
Per un’interazione semplice può essere sufficiente JavaScript. Per un vecchio progetto può avere senso mantenere jQuery. Per un’applicazione complessa e fortemente state-driven può essere più adatto un sistema component-based.
La scelta dipende quindi dal problema architetturale, non dalla ricerca della tecnologia più nuova.
jQuery e WordPress
La libreria è ancora rilevante anche perché compare in molti siti WordPress, temi e plugin sviluppati nel corso degli anni.
WordPress registra una serie di librerie JavaScript nel proprio sistema di gestione delle dipendenze e la documentazione per sviluppatori continua a documentare l’handle jquery. Puoi verificarlo nella documentazione di wp_enqueue_script().
Questo però non significa che un tema o plugin debba caricare una propria copia arbitraria.
In WordPress la strada corretta consiste normalmente nel dichiarare le dipendenze attraverso il sistema di enqueue, ad esempio:
wp_enqueue_script(
'mio-script',
get_stylesheet_directory_uri() . '/js/mio-script.js',
array( 'jquery' ),
'1.0.0',
true
);
In questo modo WordPress può gestire l’ordine di caricamento della dipendenza.
Sostituire manualmente la copia inclusa nel CMS con una release differente può invece rompere temi o plugin che si aspettano una determinata versione o determinati comportamenti. Gli aggiornamenti vanno quindi testati nel contesto dell’intera installazione.
jQuery UI, plugin e jQuery Mobile: cosa esiste ancora
Attorno a jQuery è nato un ecosistema enorme. Non tutte le sue parti, però, hanno oggi lo stesso stato.
jQuery UI è ancora disponibile, ma in maintenance mode
jQuery UI raccoglie componenti e interazioni come accordion, autocomplete, datepicker, dialog, draggable, sortable e tabs.
Il progetto continua a essere mantenuto e le release recenti sono compatibili con jQuery 4, ma il team lo descrive attualmente come progetto in maintenance state.
In pratica vengono mantenute compatibilità, sicurezza e regressioni importanti, mentre non è pianificato un nuovo grande sviluppo di funzionalità.
Se un progetto esistente usa jQuery UI, questo è un motivo valido per mantenerne monitorata la compatibilità. Per un’interfaccia nuova, invece, valuterei prima se la piattaforma web o componenti più moderni risolvono già il problema.
I plugin jQuery vanno valutati uno per uno
Il successo della libreria ha prodotto migliaia di plugin.
Il fatto che un plugin sia basato su jQuery, però, non dice nulla sulla sua qualità attuale.
Prima di inserirne uno in un nuovo sito controlla almeno:
- data degli ultimi aggiornamenti;
- compatibilità con la versione utilizzata;
- repository e issue aperte;
- documentazione;
- eventuali vulnerabilità note;
- dimensione e dipendenze;
- possibilità di ottenere la stessa funzione con API native più semplici.
Un tutorial ancora online può consigliare un plugin che non viene mantenuto da anni. L’età della pagina e quella della dipendenza fanno quindi parte della valutazione tecnica.
jQuery Mobile è deprecato
jQuery Mobile non va più consigliato per avviare nuovi progetti.
Il progetto è stato ufficialmente deprecato e il team ha indicato agli sviluppatori di pianificare la transizione verso altre tecnologie. Puoi leggere l’annuncio ufficiale sulla deprecazione di jQuery Mobile.
È una precisazione importante perché molte vecchie guide continuano a citarlo accanto a jQuery Core e jQuery UI come se i tre progetti avessero lo stesso stato.
Non è così.
jQuery Core è attivamente mantenuto, jQuery UI è in maintenance mode e jQuery Mobile è deprecato.
Conviene ancora imparare jQuery?
Sì, se il tuo contesto di lavoro lo richiede. Ma non la userei come sostituto dell’apprendimento di JavaScript.
Se parti da zero, l’ordine più utile è:
HTML → CSS → JavaScript → API del browser → jQuery quando serve.
Imparando prima JavaScript capirai variabili, funzioni, oggetti, eventi, asincronia, DOM e debugging indipendentemente dalla libreria utilizzata.
A quel punto diventa molto più semplice capire la sua API.
Se invece lavori su WordPress, vecchi siti aziendali, template, plugin o applicazioni costruite alcuni anni fa, saper leggere questo tipo di codice può essere ancora una competenza molto pratica. Potresti incontrare continuamente:
$(".elemento")
$(this)
.on()
.ajax()
.each()
e dover capire cosa sta succedendo prima di correggere o modernizzare il codice.
Non serve quindi scegliere fra due posizioni estreme.
Dire che jQuery è indispensabile per qualsiasi sviluppatore moderno non descrive più la realtà. Dire che sia inutile perché esistono API JavaScript native ignora invece l’enorme quantità di software e siti che continuano a utilizzarla.
Conclusione
jQuery ha avuto un ruolo decisivo nell’evoluzione dello sviluppo web perché ha risolto un problema molto concreto: rendere più uniforme e semplice lavorare con JavaScript e con browser che, all’epoca, erano molto meno coerenti fra loro.
Quel problema oggi è più piccolo. querySelector(), classList, addEventListener(), fetch(), Promise, CSS transitions e molte altre API native permettono di realizzare direttamente funzionalità che in passato avrebbero portato quasi automaticamente all’utilizzo della libreria.
Ma da questo non segue che sia diventata inutile.
Il progetto è ancora mantenuto, continua a evolversi con la serie 4 e rimane importante quando lavori su progetti esistenti, WordPress, plugin, temi e codice che già dipende dalla sua API.
Per un progetto nuovo partirei quindi da JavaScript nativo e aggiungerei jQuery solo quando offre un vantaggio concreto. Per un progetto che la utilizza già, invece, non la eliminerei per principio: prima valuterei dipendenze, compatibilità e costo reale della migrazione.
La decisione corretta non è scegliere fra “vecchio” e “nuovo”, ma usare la soluzione più semplice che risolve il problema senza introdurre complessità inutile.