Differenza tra librerie e framework JavaScript

Umar Hansa

Questo articolo illustra le differenze tra framework e librerie nel contesto di un ambiente JavaScript lato client, ossia il codice che viene eseguito nel browser web. Tuttavia, alcuni dei punti sollevati in questo articolo si applicano anche ad altri ambienti, perché le librerie e i framework fanno parte di molti campi di ingegneria del software, come lo sviluppo di app mobile native.

Le discussioni in questo post si concentrano sulle differenze qualitative piuttosto che sulle differenze quantitative tra librerie e quadri normativi. Ad esempio:

• Quantitativo: i framework in genere aderiscono al principio dell'inversione del controllo.
• Qualitativo: l'esperienza del quadro di riferimento può attirare maggiormente i futuri datori di lavoro quando cercano lavoro.

Perché saperne di più su librerie e framework?

L'utilizzo della libreria JavaScript e del framework è prolifico in tutto il web. Tutti gli altri siti web sembrano utilizzare codice di terze parti nelle proprie risorse JavaScript. Il peggior peso delle pagine web con il passare del tempo influisce sugli utenti. JavaScript è un fattore determinante per il peso complessivo della pagina ed è lo stesso JavaScript che spesso comprende librerie e framework di terze parti.

Non è abbastanza positivo dire "Smetti di usare i framework JavaScript", perché i framework forniscono un grande vantaggio agli sviluppatori. I framework possono aiutarti a programmare in modo efficiente e fornire funzionalità rapidamente, oltre ad altri vantaggi. Dovresti, invece, istruirti in modo da poter prendere una decisione consapevole al momento opportuno.

"Dovrei usare una biblioteca o un modello oggi?" è una domanda insolita che ti viene posta. Librerie e framework sono due cose molto diverse. Tuttavia, librerie e framework sono spesso confusi e maggiore è la tua conoscenza dei due, più è probabile che tu prenda decisioni consapevoli sul loro utilizzo.

Esempi di librerie e framework

Potresti notare il codice di terze parti con altri nomi, ad esempio widget, plug-in, polyfill o pacchetti. Tuttavia, generalmente tutti rientrano nella categoria di una libreria o di un framework. In sostanza, la differenza tra i due aspetti può essere così riassunta:

• Per una libreria, il codice dell'app chiama il codice della libreria.
• Per un framework, il codice dell'app viene chiamato dal framework.

Raccolta

Le librerie tendono a essere più semplici dei framework e offrono funzionalità limitate. Se passi un input a un metodo e ricevi un output, probabilmente hai utilizzato una libreria.

Guarda questo esempio della libreria lodash:

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

Come nel caso di molte librerie, è pratico leggere attentamente questo codice e capire cosa fa. C'è poca magia:

1. Un'istruzione import importa la libreria Lodash nel programma JavaScript.
2. Viene richiamato il metodo capitalize().
3. Al metodo viene passato un singolo argomento.
4. Il valore restituito viene acquisito in una variabile.

Framework

I framework tendono a essere più grandi delle librerie e contribuiscono maggiormente al peso complessivo della pagina. Infatti, un framework può includere una libreria.

Questo esempio mostra un framework semplice senza libreria e utilizza Vue, un framework JavaScript popolare.

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

Se confronti questo esempio di framework con l'esempio di libreria precedente, potresti notare le seguenti differenze:

• Il codice del framework comprende più tecniche e le astrae all'interno della propria API "guidata".
• Gli sviluppatori non hanno il controllo completo su come e quando avvengono le operazioni. Ad esempio, il modo e il momento in cui Vue scrive la stringa 'Hello, world' nella pagina non vengono più visualizzati da te.
• L'istanza della classe Vue comporta alcuni effetti collaterali, che sono comuni quando si usano i framework, mentre una libreria può offrire funzioni pure.
• Il framework prevede un particolare sistema di modelli HTML anziché utilizzarne uno tuo.
• Se leggi più a fondo la documentazione relativa al framework Vue o la maggior parte delle altre documentazioni relative ai framework, puoi vedere come i framework prescrivono i pattern di architettura che puoi utilizzare. I framework JavaScript ti sottraggono un po' di lavoro cognitivo, perché non devi saperlo autonomamente.

Quando utilizzare una libreria e un framework

Dopo aver letto i confronti tra librerie e framework, potresti iniziare a capire quando utilizzare l'uno o l'altro:

• In qualità di sviluppatore, un framework può ridurre la complessità. Come discusso, un framework può astrarre la logica, il comportamento e persino gli schemi di architettura. È particolarmente utile quando inizi un nuovo progetto. Una libreria può aiutare a ridurre la complessità, ma in genere è incentrata sul riutilizzo del codice.
• Gli autori di framework vogliono che tu sia produttivo e spesso sviluppi strumenti aggiuntivi, software di debug e guide complete tra le altre risorse per aiutarti a utilizzare un framework in modo efficace. Anche gli autori delle biblioteche vogliono mantenere la tua produttività, ma gli strumenti specializzati non sono comuni nelle biblioteche.
• La maggior parte dei framework fornisce un punto di partenza funzionale, ad esempio uno scheletro o un boilerplate, per aiutarti a creare rapidamente app web. Una libreria diventa parte del tuo codebase già consolidato.
• In generale, i framework introducono una certa complessità nel codebase. La complessità non è sempre ovvia all'inizio, ma può manifestarsi con il passare del tempo.

Ti ricordiamo che in genere non viene confrontata una libreria con un framework perché sono elementi diversi che svolgono attività diverse. Tuttavia, maggiore è la conoscenza di queste due funzionalità, più avrai la possibilità di decidere quale è la soluzione migliore per te. La decisione di utilizzare un framework o una libreria dipende in definitiva dalle tue esigenze.

Scambiabilità

Non cambierai la tua libreria o il tuo framework ogni settimana. Tuttavia, è buona norma comprendere gli svantaggi di un pacchetto che ti blocca nel suo ecosistema. Ti consigliamo inoltre di tenere presente che lo sviluppatore che decide di utilizzare un pacchetto di terze parti è in qualche modo responsabile della creazione di un basso accoppiamento tra il pacchetto e il codice sorgente dell'app.

Un pacchetto collegato al codice sorgente è più difficile da rimuovere e sostituire con un altro pacchetto. Potresti dover scambiare un pacco quando:

• Devi aggiornare un pacchetto non più mantenuto.
• Scopri che il pacchetto contiene troppi bug per poter lavorare.
• Scoprirai un nuovo pacchetto che soddisfa meglio le tue esigenze.
• I requisiti del tuo prodotto cambiano e il pacchetto non è più necessario.

Considera questo esempio:

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

L'esempio precedente utilizza il pacchetto @package/set-color di terze parti in tre file separati. Se lavori su questo codice e devi sostituire il pacchetto di terze parti, devi aggiornare il codice in tre posizioni.

In alternativa, puoi semplificare la manutenzione e astrarre l'utilizzo della libreria in un unico posto, come puoi vedere in questo esempio:

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

Nell'esempio precedente, l'utilizzo diretto della libreria è astratto. Pertanto, se devi sostituire il pacchetto di terze parti, aggiorni un solo file. Inoltre, ora è più facile lavorare con il codice perché il file set-color.js interno imposta un tema a colori predefinito da utilizzare.

Nota: quando leggi il vecchio e il nuovo codice, potresti non essere convinto del nuovo codice e porre domande quali: - Il nuovo codice non è più complesso perché c'è un ulteriore livello di indirezione? - Che cosa succede se non sostituisco mai il pacco? Come posso giustificare il tempo necessario per astrarre il codice? Si tratta di domande valide le cui risposte dipendono in ultima analisi dal caso d'uso. Con un'analisi o una semplice prototipazione, puoi valutare i pro e i contro per rispondere a queste domande, ma spesso non c'è una risposta giusta o sbagliata.

Facilità di utilizzo

Un framework può avere un'API complessa, ma potrebbe offrire agli sviluppatori strumenti che ne facilitano l'utilizzo in generale. La facilità d'uso si basa su molti fattori e può essere altamente soggettiva. Un framework può essere difficile da usare perché:

• Il framework ha un'API intrinsecamente complessa.
• Il framework è documentato male e richiede molte prove ed errori per risolvere i problemi.
• Il framework utilizza tecniche sconosciute a te e al tuo team.

I framework possono mitigare queste sfide attraverso best practice comuni, come le seguenti:

• Il framework offre strumenti di diagnostica e sviluppatore per semplificare il debug.
• Il framework ha una community attiva di sviluppatori che collaborano alla creazione di documentazione, guide, tutorial e video senza costi. Dopo aver fruito di questi contenuti, la produttività del framework è garantita.
• Il framework offre un'API che segue le comuni convenzioni di codifica. Stai utilizzando il framework perché hai imparato queste convenzioni in precedenza e hai maggiore dimestichezza con gli stili di programmazione.

Sebbene questi punti siano comunemente attribuiti ai framework, possono anche essere attribuiti alle librerie. Ad esempio, la libreria JavaScript D3.js è potente e ha un vasto ecosistema che offre workshop, guide e documentazione tra le altre risorse, tutti fattori che incidono sulla sua facilità d'uso.

Inoltre, un framework di solito prescrive un'architettura per la tua app web, mentre una libreria è in genere compatibile con la tua architettura esistente, di qualunque cosa si tratti.

Esibizione

In generale, i framework possono influire sulle prestazioni più delle librerie, anche se esistono eccezioni in questo caso. Le prestazioni del web sono molto vaste e trattano molti argomenti, per cui queste sezioni trattano due argomenti degni di nota: l'agitazione degli alberi e gli aggiornamenti del software.

Tremore degli alberi

Il raggruppamento è solo un aspetto delle prestazioni web, ma ha un grande effetto in termini di prestazioni, soprattutto con librerie più grandi. L'utilizzo di tremolio degli alberi durante l'importazione e l'esportazione migliora le prestazioni perché trova ed elimina il codice non necessario per l'app.

Quando raggruppi il codice JavaScript, un passaggio utile noto come tremolio ad albero è un'ottimizzazione delle prestazioni molto utile per il tuo codice, sebbene sia più facile da eseguire con le librerie che con i framework.

Quando importi codice di terze parti nel codice sorgente, in genere lo si raggruppa in uno o più file di output. Ad esempio, i file header.js, footer.js e sidebar.js sono combinati nel file output.js, che è il file di output che carichi nell'app web.

Per comprendere meglio il tremolio degli alberi, considera questi esempi di codice:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

Ai fini della dimostrazione, l'esempio di codice library.js è volutamente ridotto rispetto a quello che potresti trovare nel mondo reale, dove la libreria può essere lunga migliaia di righe.

Un processo bundle ingenuo potrebbe esportare il codice con questo output:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

Anche se la funzione subtract() non è necessaria in questa app, è comunque inclusa nel bundle finale. Un codice non necessario come questo aumenta le dimensioni di download, i tempi di analisi e compilazione e i costi di esecuzione che gli utenti devono pagare. Un approccio di base per la rimozione degli alberi rimuove i codici morti e produce questo output:

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

Nota che il codice è più breve e conciso. In questo esempio, il miglioramento delle prestazioni è trascurabile, ma in un'app reale in cui la libreria è lunga migliaia di righe, l'effetto delle prestazioni può essere molto più significativo. È interessante notare come gli strumenti moderni per i bundle, come Parcel, Webpack e Rollup, fanno un passo in più perché combinano minimizzazione e tremolio degli alberi per creare un bundle altamente ottimizzato. Per dimostrare l'efficacia degli strumenti in bundle, abbiamo utilizzato Parcel per creare un file bundle con i precedenti esempi di codice. Il pacchetto ha rimosso tutto il codice inutilizzato ed esportato questo singolo modulo:

console.log(7+10);

Il pacchetto è sufficientemente intelligente da rimuovere istruzioni di importazione, definizioni di funzioni e comportamento tra gli altri elementi per creare un codice altamente ottimizzato.

Il raggruppamento è solo un aspetto delle prestazioni web, ma ha un grande effetto in termini di prestazioni, soprattutto con librerie più grandi. Lo scuotimento degli alberi è in genere più semplice da eseguire con le librerie che con i framework.

Aggiornamenti software

Per molte librerie e framework, gli aggiornamenti software aggiungono funzionalità, correggono bug e, in definitiva, aumentano di dimensioni nel tempo. Non è sempre necessario scaricare gli aggiornamenti, ma se gli aggiornamenti includono correzioni di bug, miglioramenti di funzioni desiderati o correzioni di sicurezza, è probabile che l'aggiornamento sia necessario. Tuttavia, maggiore è la quantità di dati inviati tramite cavo, meno performanti sono le prestazioni dell'app e l'effetto sulle prestazioni dell'esperienza utente.

Se una libreria aumenta di dimensioni, puoi utilizzare l'scuotimento degli alberi per mitigare la crescita. In alternativa, puoi utilizzare un'alternativa più piccola alla libreria JavaScript. Per ulteriori informazioni, consulta la sezione Scambiabilità.

Se un framework cresce, non solo l'albero è più difficile da scuotere, ma può essere più difficile sostituire un framework con un altro. Per ulteriori informazioni, consulta la sezione Scambiabilità.

Nota: gli autori e i gestori dei framework investono molto per ottimizzare il proprio codice, in modo che tu e i tuoi utenti possiate trarre vantaggio. Per molti framework e librerie popolari, spesso correzioni e miglioramenti delle prestazioni vengono forniti con gli aggiornamenti software. Il rendimento non migliora sempre nel tempo.

Occupabilità

È un po' un segreto che molte aziende hanno requisiti rigidi per gli sviluppatori che conoscono un particolare framework. Potrebbero ignorare le tue conoscenze dei concetti fondamentali del web e concentrarsi solo sulle conoscenze specifiche di un determinato framework JavaScript. Giusto o sbagliato, questa è la realtà per molti lavori.

La conoscenza di alcune librerie JavaScript non danneggerà la tua applicazione di lavoro, ma non c'è alcuna garanzia che ti distinguerà. Se conosci molto bene alcuni framework JavaScript popolari, ci sono buone probabilità che i datori di lavoro considerino favorevoli questa conoscenza nell'attuale mercato del lavoro per gli sviluppatori web. Alcune grandi organizzazioni aziendali sono bloccate con framework JavaScript molto vecchi e possono persino essere disperati a trovare candidati che siano a proprio agio con tali framework.

Puoi usare questo open secret a tuo vantaggio. Tuttavia, affronta il mercato del lavoro con cautela e tenendo presenti le seguenti considerazioni:

• Ricorda che, se nella tua carriera trascorri gran parte del tempo con un solo framework, potresti perderti esperienze di apprendimento con altri framework più moderni.
• Prendi in considerazione uno sviluppatore che non ha una buona conoscenza dei concetti fondamentali dello sviluppo software o dello sviluppo web, ma viene assunto come sviluppatore di framework. Questo sviluppatore non scrive codice efficace e potresti trovare scoraggiante o complicato lavorare su un codebase di questo tipo. In alcuni casi, questo scenario può portare al burnout. Ad esempio, potresti dover eseguire il refactoring del codice o ottimizzarlo delle prestazioni perché è lento.
• Quando apprendi lo sviluppo web, il percorso migliore è iniziare con una particolare attenzione ai concetti fondamentali dello sviluppo web, dello sviluppo software e dell'ingegneria del software. Una base così solida ti aiuta a scegliere qualsiasi framework JavaScript in modo rapido ed efficace.

Conclusione

Ottimo lavoro per comprendere le differenze tra i framework e le librerie JavaScript. Non sceglierai spesso framework o librerie a meno che non lavori su progetti greenfield o come consulente. Tuttavia, quando si prendono decisioni di questo tipo, maggiori sono le conoscenze in merito all'argomento e più informate la decisione.

Come hai appreso, la scelta del framework che crei e, in alcuni casi, la scelta della libreria, può influire notevolmente sulla tua esperienza di sviluppo e sugli utenti finali, ad esempio in relazione alle prestazioni.