Ciao, e benvenuto nella quarta puntata della nona stagione. Nella scorsa puntata la rivoluzione di AJAX aveva reso il Web reattivo e affamato di JavaScript. Ma c'era un problema enorme che rendeva quel sogno un incubo quotidiano per chi doveva realizzarlo: scrivere JavaScript, all'epoca, era una sofferenza. Oggi raccontiamo lo strumento che risolse quella sofferenza e dominò il Web per un decennio intero: una libreria chiamata jQuery.
Per capire perché jQuery fu così amata, dobbiamo capire quanto era doloroso il problema che risolse. E il problema, ancora una volta, erano i browser. Riprendo un tema centrale della stagione sul CSS: negli anni Duemila i browser erano tutti diversi tra loro, e non solo per lo stile. Anche il modo di scrivere JavaScript per manipolare la pagina cambiava da un browser all'altro. La stessa identica cosa, per esempio trovare un elemento nella pagina o reagire a un clic, si scriveva in modi diversi a seconda del browser, e dovevi gestire tutte le varianti a mano.
Immagina la fatica. Volevi fare una cosa semplice, e dovevi scrivere il codice tre volte, una per ciascun browser importante, con condizioni per capire in quale ti trovavi e comportarti di conseguenza. Il codice si riempiva di controlli, di casi speciali, di rimedi per le stranezze di ciascun browser. Una cosa banale diventava lunga, contorta e piena di trappole. Scrivere JavaScript che funzionasse ovunque richiedeva di conoscere a memoria le differenze e i difetti di ogni browser. Era un lavoro da specialisti, frustrante e lento.
In questo panorama, nel duemilasei, arrivò una libreria che avrebbe cambiato la vita a milioni di sviluppatori. La sua idea era semplice e geniale: nascondere tutte le differenze tra i browser dietro un modo unico, semplice ed elegante di scrivere le cose. Tu scrivevi il tuo codice una volta sola, in modo pulito, e la libreria si occupava dietro le quinte di farlo funzionare correttamente su tutti i browser, gestendo lei tutte le stranezze. Prendeva la parte più dolorosa del lavoro e la faceva sparire. Il suo motto, non a caso, era una promessa di scrivere meno per fare di più.
E fu esattamente ciò che accadde. Con quella libreria, cose che prima richiedevano venti righe contorte e piene di casi speciali diventavano una singola riga, chiara e leggibile. Trovare elementi nella pagina, modificarli, reagire agli eventi, fare quelle richieste in sottofondo di cui abbiamo parlato: tutto diventava semplice, breve, elegante. Era una liberazione. Gli sviluppatori la adottarono in massa, con entusiasmo, e nel giro di pochi anni divenne onnipresente: una fetta enorme di tutti i siti del mondo la usava. Per circa un decennio, jQuery fu, di fatto, il modo in cui si scriveva JavaScript.
Voglio sottolineare l'effetto democratizzante di questo strumento, perché riprende un tema della stagione sul CSS. Prima, scrivere JavaScript interattivo che funzionasse ovunque era un'arte da pochi esperti. Con questa libreria, diventò accessibile a moltissimi. Persone che non erano maghi delle differenze tra browser potevano finalmente costruire pagine ricche e interattive. La libreria abbassò enormemente la barriera d'ingresso, e questo accelerò l'intera evoluzione del frontend, perché improvvisamente molte più persone potevano partecipare a costruire il Web reattivo che tutti volevano.
Ma ogni epoca, nella nostra storia, prepara la propria fine, ed è affascinante capire perché jQuery, dopo aver dominato, lentamente declinò. Due cose accaddero. La prima: il problema che risolveva, la differenza tra browser, si attenuò col tempo. Come abbiamo raccontato per il CSS, i browser lentamente si allinearono agli standard comuni, e molte delle comodità che jQuery offriva entrarono direttamente nel linguaggio, diventando native. A un certo punto, il linguaggio stesso sapeva fare, in modo pulito, ciò per cui prima serviva la libreria. Il motivo principale della sua esistenza, pian piano, svanì.
La seconda ragione del declino è ancora più importante, e anticipa il resto della stagione. jQuery era nata per un Web fatto di pagine a cui aggiungere un po' di interattività: trova questo elemento, modificalo, reagisci a quel clic. Ma il Web stava diventando qualcosa di più ambizioso: vere e proprie applicazioni complesse dentro il browser. E per costruire applicazioni intere, l'approccio di jQuery, fatto di tante piccole modifiche puntuali alla pagina, non bastava più: diventava caotico e ingestibile. Serviva un modo completamente nuovo di pensare, e quel modo nuovo sarebbe arrivato con i framework, di cui parleremo. jQuery aveva vinto la battaglia del suo tempo, ma il tempo stava cambiando.
Per oggi ci fermiamo qui. Negli anni Duemila scrivere JavaScript era una sofferenza, perché ogni browser voleva le cose a modo suo. La libreria jQuery, arrivata nel duemilasei, risolse questo dolore nascondendo le differenze dietro un modo unico, semplice ed elegante di scrivere, e per questo dominò il Web per un decennio, democratizzando l'interattività. Poi declinò, perché i browser si allinearono e perché il Web passò da pagine interattive ad applicazioni intere, che richiedevano un pensiero nuovo. Nella prossima puntata nasce proprio quel pensiero nuovo: le applicazioni a pagina singola. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.