Scegli una libreria o un framework JavaScript

Umar Hansa
Umar Hansa

Questo articolo fornisce approfondimenti su come scegliere una libreria o un framework da utilizzare all'interno dell'applicazione web. Le discussioni riportate di seguito 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. Capire quali pro e quali contro si applicano in situazioni diverse è fondamentale per valutare il vasto numero di librerie JavaScript disponibili.

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

Questo post menziona principalmente "librerie". Tuttavia, molte delle discussioni sono applicabili anche ai framework. 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, è il framework a controllare 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ò aiutarti a evitare la ripetizione del codice non necessaria. 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 completa, che offre a te e al tuo team un modo rapido per acquisire familiarità con l'utilizzo della libreria.

In definitiva, l'utilizzo di una libreria JavaScript ti fa 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 senza costi (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 gestita.
  • 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ì complessa e puoi sostituire una raccolta in tutta sicurezza se non ti piace. Tuttavia, a volte una libreria può avere un effetto significativo sul tuo lavoro e sulla tua applicazione web, il che suggerisce che potrebbe essere necessario un approccio più informato.

Esistono alcuni ambienti JavaScript lato server, 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 sul rendimento di una libreria JavaScript su un'applicazione web lato client non deve essere ignorato. Una libreria JavaScript di grandi dimensioni può influire negativamente sul rendimento del caricamento della pagina. Ricorda che i millisecondi fanno milioni.

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.

Maggiore è la libreria JavaScript, maggiore è l'impatto sul rendimento per gli utenti.

Quando valuti o utilizzi una libreria o un framework JavaScript, prendi in considerazione 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à 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 libreria accetta i commenti, invia le tue osservazioni sul rendimento, i tuoi suggerimenti e persino i tuoi contributi al progetto. Ed è qui che la community open source dà il meglio di sé. 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. È normale che una libreria JavaScript cresca nel tempo. Aggiunta di funzionalità, correzione di bug, casi limite e altro ancora possono aumentare le dimensioni del file di una raccolta. Una volta che tu o il tuo team avete deciso di utilizzare una libreria, l'aggiornamento potrebbe non essere un problema e potrebbe non sollevare domande. È qui che è utile affidarsi all'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. 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 del genere 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.
  • 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 devi bloccare le dipendenze a una versione specifica o eseguire il commit del codice di terze parti nel 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 un cursore di immagini a una pagina. Se il cursore delle immagini non tiene conto dell'accessibilità web, tu, in qualità di sviluppatore web, potresti trascurare una funzionalità così importante e rilasciare un prodotto che non dispone di funzionalità essenziali, ad esempio la possibilità di navigare nel cursore con la tastiera.

  • Il plug-in di tipografia adattabile 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 solo con tastiera?
  • La raccolta di player 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 di librerie alternative più accessibili; potrebbero esistere, ma sono più difficili da trovare.
  • In casi estremi, potrebbe essere necessario abbandonare completamente una libreria e implementare le funzionalità da zero. Ciò 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 senza costi.

Convenzioni

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

Se una libreria non segue convenzioni di codifica comuni (ad esempio una guida di stile comune), non c'è molto che puoi fare per una correzione immediata. 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 racchiudere e contenere tutte le interazioni con la libreria in un unico file nella base di codice. 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. Infatti, una libreria completa di funzionalità è una scoperta rara nel mondo in continua evoluzione dello sviluppo web. Tuttavia, a volte è necessario che l'autore della libreria sia reattivo e disponibile ad apportare aggiornamenti. Nuove ricerche e risultati possono rivelare modi migliori per fare le cose, quindi 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 influire su:

  • 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 minare lo scopo stesso 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.

Licenze

La licenza del software è un aspetto importante dell'utilizzo di librerie software di terze parti. L'autore di una raccolta può assegnare una licenza alla raccolta. 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 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 potrebbe significare più tutorial, guide, video e persino corsi sulla libreria o sul framework in questione.
  • Una grande community attiva potrebbe significare un maggiore supporto sui forum e sui siti web di domande e risposte, aumentando la probabilità che le domande di assistenza vengano risposte.
  • Una community coinvolta può significare più collaboratori esterni alla libreria o al 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ò diventare ingombrante 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 gli autori e i manutentori e può richiedere una moderazione della community molto intensa.
  • 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.

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 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 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ò sempre essere 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 è efficiente? Questa libreria soddisfa gli standard della mia attività per l'accessibilità web?

Esistono altri aspetti di librerie e framework che potresti prendere in considerazione e che non sono stati ampiamente discussi 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 framework che stai 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.