Scegli una libreria o un framework JavaScript

Umar Hansa

Questo articolo fornisce informazioni su come scegliere una libreria o un framework da utilizzare all'interno della tua applicazione web. Le discussioni riportate di seguito ti aiuteranno a valutare i pro e i contro della scelta della libreria o del framework JavaScript più adatto al problema aziendale che stai cercando di risolvere. Capire quali pro e quali contro si applicano in situazioni diverse è fondamentale per valutare il vasto numero 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 già scritto che puoi chiamare nel codice del tuo progetto per eseguire un'attività specifica.

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

• Per 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 all'applicazione. Quando utilizzi una libreria, controlli il flusso dell'applicazione e scegli quando chiamarla.

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

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

Quando viene eseguito il metodo lodash.capitalize, viene chiamato il codice JavaScript precompilato che mette 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 puoi creare il comportamento della tua applicazione. In altre parole, quando utilizzi un framework, quest'ultimo controlla il flusso dell'applicazione. Per utilizzare un framework, scrivi il codice dell'applicazione personalizzata, 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, tieni presente che il framework ha molto più controllo sul codice che scrivi e, in alcuni casi, assume anche il controllo su quando eseguire il codice.

Perché utilizzare una libreria?

L'utilizzo di una libreria JavaScript può aiutare a evitare ripetizioni di codice non necessarie. Le librerie possono astrarre la logica complessa, ad esempio 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 consentono di ignorare 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.

Alcune librerie sono supportate da grandi aziende che investono tempo e denaro per mantenerle aggiornate e sicure. Molte librerie sono accompagnate da una documentazione esaustiva 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 consente di risparmiare tempo.

Perché dovresti preoccuparti dell'utilizzo della libreria?

Tecnicamente, puoi sviluppare la tua applicazione web da zero, ma perché complicarti la vita quando puoi utilizzare software gratuito (open source) o acquistare una soluzione che, a lungo termine, può farti risparmiare tempo e denaro? Esistono un gran numero di librerie e framework JavaScript disponibili, ognuno dei quali offre un approccio unico alla risoluzione dei problemi e presenta caratteristiche diverse. Ad esempio:

• Una libreria può essere scritta e gestita internamente anziché da terze parti.
• Una libreria può avere licenze legali specifiche che la rendono adatta o non adatta alla tua applicazione web.
• Una libreria può essere obsoleta o non sottoposta a manutenzione.
• Una libreria può semplificare un insieme 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ì difficile e puoi tranquillamente sostituire una raccolta 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 la necessità di un approccio più consapevole.

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

Esistono alcuni ambienti JavaScript non lato client, come sul server (eseguito in un ambiente cloud) o su 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 in un'applicazione web lato client non deve essere ignorato. Una libreria JavaScript di grandi dimensioni può interrompere il caricamento della pagina; ricorda che i millisecondi fanno milioni.

Nota: molte librerie JavaScript sono open source e non si può sottovalutare l'impegno dei relativi gestori: l'open source non è facile.

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

Più grande è la libreria JavaScript, maggiore sarà l'effetto sulle prestazioni degli utenti.

Durante la valutazione o l'utilizzo di una libreria o di un framework JavaScript, prendi in considerazione i seguenti suggerimenti per migliorare le prestazioni:

• Se hai una libreria JavaScript di grandi dimensioni, valuta la possibilità di utilizzare un'alternativa più piccola. Ad esempio, date-fns offre molte funzionalità a dimensioni più ragionevoli rispetto ad altre opzioni.
• Seguendo 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 ritardo di un secondo al tempo di caricamento della pagina (non dimenticare di limitare la rete e la CPU durante il test), potrebbe essere necessario rivalutare la libreria scelta. Oltre a controllare il caricamento della pagina, assicurati di eseguire il profiling di qualsiasi comportamento della pagina web che richiami il codice della libreria in questione: le prestazioni di caricamento della pagina non raccontano tutta la storia.
• Se l'autore della biblioteca accetta commenti, invia le tue osservazioni sulle prestazioni, i suggerimenti e perfino i contributi al progetto. È qui che eccelle la community open source. Se decidi di fare un contributo, potresti dover prima consultare il tuo datore di lavoro.
• Utilizza uno strumento di monitoraggio automatico dei bundle, come bundlesize, per rilevare aggiornamenti di dimensioni inaspettatamente elevate di una libreria. Capita spesso che una libreria JavaScript aumenti nel tempo. Aggiunte di funzionalità, correzioni di bug, casi limite e altro ancora, possono incrementare le dimensioni dei file di una libreria. Una volta che tu o il tuo team avete concordato di utilizzare una libreria, aggiornarla potrebbe non essere un problema e generare domande praticamente inesistenti. È qui che conviene fare affidamento sull'automazione.
• Esamina i requisiti per 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 di 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 intrinseci. Un pacchetto dannoso all'interno della base di codice dell'applicazione web può compromettere la sicurezza sia del team di sviluppo sia degli utenti.

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

Di seguito sono riportati alcuni suggerimenti per la sicurezza da considerare quando utilizzi o valuti codice di terze parti:

• Se utilizzi GitHub, valuta le offerte di sicurezza del codice, come Dependabot. In alternativa, valuta servizi alternativi che cercano vulnerabilità nel codice, come snyk.io.
• Prendi in considerazione l'utilizzo di servizi di controllo del codice, un team di tecnici in grado di controllare manualmente il codice di terze parti in uso.
• Valuta se bloccare le dipendenze a una versione specifica o eseguire il commit del codice di terze parti all'interno del controllo della versione. In questo modo puoi bloccare la dipendenza da una determinata versione, presumibilmente considerata sicura. Ironia della sorte, questo può avere un effetto contrario in termini di sicurezza, in quanto potresti perdere aggiornamenti vitali della libreria.
• Esamina la home page del progetto o la pagina GitHub, se esistente. 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 lato client basata su JavaScript, l'accessibilità web è di grande importanza.

Una libreria (o un framework) lato client basata su JavaScript può aumentare o diminuire l'accessibilità del tuo sito web. Prendi in considerazione una libreria JavaScript di terze parti che aggiunge a una pagina un dispositivo di scorrimento delle immagini. Se il cursore delle immagini non tiene conto dell'accessibilità web, gli sviluppatori web potrebbero trascurare una funzionalità così importante e rilasciare un prodotto a cui mancano funzionalità fondamentali, ad esempio il dispositivo di scorrimento che è 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 biblioteca. Questo cursore di immagini è un esempio particolare, ma prendi in considerazione altri esempi di librerie JavaScript:

• Il plug-in adattabile per la tipografia supporta gli utenti che aumentano o diminuiscono lo zoom della pagina?
• Il plug-in di caricamento dei file supporta i caricamenti di file da dispositivi per la disabilità?
• La raccolta di animazioni offre assistenza agli utenti che preferiscono animazioni ridotte?
• Il plug-in delle mappe interattive supporta l'utilizzo della sola tastiera?
• La raccolta di lettori audio offre un'esperienza appropriata sugli screen reader?

È ragionevole aspettarsi che tu, in qualità di sviluppatore web, debba intervenire in qualche modo per soddisfare questi requisiti di accessibilità. Ad esempio:

• Per eventuali funzionalità mancanti, puoi implementarle all'interno del codice di base, anche continuando a utilizzare la libreria in questione.
• Con l'aiuto del tuo datore di lavoro, puoi contribuire con una funzionalità mancante alla raccolta, se l'autore della raccolta lo consente.
• Puoi aprire una finestra di dialogo con l'autore della raccolta. Ad esempio, queste funzionalità di accessibilità specifiche sono previste nella tua roadmap? Sei d'accordo che appartengano alla biblioteca?
• Per i casi d'uso più comuni, puoi esplorare opzioni alternative di libreria che sono più accessibili; possono esistere, ma sono più difficili da trovare.
• In casi estremi, 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à degradata al primo utilizzo e devi annullare gran parte di ciò che la libreria o il framework ti offre gratuitamente.

Convenzioni

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

Se una libreria non segue convenzioni di codifica comuni (ad esempio, una guida di stile comune), non c'è molto che tu possa fare per risolvere immediatamente il problema. Tuttavia, ci sono ancora 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, potresti non avere nulla da temere.
• Se l'API della libreria non segue convenzioni di codifica comuni, puoi utilizzare un pattern di progettazione JavaScript, come il pattern proxy, per eseguire il wrapping di tutte le interazioni con la libreria in un singolo file del codebase e utilizzarlo. Il proxy può quindi offrire un'API più intuitiva ad altre parti del codice all'interno della base di codice.

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

Aggiornamenti

Ad esempio, una libreria completamente funzionante che esegue alcuni calcoli matematici potrebbe raramente richiedere aggiornamenti. Anzi, una libreria completa di funzionalità è una rara scoperta nel mondo in continua evoluzione dello sviluppo web. Tuttavia, in alcuni casi è possibile che l'autore della raccolta sia reattivo e disposto ad apportare aggiornamenti. Nuove ricerche e risultati possono rivelare modi migliori per svolgere le attività, pertanto le tecniche utilizzate in librerie e 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 interessarti:

• La raccolta ha una programmazione delle uscite sensata? Ad esempio, gli aggiornamenti del repository del codice sorgente possono verificarsi di frequente, ma se questi aggiornamenti non vengono "pubblicati" o "rilasciati" di conseguenza, potresti riscontrare difficoltà a scaricarli.
• La libreria rilascia aggiornamenti con uno schema di versionamento del software sensato? Una raccolta dovrebbe farti risparmiare tempo. Se devi modificare inaspettatamente il codice ogni volta che aggiorni la versione della libreria, potresti svuotare lo scopo dell'utilizzo della libreria. A volte le modifiche incompatibili sono inevitabili, ma in un mondo ideale le modifiche sono rare e non forzate agli utenti della raccolta.
• La libreria si impegna per la compatibilità con le versioni precedenti? A volte, gli aggiornamenti software possono comportare modifiche che non sono compatibili con le versioni precedenti, ma forniscono anche un livello di retrocompatibilità. In questo modo, l'utente della libreria può utilizzare la versione più recente della libreria con modifiche minime al codice.

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

Licenze

Avviso: questo non è un parere legale.

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

Ad esempio, una libreria JavaScript potrebbe avere una licenza software che ti consente di utilizzarla in un ambiente non commerciale. Per un progetto hobby personale, 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, ti consigliamo di rivolgerti a un consulente legale o al team legale della tua azienda.

Community

Una libreria o un framework con una vasta community di utenti/collaboratori può essere utile, ma non è una garanzia. In generale, più utenti utilizzano una libreria o un framework, più è probabile che ne trarranno vantaggio. Valuta i seguenti pro e contro della partecipazione a una community di sviluppo:

Pro:

• Una base utenti ampia potrebbe significare maggiori probabilità di rilevare i bug in anticipo e di frequente.
• Una grande community attiva può includere altri tutorial, guide, video e persino corsi relativi alla libreria o al framework in questione.
• Una grande community attiva può offrire maggiore supporto sui forum e sui siti web di domande e risposte, aumentando la probabilità che le domande di assistenza ricevano risposta.
• Una community coinvolta può significare più collaboratori esterni per la raccolta o il framework. Possono contribuire a fornire funzionalità che altrimenti non sono presenti nella roadmap dell'autore.
• Quando una libreria o un framework è popolare all'interno di una community, è più probabile che i tuoi colleghi e coetanei ne abbiano sentito parlare o che addirittura la conoscano.

Contro:

• Un progetto con una base utenti ampia e diversificata può gonfiarsi a causa dell'aggiunta costante di funzionalità. Le librerie gonfie possono danneggiare le prestazioni del web.
• Un progetto con una community attiva e coinvolta può essere stressante per autori e gestori e può richiedere un'elevata moderazione.
• Un progetto che cresce rapidamente, ma non dispone del supporto appropriato, può iniziare a mostrare i 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 sviluppo web è davvero fantastica. Ogni community ha i suoi problemi, ma non dovresti sentirti dissuaso dal interagire con una community in particolare in base a ciò che leggi qui. Può essere particolarmente difficile per un nuovo sviluppatore web sentirsi parte di una community, soprattutto quelle con punti di vista polarizzanti. Tieni presente che si tratta di una sfida comune all'interno della community web e che è un'area in cui è necessaria una conversazione più aperta.

Documentazione

Indipendentemente da quanto semplice o complesso sia un framework o una libreria JavaScript, la documentazione del software può sempre essere utile. Anche gli sviluppatori molto esperti utilizzano la documentazione anziché capire autonomamente il codice. La documentazione chiarisce l'API da utilizzare e come utilizzarla.

La documentazione può anche fornire codice campione, consentendoti di iniziare più facilmente. 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 autonomamente.
• La documentazione è chiara, facile da capire e priva di ambiguità? Molti sviluppatori dedicano molto tempo alla documentazione. Potrebbe sembrare poco importante, ma la chiarezza della documentazione testuale può avere un grande impatto sulla tua produttività.
• La documentazione viene generata completamente automaticamente? Questa documentazione può essere più difficile da assimilare e non sempre fornisce indicazioni chiare su come utilizzare un'API.
• La documentazione è aggiornata? La manutenzione della documentazione a volte viene trattata come un ripensamento. Se la libreria viene aggiornata, ma non la documentazione, il tempo di sviluppo potrebbe essere sprecato.
• La documentazione è completa e disponibile in più formati? Guide per l'utente, codice di esempio, documentazione di riferimento, demo dal vivo e tutorial sono tutti formati di documentazione utili che possono aiutarti a utilizzare correttamente una libreria o un framework.

La documentazione non può essere sempre completa, e va bene così. 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 di cui hai bisogno.

Conclusione

È normale sentirsi sopraffatti quando si sceglie una libreria o un framework per la prima volta. Come per tutto il resto, più impari e pratichi un'attività, più diventi bravo. Ti consigliamo di fare riferimento a questo post la prossima volta che dovrai scegliere una libreria o un framework da utilizzare. Puoi utilizzare le intestazioni di questo post come elenco di controllo. Ad esempio: "Questa libreria ha un buon rendimento?" Questa libreria soddisfa gli standard della mia attività per l'accessibilità web?

Ci sono altri aspetti delle librerie e dei framework che ti consigliamo di prendere in considerazione, ma che non sono stati trattati in modo approfondito in questo post:

• Estensione: quanto è facile estendere la libreria con logica e/o comportamento personalizzati?
• Strumenti:se applicabile, la libreria dispone di strumenti come plug-in per 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 indicano che la suite di test sta superando il test rispetto all'ultimo commit?
• Compatibilità: la libreria funziona bene con altre librerie e/o altri framework che stai attualmente utilizzando?
• Costo: qual è il costo di un framework? È open source o disponibile per l'acquisto?
• Metriche di vanità: queste dovrebbero essere in fondo all'elenco dei criteri o addirittura ignorate del tutto, ma ti consigliamo di prendere in considerazione i "voti" del progetto, gli account di social media che rappresentano il progetto e/o il numero di bug/problemi aperti nella pagina del progetto.