jQuery di John Resig ha semplificato JavaScript, appianato le incongruenze tra browser e diffuso pattern che hanno influenzato gli strumenti front-end per anni. Ecco come ha plasmato il web.
Se costruivi un sito intorno al 2005–2008, non «scrivevi JavaScript» in senso semplice. Dovevi trattare con i browser.
Una funzione semplice—evidenziare una voce di menu, mostrare una modale, validare un form, caricare un frammento di HTML senza ricaricare la pagina—poteva trasformarsi in un piccolo progetto di ricerca. Cercavi quale metodo esisteva in quale browser, quale evento si comportava diversamente e perché quella chiamata al DOM funzionava sulla tua macchina ma si rompeva per metà degli utenti.
Gli sviluppatori volevano «scrivi una volta, esegui ovunque», ma le differenze tra browser facevano sembrare il tutto come «scrivi tre volte, testa ovunque». Internet Explorer aveva le sue stranezze, versioni più vecchie di Firefox e Safari discutevano su casi limite, e anche basi come la gestione degli eventi e la manipolazione del DOM potevano essere incoerenti.
Questa discrepanza non solo faceva perdere tempo—cambiava ciò che i team osavano costruire. Le interfacce interattive erano possibili, ma costose in termini di lavoro e fragili nella manutenzione. Molti siti restavano più semplici di quanto avrebbero potuto essere perché il costo per farlo funzionare su tutti i browser era troppo alto.
jQuery, creato da John Resig, contava perché si concentrava sui compiti di tutti i giorni: selezionare elementi, reagire alle azioni dell'utente, modificare la pagina, animare piccole transizioni e fare richieste AJAX. Offriva una API piccola e leggibile che appianava le differenze tra browser così potevi passare più tempo a costruire la funzionalità e meno a lottare con la piattaforma.
In pratica, rese le interazioni comuni semplici e ripetibili—qualcosa che si poteva insegnare, condividere e riutilizzare.
La storia non è solo che jQuery ha fatto risparmiare tempo. Ha influenzato il modo di pensare degli sviluppatori: concatenare operazioni, affidarsi a selettori concisi, organizzare il codice UI attorno agli eventi e aspettarsi che le librerie offrano una "esperienza sviluppatore" coerente. Quelle abitudini hanno plasmato gli strumenti successivi, anche dopo che gli standard web hanno raggiunto la parità e nuovi framework hanno preso il sopravvento.
Quella mentalità del “rendere facile il percorso comune” è visibile anche negli strumenti odierni. Piattaforme moderne come Koder.ai applicano lo stesso principio di esperienza sviluppatore a un livello diverso—permettono ai team di costruire app web, backend e mobile tramite un flusso di lavoro guidato in chat—dove jQuery una volta rendeva il codice UI rivolto al browser più accessibile.
John Resig non voleva iniziare un movimento quando ha iniziato a smanettare con una piccola libreria helper JavaScript a metà anni 2000. Era uno sviluppatore pratico che provava la stessa frizione che provavano tutti: le cose semplici sul web richiedevano troppe righe di codice, si rompevano in browser sorprendenti e erano difficili da spiegare ai colleghi.
La motivazione principale di Resig era la chiarezza. Invece di chiedere agli sviluppatori di memorizzare dozzine di stranezze dei browser, voleva un piccolo set di comandi che corrispondesse a come le persone pensavano di costruire pagine: “trova questo elemento”, “cambia questo”, “quando l'utente clicca, fai quello”. jQuery non è stato creato per mostrare genialità—è stato creato per ridurre la frustrazione quotidiana e aiutare progetti ordinari a essere consegnati.
Altrettanto importante era l'empatia per lo sviluppatore web tipico. La maggior parte delle persone non costruiva demo sperimentali; manteneva siti di marketing, pannelli di amministrazione e pagine prodotto con scadenze. L'attenzione di jQuery su una API compatta e leggibile rifletteva quella realtà.
jQuery si diffuse perché era facile da imparare e facile da passare agli altri. Resig faceva talk e demo che mostravano vantaggi immediati, e il progetto sviluppò rapidamente la reputazione di ottima documentazione ed esempi accessibili. Questo contava: quando uno strumento ti aiuta a risolvere un problema reale in pochi minuti, lo racconti ad altri sviluppatori.
La community iniziale ha rafforzato questo circuito. Le persone condividevano snippet, scrivevano plugin e segnalavano casi limite di browser e dispositivi che Resig non poteva testare da solo. jQuery è cresciuto in pubblico, con i feedback che hanno modellato cosa rimanesse semplice e cosa venisse lisciato.
È tentante ridurre jQuery a un singolo “momento geniale”, ma la storia più onesta è perseveranza e buon giudizio: notare un dolore diffuso, progettare per i flussi di lavoro quotidiani e costruire fiducia attraverso la coerenza. Resig non ha solo scritto codice—ha creato uno strumento che sembrava una scorciatoia amichevole per il modo in cui il web funzionava davvero.
Prima di jQuery, scrivere un comportamento interattivo “semplice” spesso significava cucire insieme una pila di soluzioni specifiche per browser. Si potevano assolutamente costruire interfacce ricche, ma il costo era tempo, pazienza e molti test.
Oggi prendere un pulsante e cambiarne il testo sembra una riga. Allora la selezione del DOM era incoerente e scomoda. Alcuni browser supportavano metodi utili, altri no, e finivi per mescolare approcci come getElementById, getElementsByTagName, loop manuali e controlli su stringhe solo per mirare agli elementi giusti.
Anche quando selezionavi quello che ti serviva, spesso dovevi scrivere codice extra per gestire collezioni, convertirle in array o aggirare casi limite strani.
Gestire click, pressioni di tasti e hover era una richiesta comune—ma i browser erano in disaccordo su come legare eventi e su com'era fatto l'oggetto evento. Codice che funzionava perfettamente in un browser poteva fallire silenziosamente in un altro.
Gli sviluppatori scrivevano wrapper per normalizzare la gestione degli eventi: “Se questa API esiste, usala; altrimenti usa quest'altra.” Questo significava più codice, più debug e più modi in cui i bug potevano insinuarsi.
Le richieste asincrone erano possibili, ma non erano amichevoli. Configurare un XMLHttpRequest tipicamente comportava più passaggi, logica a rami per browser diversi e attenta gestione degli stati di risposta.
Una piccola funzione—come inviare un form senza ricaricare la pagina—poteva gonfiarsi in dozzine di righe più retry, gestione degli errori e test su browser.
Il dolore più grande non era scrivere il codice una sola volta; era mantenerlo funzionante ovunque. I team avevano bisogno di qualcosa di affidabile, facile da imparare e abbastanza coerente da permettere a nuovi sviluppatori di contribuire senza memorizzare una checklist di compatibilità browser. jQuery arrivò come risposta a quella frizione quotidiana.
La svolta di jQuery non fu una nuova capacità del browser—fu un nuovo modo di pensare al lavoro UI quotidiano. Invece di scrivere tanto JavaScript specifico per browser solo per trovare un elemento, aggiornarlo e collegare un evento, jQuery ridusse la routine a uno schema semplice: seleziona qualcosa, poi falla qualcosa.
Al centro c'è la funzione $(). Le passi un selettore in stile CSS (o un elemento), e ottieni un oggetto jQuery—un wrapper semplice da usare sugli elementi corrispondenti.
Da lì chiami metodi che sembrano compiti: aggiungi una classe, nascondi un elemento, cambia testo, attacca un gestore di click. Lo scopo non era esporre ogni dettaglio di basso livello; era coprire l'80% dei lavori UI che quasi ogni sito richiedeva.
jQuery incoraggiava uno stile fluente dove ogni step restituisce lo stesso oggetto jQuery, così puoi “concatenare” azioni in una linea leggibile:
$(".notice")
.addClass("active")
.text("Saved!")
.fadeIn();
Anche se non capivi gli interni, potevi capire la storia: trova le notice, segnale come attive, imposta il messaggio, mostrale.
Prima di jQuery, gli sviluppatori si chiedevano continuamente: “Quale metodo funziona in questo browser?” o “Questa proprietà ha nome diverso nelle versioni più vecchie?” jQuery rispondeva con un set coerente di metodi e comportamenti prevedibili. I principianti avevano una curva di apprendimento dolce; i professionisti guadagnavano velocità: meno funzioni helper personalizzate, meno hack di compatibilità e meno codice da revisionare.
Poiché l'API era compatta e i nomi dei metodi corrispondevano alle intenzioni UI, jQuery spingeva i team verso script più facili da leggere. Invece di chiamate DOM sparse e variabili temporanee, potevi leggere il codice come una sequenza di azioni UI—facendo sembrare il lavoro front-end più simile ad assemblare passi chiari che a combattere con il browser.
Uno dei trucchi più persuasivi di jQuery fu rendere il primo passo di ogni compito UI banale: selezionare gli elementi giusti. Invece di ricordare metodi DOM specifici per browser e le loro stranezze, potevi scrivere qualcosa che sembrava CSS e aveva senso immediatamente.
Designer e sviluppatori front-end già pensavano in selettori: “prendi tutti i .button dentro l'header”, “mira al primo elemento”, “trova input di un certo tipo”. jQuery trasformò quel modello mentale in uno strumento JavaScript:
$(".nav a") per lavorare con i link nella navigazione$("#signup-form input[type=email]") per trovare un campo specifico$("ul li:first") per una logica rapida del “primo elemento"Quella leggibilità contava. Ridusse lo sforzo di traduzione tra “ciò che voglio” e “come il DOM vuole che lo chieda”.
Dietro $(selector) c'era Sizzle, il motore di selezione di jQuery. I browser iniziali non erano d'accordo su come certi selettori dovevano comportarsi, e alcuni non supportavano affatto l'insieme completo. Sizzle forniva un'interpretazione coerente e comportamenti di fallback, così $(".card > .title") non diventava una lotteria tra browser.
Il risultato fu produttività reale: meno rami condizionali, meno “se IE allora…” e meno tempo speso a debug per capire perché un selettore funzionava in un browser ma non in un altro.
La potenza dei selettori nascondeva anche dei costi:
Ciononostante, per il lavoro di interfaccia quotidiano, rendere facile il “trovarlo” fu un enorme cambiamento—e una grande ragione per cui jQuery sembrava una superpotenza.
Per molti sviluppatori, jQuery non era “una libreria”—era l'insieme quotidiano di strumenti che usavi per costruire interazioni. Trasformava il lavoro UI comune in poche chiamate prevedibili, anche quando i browser discutevano sui dettagli.
Prima di jQuery, collegare un gestore di click poteva significare destreggiarsi tra modelli di eventi diversi e casi limite strani. .on() di jQuery (e prima .bind()/.click()) offriva un modo coerente per ascoltare azioni utente come click, submit e input da tastiera.
Rendeva anche ovvio “esegui questo quando la pagina è pronta”:
$(function () {
// safe to touch the DOM
});
Questa abitudine singola riduceva i bug di timing nelle pagine tipiche—niente più dubbi se gli elementi esistessero già.
L'API DOM di jQuery era intenzionalmente piccola e pratica. Devi aggiornare il contenuto? .text() o .html(). Costruire pezzi UI? ('<div>...</div>') e .append(). Stati visivi? .addClass(), .removeClass(), e .toggleClass().
Invece di gestire differenze tra className, stranezze degli attributi e metodi di nodo incoerenti, gli sviluppatori potevano concentrarsi su cosa volevano cambiare.
Animazioni integrate come .hide(), .show(), .fadeIn() e .slideToggle() facevano sembrare le pagine vive con poco sforzo. I designer le amavano, gli stakeholder le notavano e i tutorial le usavano spesso.
Lo svantaggio: gli effetti erano facili da abusare—troppe dissolvenze e scivolamenti potevano rendere le interfacce lente o goliardiche. Tuttavia, per interazioni tipiche (menu, accordion, notifiche), jQuery abbassava la barriera per “fargli sembrare rifinito”.
Attraverso eventi, cambi al DOM ed effetti, il vero vantaggio era la semplicità: meno casi limite nel lavoro quotidiano e un set condiviso di pattern che i team potevano apprendere rapidamente.
Prima di jQuery, “AJAX” suonava come un trucco: aggiornare parte di una pagina senza ricaricare tutto. In termini semplici, è solo il browser che manda una richiesta in background, riceve dati (spesso HTML o JSON) e aggiorna la pagina così l'utente può continuare.
XMLHttpRequest a una rigaLa funzionalità di base era XMLHttpRequest, ma usarla direttamente significava molto codice ripetitivo: creare la richiesta, monitorare lo stato, parsare la risposta, gestire stranezze dei browser.
jQuery incapsulò quella complessità in metodi helper che sembravano strumenti di uso quotidiano:
$.ajax() per il controllo totale$.get() / $.post() per richieste semplici.load() per recuperare HTML e iniettarlo in un elementoInvece di costruire handler, generare query string e parsare risposte da soli, potevi concentrarti su cosa l'utente doveva vedere dopo.
Questi pattern divennero rapidamente normali sui siti:
Anche con server datati, jQuery permetteva all'interfaccia di sembrare reattiva.
jQuery rendeva le richieste facili da iniziare—ma non sempre facili da completare correttamente. Errori comuni includevano:
L'API abbassava la barriera, ma insegnava anche una lezione che vale ancora: il percorso felice è solo metà del costruire un'interfaccia affidabile.
jQuery non era solo una libreria che scaricavi—era una piattaforma su cui le persone costruivano. I “plugin” erano piccole estensioni che aggiungevano nuovi metodi, di solito attaccando funzioni a $.fn. Per gli sviluppatori, questo significava che potevi inserire una funzionalità e chiamarla con lo stesso stile che usavi per tutto il resto.
La soglia d'ingresso era bassa. Se conoscevi jQuery, capivi già il pattern dei plugin: seleziona elementi, chiama un metodo, passa opzioni.
Ancora più importante, le convenzioni di jQuery facevano sembrare i plugin sorprendentemente coerenti, anche se scritti da autori diversi:
$('.menu').dropdown() leggeva come jQuery nativo.$('.btn').addClass('x').plugin().fadeIn().{ speed: 200, theme: 'dark' }, facile da copiare e modificare.I plugin coprivano la “zona mancante” tra lavoro DOM grezzo e framework applicativi completi. Categorie comuni erano slider e carousel, validazione di form, modali e lightbox, date picker, autocomplete, tooltip e helper per tabelle.
Per molti team, specialmente quelli che lavoravano su siti marketing o dashboard interne, i plugin trasformavano settimane di lavoro UI in un giorno di assemblaggio.
Il boom dei plugin aveva un costo. La qualità variava moltissimo, la documentazione poteva essere scarsa e combinare più plugin a volte portava a conflitti CSS o handler in conflitto. La dipendenza crescente diventò reale: una funzione poteva dipendere da altri due plugin, ognuno con la propria storia di aggiornamenti. Quando gli autori abbandonavano i progetti, i plugin non mantenuti potevano vincolare un progetto a versioni vecchie di jQuery—o diventare un rischio per sicurezza e stabilità.
Il core di jQuery rendeva il lavoro sul DOM prevedibile, ma i team dovevano ancora costruire pezzi di interfaccia da zero. jQuery UI colmò quella lacuna con una raccolta di componenti pronti—date picker, dialog, tab, slider, accordion, comportamenti drag/sortable—impacchettati in modo che funzionassero tra browser con poca fatica. Per team piccoli e agenzie che consegnavano molti siti marketing o strumenti interni, quel valore del "buono abbastanza, ora" era difficile da battere.
Il grande vantaggio non erano solo i widget—era la combinazione di widget più API coerente e theming. Potevi prototipare velocemente inserendo una dialog o un autocomplete, poi uniformarne l'aspetto con ThemeRoller invece di riscrivere markup e pattern CSS per ogni progetto. Quella ripetibilità faceva sembrare jQuery UI più un kit pratico che un design system.
jQuery Mobile cercò di risolvere un problema diverso: gli smartphone iniziali avevano capacità del browser incoerenti e supporto CSS limitato, e le convenzioni responsive erano ancora in via di definizione. Offriva componenti touch-friendly e un modello di navigazione “single-page” con transizioni Ajax di pagina, puntando a far sembrare una base di codice unica un'app quasi nativa.
Con il migliorare degli standard web—CSS3, browser mobili migliori e controlli nativi più evoluti—alcune di queste astrazioni divennero più un costo che un beneficio. I widget jQuery UI potevano essere pesanti, difficili da rendere accessibili e complicati da allineare con aspettative di design moderne. Il modello di riscrittura del DOM e navigazione di jQuery Mobile entrava anche in conflitto con approcci successivi come layout responsive-first e routing basato su framework.
Nonostante ciò, entrambi i progetti dimostrarono un'idea chiave: componenti UI condivisi e riutilizzabili possono accelerare enormemente la consegna nel mondo reale.
jQuery non solo ha fatto comportare meglio i browser; ha cambiato l'aspetto del codice front-end “normale”. I team iniziarono a scrivere JavaScript ogni giorno, non solo per pagine speciali, perché i compiti UI comuni sembravano improvvisamente prevedibili.
Uno dei cambiamenti culturali più grandi di jQuery fu la popolarizzazione dello chaining: seleziona qualcosa, poi continua a operare su di essa in un flusso leggibile.
$(".card")
.addClass("active")
.find(".title")
.text("Updated")
.end()
.fadeIn(200);
Questo stile fluente influenzò librerie successive e anche API native moderne. Spinse inoltre gli sviluppatori verso operazioni piccole e componibili invece di funzioni monolitiche.
Gli helper di jQuery—$.each, $.map, $.extend, scorciatoie AJAX—renderono allettante comprimere la logica in poche righe. Questo migliorava la velocità di sviluppo, ma incoraggiava anche one-liner “furbi” e comportamenti impliciti difficili da riprendere mesi dopo.
Molti codebase finivano con logica di business mescolata direttamente in handler di click, perché era così facile “farlo qui e basta”. Quella comodità accelerava la consegna, ma spesso aumentava la complessità a lungo termine.
Prima che componenti e modelli di stato prevedibili diventassero comuni, le app jQuery spesso memorizzavano lo stato nel DOM: classi, input nascosti e attributi data. Il debug significava ispezionare HTML live e fare stepping attraverso callback evento che potevano scatenarsi in ordini sorprendenti.
I test unitari erano possibili, ma i team facevano più spesso QA manuale e usavano gli strumenti di sviluppo del browser. I problemi erano frequentemente legati al timing (animazioni, AJAX, bubbling degli eventi), rendendo i bug intermittenti.
Il codice jQuery tendeva a rimanere manutenibile quando i team:
Diventava ingarbugliato quando le pagine accumulavano strati di handler, selettori ripetuti ovunque e “solo un'altra” modifica dentro un callback di animazione. La libreria rendeva l'iterazione rapida facile; la disciplina determinava se il risultato invecchiava bene.
jQuery non scomparve dall'oggi al domani, e non “perse” perché peggiorò. Ha perso terreno perché la piattaforma browser non aveva più bisogno di un traduttore. I problemi che jQuery aveva appianato—API mancanti, comportamenti incoerenti e flussi di lavoro macchinosi—divennero meno comuni man mano che gli standard maturavano e i browser convergevano.
Man mano che le API DOM e JavaScript si standardizzavano, molte chiamate jQuery quotidiane ottennero equivalenti diretti:
document.querySelector() e document.querySelectorAll() coprivano la maggior parte dei casi che prima richiedevano $(...).addEventListener() divenne universalmente affidabile, rimuovendo una grande fetta di lavoro di compatibilità.fetch() (e poi async/await) rese le chiamate in stile AJAX native e leggibili.Quando il “modo nativo” è coerente tra browser, la ragione di dipendere da un helper si riduce.
Con la crescita delle web app da pochi widget interattivi a prodotti completi, i team iniziarono a misurare tempo di caricamento e costo del JavaScript più seriamente. Spedire jQuery (più plugin) per qualche comodità diventava più difficile da giustificare—soprattutto su reti mobili.
Non è che jQuery fosse lento; è che “un'altra dipendenza” divenne un compromesso reale. Gli sviluppatori preferivano utility più piccole e mirate—or nessuna libreria quando la piattaforma faceva già il lavoro.
I framework per single-page application spostarono l'attenzione dal manipolare manualmente il DOM verso la gestione dello stato e la composizione dell'interfaccia con componenti. In React/Vue/Angular normalmente non chiedi alla pagina “trova questo elemento e cambialo”. Aggiorni i dati e l'interfaccia si ridisegna.
In quel modello, i punti di forza di jQuery—manipolazione imperativa del DOM, effetti e wiring one-off degli eventi—sono meno centrali e talvolta scoraggiati.
La missione di jQuery era rendere il web utilizzabile e coerente. Quando i browser hanno recuperato terreno, jQuery è diventato meno necessario—non meno importante. Molti siti di produzione lo usano ancora, e molte API moderne (e aspettative degli sviluppatori) riflettono le lezioni che jQuery ha insegnato all'intero ecosistema.
jQuery non è più la scelta di default per nuovo lavoro front-end, ma ancora alimenta silenziosamente una quantità sorprendente di web—e la sua influenza è radicata nel modo in cui molti sviluppatori pensano a JavaScript.
Lo incontrerai più spesso in contesti che danno priorità alla stabilità rispetto alle riscritture:
Se mantieni uno di questi progetti, il vantaggio è prevedibilità: il codice è comprensibile, ben documentato e di solito facile da correggere.
Gli strumenti moderni non hanno copiato jQuery riga per riga, ma hanno assorbito i suoi migliori istinti:
Anche l'evoluzione del JavaScript “vanilla” (come querySelectorAll, classList, fetch e una migliore gestione degli eventi) riflette i problemi che jQuery risolveva per gli sviluppatori quotidiani.
La lezione più grande è il pensiero di prodotto: una API piccola e coerente unita a ottima documentazione può cambiare il modo in cui un'intera industria scrive codice.
È anche un promemoria che l'esperienza sviluppatore si somma. Nell'era di jQuery, la DX significava nascondere le stranezze dei browser dietro una API pulita; oggi può anche significare accorciare il percorso dall'idea al software funzionante. Questo è parte del motivo per cui piattaforme vibe-coding come Koder.ai risuonano con molti team: invece di assemblare boilerplate a mano, puoi iterare in un'interfaccia chat, generare un front end React con un backend Go + PostgreSQL (o un'app mobile Flutter), e continuare a muoverti—pur conservando l'opzione di esportare il codice sorgente quando vuoi pieno controllo.
jQuery contava perché trasformava lo scripting DOM, incoerente e specifico per browser, in un piccolo insieme di strumenti prevedibili. Rendeva compiti quotidiani—selezionare elementi, collegare eventi, modificare il DOM, fare AJAX—ripetibili attraverso i browser, aumentando velocità e fiducia del team.
Prima di jQuery gli sviluppatori si scontravano regolarmente con differenze tra browser in:
XMLHttpRequest)Il costo principale non era scrivere il codice una volta, ma mantenerlo affidabile ovunque.
$() è la funzione centrale: le passi un selettore in stile CSS (o un elemento) e ottieni indietro un oggetto jQuery che avvolge gli elementi corrispondenti. Quell'oggetto espone un set coerente di metodi così puoi “trovare, poi agire” senza preoccuparti dei dettagli specifici del browser.
Lo chaining è importante perché la maggior parte dei metodi jQuery restituisce lo stesso oggetto jQuery dopo aver eseguito un'azione. Questo ti permette di esprimere una sequenza di operazioni UI in un unico flusso leggibile (seleziona → modifica → anima) con meno variabili temporanee.
Sizzle è il motore di selezione dietro $(selector). Ha fornito un comportamento coerente dei selettori e supporto più ampio in un'epoca in cui i browser differivano su cosa supportavano e su come interpretavano casi limite.
jQuery normalizzava i compiti comuni sugli eventi così non dovevi scrivere ramificazioni specifiche per browser. Ha anche reso pratico eseguire codice quando il DOM è pronto:
$(function () {
// safe to touch the DOM
});
Questo ha ridotto i bug legati al timing nelle pagine tipiche.
I helper AJAX di jQuery incapsulavano le parti ripetitive di XMLHttpRequest e rendevano i casi comuni semplici:
$.ajax() per controllo totale$.get() / $.post() per richieste semplici.load() per recuperare HTML dentro un elementoHa abbassato la barriera per costruire interfacce reattive, ma serviva comunque una gestione degli errori solida e feedback all'utente.
I plugin estendevano jQuery aggiungendo metodi (di solito su $.fn) così le funzionalità potevano essere usate come chiamate jQuery native. Questo ha reso facile “inserire” capacità UI comuni (modali, validazione, slider) usando schemi familiari: selettori + oggetti di opzioni + chaining.
jQuery ha perso popolarità principalmente perché i browser hanno standardizzato le funzionalità che un tempo mascherava:
querySelector(All) ha ridotto la necessità di helper per i selettoriaddEventListener() è diventato affidabile ovunquefetch() + async/await hanno reso il codice di rete più leggibileCon la crescita dell'attenzione su bundle size e performance, includere jQuery per poche comodità è diventato più difficile da giustificare.
Non riscrivere solo per eliminarlo. Un approccio pratico è:
jQuery è spesso più difendibile in app legacy, temi/plugin di CMS più vecchi e piccoli miglioramenti “già presenti nella pagina”.