Scegli una libreria o un framework JavaScript

Umar Hansa

Questo articolo condivide approfondimenti su come scegliere una libreria o un framework da utilizzare all'interno della tua applicazione web. Le discussioni qui riportate ti aiuteranno a valutare i pro e i contro per trovare la libreria o il framework JavaScript più adatto al problema aziendale che stai cercando di risolvere. Comprendere quali pro e quali contro si applicano alle diverse situazioni è fondamentale per valutare l'ampia gamma di librerie JavaScript disponibili.

Che cosa sono le librerie e i framework JavaScript

Che cos'è una libreria JavaScript? Nella sua forma più semplice, una libreria JavaScript è un codice precompilato che puoi richiamare nel codice del tuo progetto per eseguire un'attività specifica.

Questo post menziona principalmente le "librerie". Tuttavia, molte delle discussioni sono applicabili anche ai framework. In sostanza, la differenza tra i due può essere riassunta come segue:

• Nel caso di una libreria, il codice dell'applicazione chiama il codice della libreria.
• Per un framework, il codice dell'applicazione viene chiamato dal framework.

I seguenti esempi pratici aiutano a illustrare le differenze.

Esempio di chiamata a una libreria JavaScript

Una libreria JavaScript esegue un'attività specifica e poi restituisce il controllo alla tua applicazione. Quando utilizzi una libreria, controlli il flusso dell'applicazione e scegli quando chiamare la libreria.

Nell'esempio seguente, il codice dell'applicazione importa un metodo dalla libreria lodash. Al termine della funzione, il controllo viene restituito alla tua applicazione.

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

Quando viene eseguito il metodo lodash.capitalize, viene chiamato il codice JavaScript pre-scritto che scrive in maiuscolo il primo carattere di una stringa.

Esempio di utilizzo di un framework JavaScript

Un framework JavaScript è un modello di codice predefinito all'interno del quale crei il comportamento della tua applicazione. In altre parole, quando utilizzi un framework, questo controlla il flusso dell'applicazione. Per utilizzare un framework, scrivi il codice dell'applicazione personalizzato, che viene poi chiamato dal framework.

Il seguente esempio mostra uno snippet di codice che utilizza il framework JavaScript Preact:

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

Nell'esempio, nota che il framework ha un controllo molto maggiore sul codice che scrivi e, in alcuni casi, il framework assume persino il controllo su quando eseguire il codice.

Perché utilizzare una libreria?

L'utilizzo di una libreria JavaScript può aiutare a evitare inutili ripetizioni di codice. Le librerie possono astrarre logiche complesse, come la manipolazione delle date o i calcoli finanziari. Una libreria può anche aiutarti a lanciare il tuo prodotto iniziale, invece di dover scrivere tutto il codice da zero, il che può richiedere tempo.

Alcune librerie JavaScript lato client aiutano ad astrarre le peculiarità della piattaforma web. Una biblioteca può anche fungere da strumento di apprendimento. Ad esempio, se non hai dimestichezza con le funzioni di easing delle animazioni, il codice sorgente di una libreria può insegnarti come funzionano questi easing.

Alcune librerie sono supportate da grandi aziende che investono tempo e denaro per mantenerle aggiornate e sicure. Molte librerie sono accompagnate da una documentazione completa, che offre a te e al tuo team un modo rapido per familiarizzare con l'utilizzo della libreria.

In definitiva, l'utilizzo di una libreria JavaScript ti fa risparmiare tempo.

Perché dovrebbe interessarti l'utilizzo della libreria?

Tecnicamente, puoi sviluppare la tua applicazione web da zero, ma perché darsi tanta pena quando puoi utilizzare un software senza costi (open source) o acquistare una soluzione che, nel lungo periodo, può farti risparmiare tempo e denaro? Esiste un gran numero di librerie e framework JavaScript, ognuno dei quali offre un approccio unico alla risoluzione dei problemi e ha caratteristiche diverse. Ad esempio:

• Una libreria può essere scritta e gestita internamente anziché da una terza parte.
• Una libreria può avere licenze legali specifiche che la rendono adatta o meno alla tua applicazione web.
• Una libreria può essere obsoleta o non gestita.
• Una libreria può semplificare una serie di attività complesse e farti risparmiare molto tempo e denaro.
• Una libreria può essere ampiamente utilizzata nella community ed essere ben nota tra gli sviluppatori.

Come puoi immaginare, caratteristiche diverse possono influire sulla tua applicazione web in modi diversi. A volte, la decisione non è così complessa e puoi tranquillamente sostituire una libreria se non ti piace. Tuttavia, a volte una libreria può avere un impatto significativo sul tuo lavoro e sulla tua applicazione web, il che suggerisce che potrebbe essere necessario un approccio più informato.

Punto chiave: molti dei punti sollevati nella sezione seguente sulle prestazioni, nonché i punti sollevati in questo articolo, sono applicabili agli ambienti lato client. Il codice lato client viene eseguito sul dispositivo dell'utente finale, ad esempio tramite il suo browser web.

Esistono alcuni ambienti JavaScript non lato client, ad esempio sul server (eseguiti in un ambiente cloud) o su un Raspberry Pi, in cui potrebbe essere necessario modificare i criteri utilizzati per esaminare librerie e framework.

Prestazioni

L'effetto sulle prestazioni di una libreria JavaScript su un'applicazione web lato client non deve essere ignorato. Una libreria JavaScript di grandi dimensioni può compromettere le prestazioni di caricamento della pagina. Ricorda che i millisecondi fanno i milioni.

Nota: molte librerie JavaScript sono open source e gli sforzi dei gestori delle librerie non possono essere sopravvalutati: l'open source non è facile.

Considera uno scenario in cui utilizzi una libreria JavaScript per l'animazione. Alcune librerie possono facilmente aggiungere decine di kilobyte e, in alcuni casi, anche centinaia di kilobyte. Risorse JavaScript come questa possono aggiungere un ritardo significativo al caricamento della pagina, poiché il browser deve scaricare, analizzare, compilare ed eseguire il codice.

Più grande è la libreria JavaScript, maggiore è l'effetto sul rendimento per gli utenti.

Quando valuti o utilizzi una libreria o un framework JavaScript, tieni presente i seguenti suggerimenti per migliorare il rendimento:

• Se hai una libreria JavaScript di grandi dimensioni, valuta la possibilità di utilizzare un'alternativa più piccola. Ad esempio, date-fns offre molte funzionalità con dimensioni più ragionevoli rispetto ad altre opzioni.
• Continuando con l'esempio precedente di date-fns, importa solo le funzioni di cui hai bisogno, ad esempio: import { format } from 'date-fns'. Assicurati di combinare questo approccio con il tree shaking, in modo da creare e inviare agli utenti un payload JavaScript minimo.
• Utilizza strumenti di test delle prestazioni come Lighthouse per osservare l'effetto sulle prestazioni dell'utilizzo di una determinata libreria JavaScript. Se una libreria aggiunge un secondo al tempo di caricamento della pagina (non dimenticare di limitare la rete e la CPU durante i test), potresti dover rivalutare la libreria scelta. Oltre a controllare il caricamento pagina, assicurati di profilare qualsiasi comportamento della pagina web che richiama il codice della libreria in questione: le prestazioni di caricamento pagina non dicono tutto.
• Se l'autore della libreria accetta i commenti, invia le tue osservazioni sul rendimento, i tuoi suggerimenti e persino i tuoi contributi al progetto. È qui che la community open source dà il meglio di sé. Se decidi di dare un contributo, potresti dover prima consultare il tuo datore di lavoro.
• Utilizza uno strumento di monitoraggio automatico dei bundle, come bundlesize, per controllare se sono presenti aggiornamenti di dimensioni impreviste in una libreria. È normale che una libreria JavaScript cresca nel tempo. L'aggiunta di funzionalità, la correzione di bug, i casi limite e altri fattori possono aumentare le dimensioni del file di una libreria. Una volta che tu o il tuo team avete accettato di utilizzare una libreria, l'aggiornamento della libreria potrebbe essere meno problematico e sollevare poche o nessuna domanda. In questo caso, è utile affidarsi all'automazione.
• Esamina i requisiti di una libreria e valuta se la piattaforma web offre o meno la stessa funzionalità in modo nativo. Ad esempio, la piattaforma web offre già un selettore colori, che elimina la necessità di utilizzare una libreria JavaScript di terze parti per implementare la stessa funzionalità.

Sicurezza

L'utilizzo di un modulo di terze parti comporta alcuni rischi per la sicurezza. Un pacchetto dannoso all'interno del codebase della tua applicazione web può compromettere la sicurezza sia del tuo team di sviluppo sia dei tuoi utenti.

Prendi in considerazione una libreria pubblicata nell'ecosistema NPM. Un pacchetto di questo tipo potrebbe essere legittimo. Tuttavia, nel tempo, il pacchetto può essere compromesso.

Ecco alcuni suggerimenti per la sicurezza da tenere in considerazione quando utilizzi o valuti il codice di terze parti:

• Se utilizzi GitHub, prendi in considerazione le offerte di sicurezza del codice, come Dependabot. In alternativa, prendi in considerazione servizi alternativi che analizzano le vulnerabilità nel tuo codice, come snyk.io.
• Valuta la possibilità di utilizzare servizi di controllo del codice, un team di ingegneri che può controllare manualmente il codice di terze parti che utilizzi.
• Valuta se bloccare le dipendenze su una versione specifica o eseguire il commit del codice di terze parti nel controllo della versione. In questo modo, puoi bloccare la dipendenza su una versione specifica, che si presume sia considerata sicura. Ironia della sorte, questo può avere un effetto contrario sulla sicurezza, in quanto potresti perdere aggiornamenti vitali della libreria.
• Esamina la home page del progetto o la pagina GitHub, se esiste. Verifica se esistono problemi di sicurezza in sospeso e se i problemi di sicurezza precedenti sono stati risolti entro un periodo di tempo ragionevole.
• Il codice di terze parti che utilizza altro codice di terze parti può comportare un rischio maggiore rispetto a una libreria con zero dipendenze. Tieni presente questo rischio.

Accessibilità

Forse ti starai chiedendo in che modo le librerie software sono correlate all'accessibilità web. Sebbene una libreria software possa essere utilizzata in ambienti diversi, nel contesto di una libreria basata su JavaScript lato client, l'accessibilità web è di fondamentale importanza.

Una libreria (o un framework) basata su JavaScript lato client può aumentare o diminuire l'accessibilità del tuo sito web. Prendi in considerazione una libreria JavaScript di terze parti che aggiunge uno slider di immagini a una pagina. Se lo slider di immagini non tiene conto dell'accessibilità web, tu, in qualità di sviluppatore web, potresti trascurare una funzionalità così importante e rilasciare un prodotto privo di funzionalità fondamentali, come lo slider navigabile da tastiera.

Nota: nell'esempio precedente, è responsabilità dello sviluppatore web che crea il sito web assicurarsi di utilizzare librerie adatte allo scopo. Non è responsabilità dell'autore della libreria. Questo dispositivo di scorrimento delle immagini è un esempio particolare, ma considera altri esempi di librerie JavaScript:

• Il plug-in di tipografia adattabile supporta gli utenti che aumentano o diminuiscono lo zoom della pagina?
• Il plug-in per il caricamento di file supporta i caricamenti di file da dispositivi con l'assistente?
• La libreria di animazioni offre supporto per gli utenti che preferiscono un movimento ridotto?
• Il plug-in delle mappe interattive supporta l'utilizzo solo da tastiera?
• La libreria del lettore audio offre un'esperienza appropriata sugli screen reader?

È ragionevole aspettarsi che sia necessario un certo livello di coinvolgimento da parte tua, in qualità di sviluppatore web, per soddisfare questi requisiti di accessibilità. Ad esempio:

• Per le funzionalità mancanti, puoi implementarle all'interno del tuo codebase, anche continuando a utilizzare la libreria in questione.
• Con il supporto del tuo datore di lavoro, puoi contribuire alla libreria con la funzionalità mancante, se l'autore della libreria lo consente.
• Puoi avviare un dialogo con l'autore della libreria. Ad esempio, queste funzionalità di accessibilità specifiche sono presenti nella tua roadmap? Sei d'accordo che appartengano alla raccolta?
• Per i casi d'uso più comuni, puoi esplorare opzioni di librerie alternative più accessibili, che potrebbero esistere ma essere più difficili da trovare.
• Nel caso estremo, potrebbe essere necessario abbandonare completamente una libreria e implementare le funzionalità da zero. Questo può accadere quando una libreria o un framework ha un'esperienza di accessibilità ridotta al primo utilizzo e devi annullare gran parte di ciò che la libreria o il framework dovrebbe fornirti senza costi.

Convention

È più facile lavorare con una libreria software che utilizza convenzioni di programmazione consolidate. Se una libreria utilizza una convenzione di programmazione sconosciuta, potrebbe essere difficile per te e il tuo team lavorare con questa libreria.

Se una libreria non segue le convenzioni di programmazione comuni (ad esempio, una guida di stile comune), non puoi fare molto per risolvere il problema immediatamente. Tuttavia, sono ancora disponibili alcune opzioni:

• Assicurati di distinguere tra il codice sorgente della libreria e l'API esposta a te, l'utente della libreria. Anche se il codice sorgente interno potrebbe utilizzare convenzioni non familiari, se l'API (la parte della libreria con cui interagisci) utilizza convenzioni familiari, potrebbe non esserci nulla di cui preoccuparsi.
• Se l'API della libreria non segue le convenzioni di programmazione comuni, puoi utilizzare un pattern di progettazione JavaScript, come il pattern proxy, per aggregare e contenere tutte le interazioni con la libreria in un unico file nel codebase. Il proxy può quindi offrire un'API più intuitiva ad altre parti del codice all'interno del codebase.

Le convenzioni svolgono un ruolo importante per la facilità d'uso. Una libreria che include un'API intuitiva può far risparmiare molte ore, o addirittura giorni, di lavoro rispetto a un'API controintuitiva che richiede molta sperimentazione per essere compresa.

Aggiornamenti

Ad esempio, una libreria completamente funzionante che esegue alcuni calcoli matematici potrebbe richiedere raramente aggiornamenti. In effetti, una libreria completa di funzionalità è una rarità nel mondo in continua evoluzione dello sviluppo web. Tuttavia, a volte è necessario che l'autore della libreria sia reattivo e disposto ad apportare aggiornamenti. Nuove ricerche e scoperte possono rivelare modi migliori di fare le cose, quindi le tecniche utilizzate nelle librerie e nei framework sono sempre soggette a modifiche.

Quando scegli una libreria o un framework, presta attenzione a come vengono gestiti gli aggiornamenti e tieni presente che queste decisioni possono influire su di te:

• La libreria ha un programma delle pubblicazioni ragionevole? Ad esempio, gli aggiornamenti al repository di codice sorgente possono avvenire di frequente, ma se non vengono "pubblicati" o "rilasciati" di conseguenza, potresti avere difficoltà a scaricarli.
• La libreria rilascia aggiornamenti con uno schema di controllo delle versioni del software sensato? Una libreria dovrebbe farti risparmiare tempo. Se devi modificare inaspettatamente il codice ogni volta che aggiorni la versione della libreria, lo scopo di utilizzare quella libreria potrebbe essere vanificato. Le modifiche che provocano un errore a volte sono inevitabili, ma in un mondo ideale sono rare e non vengono imposte ai consumer della libreria.
• La libreria investe risorse per la compatibilità con le versioni precedenti? A volte, gli aggiornamenti software possono comportare modifiche che provocano un errore, ma forniscono anche un livello di compatibilità con le versioni precedenti. In questo modo, il consumer della libreria può utilizzare l'ultima versione della libreria con modifiche minime al codice.

Nota: gli autori e i gestori delle librerie investono molto tempo per supportare gli sviluppatori web. Non è sempre pratico per l'autore di una libreria fornire aggiornamenti nei modi descritti in precedenza. Ad esempio, gli autori di librerie indipendenti che lavorano su progetti open source potrebbero non ricevere nemmeno il supporto finanziario di cui hanno bisogno per stare al passo con le esigenze del progetto.

Licenze

Avviso: questo articolo non costituisce una consulenza legale.

Le licenze software sono un aspetto importante dell'utilizzo di librerie software di terze parti. L'autore di una libreria può assegnare una licenza alla propria libreria. Se stai valutando di utilizzare la libreria, la scelta della licenza potrebbe interessarti.

Ad esempio, una libreria JavaScript potrebbe avere una licenza software che ne consente l'utilizzo in un ambiente non commerciale. Per un progetto personale, questa potrebbe essere un'ottima scelta. Se il tuo progetto ha un elemento commerciale, potresti dover prendere in considerazione una licenza aziendale.

In caso di dubbi, rivolgiti a un consulente legale professionista o al team legale della tua azienda.

Community

Una libreria o un framework con una grande community di utenti/collaboratori può essere utile, ma non è una garanzia. In generale, maggiore è il numero di utenti di una libreria o di un framework, maggiore è la probabilità che ne tragga vantaggio. Considera i seguenti pro e contro della partecipazione a una community di sviluppo:

Pro:

• Una base utenti di grandi dimensioni potrebbe significare una maggiore probabilità che i bug vengano rilevati in anticipo e spesso.
• Una community attiva di grandi dimensioni potrebbe significare più tutorial, guide, video e persino corsi sulla libreria o sul framework in questione.
• Una community attiva di grandi dimensioni potrebbe significare un maggiore supporto sui forum e sui siti web di domande e risposte, aumentando la probabilità che le domande di assistenza ricevano una risposta.
• Una community coinvolta può significare più collaboratori esterni alla libreria o al framework. Possono contribuire a fornire funzionalità che altrimenti non rientrerebbero nella roadmap dell'autore.
• Quando una libreria o un framework è popolare all'interno di una community, è più probabile che i tuoi colleghi ne abbiano sentito parlare o che abbiano persino familiarità con questa libreria o questo framework.

Contro:

• Un progetto con una base utenti ampia e diversificata può diventare troppo complesso a causa della continua aggiunta di funzionalità. Le librerie troppo grandi possono influire negativamente sulle prestazioni web.
• Un progetto con una community attiva e coinvolta può essere stressante per gli autori e i gestori e potrebbe richiedere una moderazione della community molto intensa.
• Un progetto che cresce rapidamente, ma non dispone del supporto adeguato, può iniziare a mostrare segni di una community tossica. Ad esempio, gli sviluppatori web principianti o junior possono sentirsi non benvenuti in una determinata community a causa del gatekeeping.

Nota: la community di sviluppatori web è di gran lunga meravigliosa. Ogni community ha le sue difficoltà, ma non dovresti farti scoraggiare dal partecipare a una determinata community in base a ciò che leggi qui. Per un nuovo sviluppatore web può essere particolarmente difficile sentirsi parte di una community, soprattutto di quelle con opinioni polarizzanti. Devi sapere che si tratta di una sfida comune all'interno della community web e di un'area in cui è necessaria una discussione più aperta.

Documentazione

Indipendentemente dalla semplicità o dalla complessità di una libreria o di un framework JavaScript, la documentazione del software può sempre essere d'aiuto. Anche gli sviluppatori più esperti utilizzano la documentazione, anziché capire il codice da soli. La documentazione chiarisce l'API da utilizzare e come utilizzarla.

La documentazione può anche fornire un codice campione, semplificando l'avvio rapido. Quando valuti una libreria o un framework, puoi porti alcune di queste domande:

• La libreria include la documentazione? In caso contrario, dovrai essere in grado di risolvere i problemi in autonomia.
• La documentazione è chiara, facile da capire e priva di ambiguità? Molti sviluppatori dedicano molto tempo alla documentazione. Può sembrare un dettaglio, ma la chiarezza della documentazione testuale può avere un grande impatto sulla tua produttività.
• La documentazione viene generata in modo completamente automatico? Questa documentazione può essere più difficile da comprendere e non sempre fornisce indicazioni chiare su come utilizzare un'API.
• La documentazione è aggiornata? La manutenzione della documentazione a volte viene trattata come un'attività secondaria. Se la libreria viene aggiornata, ma la documentazione no, questo può comportare una perdita di tempo per lo sviluppo.
• La documentazione è completa e disponibile in più formati? Guide dell'utente, codice campione, documentazione di riferimento, demo dal vivo e tutorial sono tutti formati di documentazione preziosi che possono aiutarti a utilizzare correttamente una libreria o un framework.

La documentazione non può essere sempre completa, ma non è un problema. Dovrai valutare le esigenze della tua organizzazione, i requisiti del progetto e la complessità del software e utilizzare queste informazioni per determinare il livello di documentazione necessario.

Conclusione

È normale sentirsi sopraffatti quando si sceglie una libreria o un framework per la prima volta. Come per qualsiasi altra cosa, più impari e ti eserciti in un'attività, più diventi bravo. Potrebbe essere utile fare riferimento a questo post la prossima volta che sceglierai una libreria o un framework da utilizzare. Puoi utilizzare le intestazioni di questo post come elenco di controllo. Ad esempio: "Questa libreria è efficiente?" Questa libreria soddisfa gli standard della mia attività per l'accessibilità web?

Ci sono altri aspetti delle librerie e dei framework che potresti voler prendere in considerazione e che non sono stati discussi in modo approfondito in questo post:

• Estendibilità: quanto è facile estendere la libreria con logica e/o comportamento personalizzati?
• Strumenti: se applicabile, la libreria dispone di strumenti come plug-in per l'editor di codice, strumenti di debug e plug-in per il sistema di build?
• Architettura: il codice pulito è importante, ma l'architettura complessiva della libreria è sensata?
• Test: il progetto ha una suite di test? Il sito web del progetto utilizza badge o indicatori che la suite di test sta superando rispetto all'ultimo commit?
• Compatibilità: la libreria funziona bene con altre librerie e/o framework che stai utilizzando?
• Costo: qual è il costo di un framework? È open source o disponibile per l'acquisto?
• Metriche di vanità: dovrebbero essere in fondo alla lista dei criteri o addirittura ignorate del tutto, ma potresti prendere in considerazione i "voti" del progetto, gli account dei social media che rappresentano il progetto e/o il numero di bug/problemi aperti nella pagina del progetto.