Ne hanno parlato al Front End Meetup di Milano partendo dallo speech di Claudio Bisconti, programmatore e sviluppatore web. Difficilmente jQuery scomparirà, però oggi ci sono librerie più performanti, come Angular e React, che effettuano operazioni complesse meglio di jQuery.

Il 27 Aprile a Milano si è tenuto un meetup dal titolo “Ma si usa ancora jQuery”, organizzato da Milano Front End: si è parlato dell’uso opportuno di questa popolarissima libreria Javascript, in che progetti è bene usarla e in quali, invece, è meglio dirottare su altri framework, come Angular e React. Si sono anche fatte previsioni su una sua eventuale scomparsa dal mercato.

Lo speech è stato tenuto da Claudio Bisconti, programmatore dipendente di un’azienda, la Commit Software, avente sede a Firenze, Milano e Tirana (in Albania) che sviluppa software di tutti i generi, comprese applicazioni web. Organizza anche corsi di formazione a Firenze presso la Commit University, un laboratorio di cultura digitale.

Bisconti ha condiviso la sua esperienza di programmatore, nel corso della quale ha potuto capire quali siano le migliori librerie e i framework più adatti per ogni tipo di progetto, in modo coinvolgente, condendo il tutto con delle citazioni parafrasate di alcuni personaggi famosi, che si possono leggere nelle sue slides, linkate qua sotto.

Vedi le slides di “Ma si usa ancora jQuery?”.

La storia di jQuery

jQuery è un progetto della jQuery Foundation e fu inventata da John Resig (ndr); la prima release, la 1.0, risale al 2006, l’ultima, la 3.0, è uscita nel 2016. L’autore avrebbe voluto chiamarla jSelect ma, dato che nessun dominio con quel nome fosse disponibile, ha dovuto adottare jQuery.
Qui sono elencate tutte le versioni rilasciate nel corso degli anni:

• 1.0=>2006
• 1.1=>2007
• 1.9=>2013 (la più importante)
• 2.0=>2013
• 3.0=>2016

Per saperne di più

• https://www.slideshare.net/jeresig/history-of-jquery, slides sulla storia di jQuery, elaborate nel 2009.
• Storia di jQuery (in inglese dal sito ufficiale)

Il segno dollaro ($)

Molti sviluppatori Javascript associano il simbolo $ alla libreria jQuery. In realtà nella versione 3 di ECMAScript, del 24 Marzo 2000, viene aggiunto questo carattere tra quelli utilizzabili come identificatore, esattamente come l’underscore (_). Pertanto $!=jQuery.

Mi capita, infatti, quando devo integrare un codice js basato su jQuery, in un sito fatto con WordPress, di richiamare la libreria scrivendo jQuery(selettore).metodo(args), a meno di iniziare il codice in questo modo: $=jQuery;. In caso contrario la console.log mi produrrà un errore, “$ is undefined”.

L’utilità di jQuery

jQuery è nata per facilitare la manipolazione del DOM tramite Javascript. Nel codice sottostante viene riportato un esempio.

<div>
    <label>This is div.</label>
</div>

<script type="text/javascript">
    $('div').prepend('<p>this is prepended paragraph.<p>');
    $('div').before('<p>this is new paragraph.<p>');
    $('div').after('<p>this is new paragraph.<p>');
    $('div').append('<p>this is appended paragraph.<p>');
</script>

Questo codice genera il seguente codice html.

<p>This is new paragraph.</p>
<div>
    <p>This is prepended paragraph.</p>
    <label>This is div.</label>
    <p>This is appended paragraph.</p>
</div>
<p>This is new paragraph.</p>
<p>This is paragraph.</p>

Il motto di jQuery è “Write less, do more” (Scrivi di meno, fai di più); questo poteva essere vero fino all’avvento di Angular e React. Rispetto al puro Javascript il codice basato su jQuery è più breve ma, se si osserva nei codici che seguono, ci si rende conto che con Angular e React il codice è ancora più breve; nel caso di Angular è integrato nell’html. Angular e React, ognuno a suo modo, distinguono il codice html dal Javascript.

//jQuery
$(function(){
    var elements=//...
    $('#tbody').empty();
    $.each(elements, function(index, element)
    
        var output='<tr class="element-';
        if(element.id % 2 == 0)
            output += 'even';
        else
            output += 'odd';
        output += '">';
        
        output += '<td>' + element.name + '</td>'
        output += '<td>';
        
        var skills=element.skill.split(',');
        $.each(skills, function(index, skill){
            output += '<span class="skill">#' + skill.trim() + '</span>';
        })
        
         output += '</td'>;
         output += '</tr'>;
         $('#tbody'). append(output);
    });
});

//Angular

<table>
    <tbody>
        <tr ng-repeat="e in elements" ng-class-odd="'odd'" ng-class-even="'even'">
            <td>{{e.name}}</td>
            <td>
                <span ng-repeat= "skill in e.skills | split:,">#{{ skill }}</span>
            </td>
        </tr>
    </tbody>
</table>

//React
 
var renderedEl = this.props.elements.map(function(e(){
    return(
        <tr>
            <td>{{ e.name }}</td>
            ...
        </tr>
    );
});

L’uso abusivo di jQuery

L’utilizzo sconsiderato di jQuery rende lo script più pesante per la macchina e più difficile da gestire in progetti complessi.
Consideriamo il codice sottostante

$("#foo").show();
$("#foo").addClass("thing");
$("#foo").hide();

$("#foo").on("click", function(){
    //di solito sono almeno 100 righe di codice,
    //un onclick è per sempre
});
//...

$("#foo").find("ul > li.event > input[type=checkbox]").adClass("black");

Senza stare a spiegare completamente la logica si può notare che l’elemento con l’id “foo” viene richiamato tramite jQuery tutte le volte. Non è una prassi molto consigliabile: se un altro sviluppatore dovesse cambiare l’id all’elemento in questione bisognerebbe correggere tutti i metodi jQuery su di esso applicati; inoltre il browser, ad ogni chiamata, dovrebbe creare un puntatore all’elemento interessato, con conseguenti rallentamenti. Molto meglio creare il puntatore una volta sola e memorizzarlo in una variabile, in questo modo: var foo=$(‛#foo’);.

Molti sviluppatori iniziano usando jQuery e imparano a utilizzarlo per fare qualsiasi cosa; in questo modo trascurano html e css: è possibile trovare css inline messo da Javascript e poche righe html nel codice sorgente, le restanti sono anch’esse generate dinamicamente.

Questa procedura, ndr, non solo rende la pagina più pesante da caricare ma ostacola anche il posizionamento del sito su Google: mancano tutta una serie di informazioni html utili ai motori di ricerca per leggere i contenuti della pagina.

Bisconti, poi, ha segnalato come abusivi alcuni tipici plugin jQuery, come jQuery UI e jQuery Mobile. La prima, pur funzionando bene, produce tanto codice html e questo crea una situazione non ottimale per il browser che deve eseguire le istruzioni.

La seconda, nata nel 2010, sin da subito cominciò a creare problemi prestazionali su dispositivi mobile. Secondo alcuni programmatori sarebbero stati i dispositivi a essere troppo lenti nell’elaborazione dei dati. Bisconti, a tal proposito, ha affermato che nel 2015 un’app, sviluppata con jQuery Mobile, fatta girare su uno smartphone 4 core a 2.5GHZ non ha dato prestazioni migliori.

Un partecipante ha affermato in proposito che anni fa andava bene perché garantiva compatibilità su tutti i dispositivi. Bisconti ha risposto che per l’epoca questo framework fu eccezionale poiché era l’unico ad essere ottimizzato per il mobile. Successivamente, però, è uscito Flat, per il quale non c’erano temi compatibili e i plugin di jQuery compromettevano pesantemente le performance, tanto che lo sviluppatore si ritrovava a dover riscrivere pesantemente il codice.

All’epoca in cui uscì jQuery mobile non erano pronte Cordova e Bootstrap e quindi la scelta era obbligata, a differenza di oggi dove ci sono diverse librerie alternative, tipo Ionic e Angular.

Le evoluzioni di jQuery per stare al passo

Qunit

Si tratta di un framework pensato per testare jQuery, jQuery UI, jQuery Mobile e anche il proprio codice Javascript. Il problema è che nessuno abitualmente esegue dei test sul codice; inoltre ci sono altri framework più utili a tale scopo, come unitjs, jasmine, Jest.

Modularità

Mentre ieri jQuery era da allegare integralmente, anche se ne veniva usata solo una minima parte, oggi è possibile creare una versione personalizzata, tramite riga di comando, con le funzioni che servono. In questo modo, pur non ottenendo uno script pesante meno di 70 KB, si evita di incorporarne uno da 250. Un esempio di come avvenga la procedura è possibile vederlo nel codice che segue.

npm install -g grunt-cli

git clone git://github.com/jquery/jquery.git

cd jquery
npm install

grunt custom --amd="custom-name"

grunt custom:-ajax,-deprecated,-effects,-wrap

grunt
grunt dist:./dist-custom-name/

jQuery Migrate

Nel 2013 oltre 1milione di siti implementavano jQuery. La versione 1.8 non era retrocompatibile con Internet Explorer 8 sugli elementi grafici. Si poneva quindi il problema su come snellire la libreria senza distruggere i siti prima citati. La soluzione fu elaborare jQuery Migrate che integrava le funzionalità sparite nelle nuove versioni. L’idea era quella di dare il tempo allo sviluppatore di scrivere il codice per garantire la cross compatibilità, così da poter togliere Migrate. Alla fine, però, oggi molti sviluppatori tengono assieme jQuery e jQuery Migrate.

Quando usare jQuery e quando no

Quando utilizzarlo

cose pronte

Esistono molti plugin di jQuery utili a fare tantissime cose. Solo per implementare le slide ce ne sono 172. È bene controllarne il funzionamento perché sono scritti da vari programmatori e non sono revisionati dalla community. Vanno utilizzati quando funzionano al 100%. Se quello che scarichiamo funziona per la maggior parte ma ci sono problemi conviene dirottare su qualcos’altro perché molto probabilmente si verificano altri malfunzionamenti oltre a quelli notati. Questi plugin sono scaricabili da jQuery Plugin Registry.

Nei cms e nei progetti dove è già integrato

Nei cms famosi per la costruzione di siti, come WordPress e Drupal, jQuery è già integrato. Stiamo parlando di una grande quantità di siti:

• con WordPress sono sviluppati oltre 18milioni di siti;
• Drupal è impiegato in oltre 700mila portali.

jQuery inoltre è presente in tutti i siti costruiti tra il 2008 e il 2012, prima dell’avvento di Angular.

WordPress è sponsor della jQuery Foundation e non toglierà mai questa libreria dal suo core. Il problema dei siti in WordPress è che ogni plugin installato contiene plugin di jQuery; al caricamento di una pagina si arriva a 3MB di script js. Ci sono plugin WordPress per fare il caricamento dinamico ma non costituiscono la soluzione ottimale al problema.

Anche Drupal implementa jQuery e infatti appartiene a quelle applicazioni create tra il 2008 e il 2012. Questo cms ha un plugin, jquery_update, per aggiornare jQuery fino alla 1.9. Il problema è che le versioni successive alla 1.8 non garantiscono la retrocompatibilità con l’area di amministrazione, quindi ci sono seri problemi di funzionamento. Chi si trova di fronte al fatto compiuto per la prima volta fatica a capirne la causa.

Trovare lavoro

Secondo una statistica Indeed all’inizio del 2016 erano ricercati tanti sviluppatori React quanto programmatori jQuery. Questo significa che dalle aziende è ancora molto ricercata la figura dello sviluppatore jQuery.

Semplicità d’uso

jQuery è molto semplice da capire e da usare; bastano 10 minuti per poter cominciare a utilizzarla nei propri progetti. Tuttavia bisogna fare attenzione a:

• Usare l’evento .ready() per caricare il proprio codice Js;
• Evitare lo spaghetti-code; viene definito così un codice non elegante e confusionario, composto da tante righe.

Quando è buona cosa evitarne l’utilizzo

Tanta manipolazione del DOM

Non è raro che, una volta finito il codice, il cliente chieda di aggiungere un’altra feature e che ciò crei problemi compromettenti il funzionamento dell’intero script. Meglio dirottare, in questo caso, su Angular e React

Quando c’è bisogno di prestazioni elevate

Un esperimento ha dimostrato le basse performance di jQuery. È stato fatto partire un ciclo for normale, nel quale, ad ogni iterazione, è stata eseguita una funzione che genera una nuova riga e la inserisce in una tabella, calcolando il tempo impiegato per eseguire l’intero ciclo. Il framework più lento nell’eseguire questa operazione è stato jQuery con 518 millisecondi impiegati, anche se è ignota la versione utilizzata. Qui sotto è possibile leggere i risultati dell’esperimento.

• DOM (Javascript puro) => 37,87 sec;
• React => 24,31 sec.;
• React JSX => 37,87 sec.;
• jQuery =>518 sec.;

Il test è stato eseguito su Firefox 53.0.0 su Mac OS X 10.12.0 .

Progetti complessi

Parliamo di progetti con:

• tanta iterazione con gli utenti – generazione di elementi dinamici;
• Molteplici funzionalità e classi;
• tanta logica Javascript.

Come non utilizzarlo

Da non usare come scusa

Spesso, nella pigrizia di implementare altre librerie, si sceglie jQuery poiché è già implementata, oppure perché non si vuole stare a scrivere altro codice. Se poi le performance non sono ottimali è così perché d’altro canto si è dovuto usare jQuery. Questa libreria va usata o no in base alle esigenze.

Conosco, quindi uso

Molti programmatori utilizzano jQuery perché non conoscono a fondo le feature di html e css. Invece è importante conoscere bene HTML5 e CSS3, saper fare una pagina responsive con breakpoint e implementare animazioni con le feature di CSS3.

Inoltre è importante saper scegliere la libreria giusta per ogni operazione. Per esempio jQuery non è molto indicata per la validazione di un form; esistono librerie molto più opportune per questo che facilitano di molto il lavoro e riducono il codice scritto. Inoltre, le ultime versioni di HTML hanno già delle feature che permettono di fare una buona validazione dei form.
A questo proposito è possibile leggere HTML 5.1: belle novità per pagine ancora più dinamiche e responsive.

Le conclusioni di Bisconti

Bisconti ha terminato l’intervento con alcune considerazioni.

jQuery, nonostante altre librerie si stanno rivelando più utili in alcuni frangenti, resisterà per almeno 10 anni; tutto dipende da come evolveranno gli altri framework e da come jQuery saprà stare al passo.

jQuery è bene utilizzarlo solamente quando serve: possibilmente va evitato su progetti grandi e complessi, mentre è bene utilizzarlo per servirsi dei plugin utili a fare cose particolari e per implementare tutto ciò per cui le altre librerie non sono adatte.

In buona sostanza nel 2017 jQuery è ancora attuale ma l’impiego nel proprio progetto va valutato caso per caso.

Gli interventi dei partecipanti

Terminato lo speech è giunto il momento delle domande dei partecipanti.

Uno è intervenuto dicendo che la sua azienda ha imposto l’utilizzo di jQuery per un sito di una banca che deve essere compatibile con Internet Explorer 8.
Un altro partecipante, stando nel tema, ha chiesto i tempi di estinzione di jQuery, considerato che Explorer 8 ormai è obsoleto e che non c’è più il supporto della Microsoft; Bisconti ha affermato che non morirà mai perché jQuery, attualmente, è implementata su oltre 20milioni di siti e che è un lavoro molto difficoltoso riscrivere tutti i plugin in modo che non siano basati su jQuery.

A questo proposito è intervenuto Davide Di Pumpo, membro dello staff organizzativo, affermando che il problema principale non stia nelle vecchie versioni di Explorer, bensì negli utenti che disabilitano Javascript. La percentuale stimata delle persone che hanno installato vecchie versioni di IE è sotto l’1%, mentre gli utenti che disabilitano Javascript arrivano all’1.5%; questa cifra potrebbe essere più bassa del reale poiché nella maggior parte dei casi non è possibile tracciare utenti con Javascript disabilitato, nel senso che il più diffuso sistema di tracciatura è Google Analytics che si serve di Javascript per fare questo.

È stato chiesto a Bisconti se lo speech è stato frutto di ricerca o di esperienza lavorativa. Bisconti ha risposto che lavora tutti i giorni su progetti Drupal e WordPress e che utilizza jQuery tutti i giorni. Su progetti piccoli e, sopratutto, laddove il cliente non voglia rifare l’infrastruttura continua a utilizzare jQuery. Mentre sui progetti più grossi cerca di introdurre gradualmente Angular e React per normalizzare una situazione disastrosa in termini di prestazioni.

Tornando all’eventuale scomparsa di jQuery Bisconti ha detto che per adesso nessun’altra libreria è riuscita a imporsi, pur essendocene state altre alternative come Zepto.js e jQuery Lite. Nell’ultima sono state eliminate dal codice tutte le parti che garantiscono la retrocompatibilità: il risultato è che solo le utlime versioni di Chrome, Firefox e Edge la supporta.

Un partecipante ha chiesto se il problema fosse la pigrizia dello sviluppatore, ma Bisconti ha risposto parlando di diversi sviluppatori che riscrivono i plugin di jQuery in Javascript puro, per poi creare dei wrapper che permettono a queste di girare con Angular e React. Pertanto è possibile reacarsi su GitHub, scaricare il file d’inclusione e vedere la direttiva o il modulo per qualsiasi libreria. Naturalmente non è possibile trovare questi wrapper per plugin in disuso.

jQuery resisterà per molto tempo

jQuery difficilmente, a mio parere, scomparirà del tutto. È vero che oggi ci sono ottime librerie alternative per compiere svariate operazioni, ma è bene fare alcune considerazioni:

• ci sono parecchi siti che devono garantire la retrocompatibilità con browser obsoleti e jQuery è la libreria meglio adatta allo scopo;
• è molto semplice da usare, pertanto gli sviluppatori meno esperti difficilmente dirotteranno su altre librerie, se non dopo un po’ di esperienza acquisita;
• jQuery è incorporata sui cms più utilizzati, come WordPress e Drupal;
• jQuery sta creando delle soluzioni per incorporare meno codice, come la possibilità di creare una propria versione personalizzata.

Queste considerazioni partono dallo stato attuale del mondo Javascript; tuttavia è vero che, sopratutto in ambito informatico, ogni tecnologia può diventare obsoleta da un momento all’altro:
non possiamo escludere che anche jQuery sia una di queste, ma, comunque, prima dell’uscita di scena definitiva, ci vorrà molto tempo.