Questa pagina è stata tradotta dall'API Cloud Translation.

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, ovvero 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 anziché quantitative tra librerie e framework. Ad esempio:

Quantitativo: i framework in genere rispettano il principio di inversione del controllo.
Qualitative: l'esperienza con il framework può attirare maggiormente i futuri datori di lavoro quando cerchi lavoro.

Perché imparare a conoscere librerie e framework?

L'utilizzo di librerie e framework JavaScript è molto diffuso sul web. Tutti gli altri siti web sembrano utilizzare del codice di terze parti all'interno delle risorse JavaScript. Il peso delle pagine web peggiora nel tempo, il che influisce sugli utenti. JavaScript contribuisce in larga misura al peso complessivo della pagina ed è lo stesso codice JavaScript che spesso comprende librerie e framework di terze parti.

Non è sufficiente dire "Smetti di utilizzare i framework JavaScript", perché i framework offrono un grande vantaggio agli sviluppatori. I framework possono aiutarti a scrivere codice in modo efficiente e a implementare rapidamente le funzionalità, tra gli altri vantaggi. Piuttosto, dovresti informarti in modo da poter prendere una decisione consapevole quando sarà il momento.

Dovresti usare una libreria o un framework oggi?" è una domanda insolita da porsi. Le librerie e i framework sono due cose molto diverse. Tuttavia, librerie e framework sono spesso confusi e maggiore è la conoscenza di questi due aspetti, maggiori sono le probabilità di prendere decisioni ponderate sul loro utilizzo.

Esempi di librerie e framework

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

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 ad essere più semplici dei framework e offrono un ambito ristretto di funzionalità. 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 per molte librerie, è pratico leggere questo codice e capire cosa fa. C'è poca magia in gioco:

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

Framework

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

Questo esempio mostra un semplice framework senza una 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 in una propria API "guidata".
Gli sviluppatori non hanno il controllo completo su come e quando vengono eseguite le operazioni. Ad esempio, come e quando Vue scrive la stringa 'Hello, world' nella pagina è un'astrazione rispetto a te.
L'istanziazione della classe Vue comporta alcuni effetti collaterali, comuni quando utilizzi i framework, mentre una raccolta può offrire funzioni pure.
Il framework indica un particolare sistema di modelli HTML anziché utilizzare il tuo.
Se leggi la documentazione del framework Vue o la maggior parte delle altre documentazioni dei framework, puoi vedere in che modo i framework prescrivono pattern di architettura che puoi utilizzare. I framework JavaScript ti eliminano un po' di carico cognitivo perché non devi saperlo autonomamente.

Quando utilizzare una libreria anziché un framework

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

Un framework può ridurre la complessità per te, lo sviluppatore. Come discusso, un framework può astrarre logica, comportamento e persino pattern di architettura. È particolarmente utile quando inizi un nuovo progetto. Una libreria può aiutarti a gestire la complessità, ma in genere si concentra sul riutilizzo del codice.
Gli autori dei framework vogliono che tu sia produttivo e spesso sviluppano strumenti aggiuntivi, software di debug e guide complete, oltre ad altre risorse, per aiutarti a utilizzare un framework in modo efficace. Anche gli autori delle biblioteche vogliono che tu sia produttivo, 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 della base di codice già stabilita.
In generale, i framework introducono una certa complessità nel codebase. La complessità non è sempre evidente all'inizio, ma può manifestarsi nel tempo.

Ti ricordiamo che in genere non si confronta una libreria con un framework perché sono cose diverse che svolgono attività diverse. Tuttavia, maggiori sono le tue conoscenze su questi due aspetti, più avrai la possibilità di decidere quale sia la soluzione migliore per te. La decisione di utilizzare un framework o una libreria dipende in ultima analisi dai tuoi requisiti.

Sostituibilità

Non cambierai la libreria o il framework ogni settimana. Tuttavia, è buona norma comprendere i lati negativi di un pacchetto che ti vincola al 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 accoppiamento lasco tra il pacchetto e il codice sorgente dell'app.

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

Devi aggiornare un pacchetto che non è più gestito.
Scopri che il pacchetto presenta troppi bug per poter essere utilizzato.
Scoprirai un nuovo pacchetto che risponde meglio alle tue esigenze.
I requisiti del 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 di terze parti @package/set-color in tre file separati. Se lavori su questo codice e devi sostituire il pacchetto di terze parti, devi aggiornare il codice in tre punti.

In alternativa, puoi semplificare la manutenzione e astrarre l'utilizzo della libreria in un unico punto, come mostrato 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 viene rimosso. Pertanto, se devi sostituire il pacchetto di terze parti, devi aggiornare un solo file. Inoltre, ora è più facile lavorare con il codice perché il file set-color.js interno imposta un tema di colore predefinito da utilizzare.

Facilità di utilizzo

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

Il framework ha un'API intrinsecamente complessa.
Il framework è scarsamente documentato e richiede molti tentativi ed errori per risolvere i problemi.
Il framework utilizza tecniche non familiari a te e al tuo team.

I framework possono mitigare questi problemi tramite best practice comuni, ad esempio:

Il framework offre strumenti di sviluppo e diagnostica 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 consumato questi contenuti, puoi utilizzare il framework in modo produttivo.
Il framework offre un'API che segue le convenzioni di codifica comuni. Sei produttivo con il framework perché hai appreso queste convenzioni in precedenza e hai una maggiore familiarità con gli stili di programmazione.

Sebbene questi punti siano comunemente attribuiti ai framework, possono essere attribuiti anche alle librerie. Ad esempio, la libreria JavaScript D3.js è potente e dispone di un vasto ecosistema che offre workshop, guide e documentazione, oltre ad altre risorse, che influiscono sulla sua facilità d'uso.

Inoltre, un framework in genere prescrive un'architettura per la tua app web, mentre una libreria è in genere compatibile con l'architettura esistente, qualunque essa sia.

Prestazioni

In generale, i framework possono influire sulle prestazioni più delle librerie, anche se esistono eccezioni a questa regola. Le prestazioni web sono un'area enorme con molti argomenti, quindi queste sezioni toccano due argomenti importanti: lo shaking dell'albero e gli aggiornamenti software.

Movimento di alberi

Il raggruppamento è solo un aspetto delle prestazioni web, ma ha un grande effetto sulle prestazioni, soprattutto con le librerie più grandi. L'utilizzo dell'eliminazione degli elementi non necessari durante l'importazione e l'esportazione migliora le prestazioni perché trova e rimuove il codice non necessario per l'app.

Quando raggruppi il codice JavaScript, esiste un passaggio utile noto come tree shaking che rappresenta un'ottimizzazione del rendimento utile che puoi apportare al codice, anche se è più facile da eseguire con le librerie rispetto ai framework.

Quando importi codice di terze parti nel codice sorgente, in genere lo raggruppi in uno o più file di output. Ad esempio, i file header.js, footer.js e sidebar.js vengono combinati nel file output.js, che è il file di output caricato nella tua app web.

Per comprendere meglio lo shaking dell'albero, 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));

A scopo dimostrativo, il codice di esempio library.js è volutamente ridotto rispetto a quello che potresti trovare nel mondo reale, dove la libreria può essere lunga migliaia di righe.

Un processo di aggregazione 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 del download, i tempi di analisi e compilazione e i costi di esecuzione che gli utenti devono pagare. Un approccio di base di tree-shaking rimuove il codice inutilizzato e produce questo output:

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

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

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

console.log(7+10);

L'applicazione Parcel è sufficientemente intelligente da rimuovere le istruzioni di importazione, le definizioni delle funzioni e il comportamento tra gli altri elementi per creare un codice altamente ottimizzato.

Il bundling è solo un aspetto delle prestazioni web, ma ha un grande effetto sulle prestazioni, in particolare con librerie più grandi. L'eliminazione degli alberi è in genere più semplice 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 includono correzioni di bug, miglioramenti delle funzionalità o correzioni di sicurezza, probabilmente dovresti eseguirli. Tuttavia, più dati invii sulla rete, meno performante sarà la tua app e maggiore sarà l'impatto del rendimento sull'esperienza utente.

Se le dimensioni di una biblioteca aumentano, puoi mitigare l'utilizzo dello scuotimento ad alberi per mitigare la crescita. In alternativa, puoi utilizzare un'alternativa più piccola alla libreria JavaScript. Per ulteriori informazioni, consulta la sezione Sostituibilità.

Se le dimensioni di un framework aumentano, non solo l'albero diventa più difficile da gestire, ma può essere più complicato sostituire un framework con un altro. Per ulteriori informazioni, consulta la sezione Sostituibilità.

Idoneità al lavoro

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

La conoscenza di alcune librerie JavaScript non danneggerà la tua domanda di lavoro, ma non c'è alcuna garanzia che ti farà risaltare. Se conosci molto bene alcuni framework JavaScript popolari, è probabile che i datori di lavoro considerino queste conoscenze vantaggiose nell'attuale mercato del lavoro per gli sviluppatori web. Alcune grandi organizzazioni aziendali sono bloccate con framework JavaScript molto vecchi e potrebbero persino cercare disperatamente candidati che si sentano a proprio agio con questi framework.

Puoi usare questo aperto segreto a tuo vantaggio. Tuttavia, avvicinati al mercato del lavoro con cautela e tenendo presenti queste considerazioni:

Ricorda che se nella tua carriera utilizzi un solo framework per molto tempo, potresti perdere opportunità di apprendimento con altri framework più moderni.
Prendi in considerazione uno sviluppatore che non ha ancora una buona conoscenza dei concetti fondamentali dello sviluppo di software o dello sviluppo web, ma viene ancora assunto come sviluppatore di framework. Questo sviluppatore non scrive codice efficace e potresti trovare scoraggiante o difficile lavorare su un codice di base di questo tipo. In alcuni casi, questo scenario può portare al burnout. Ad esempio, potresti dover eseguire il refactoring del codice o ottimizzarne il rendimento perché è lento.
Quando impari lo sviluppo web, il percorso migliore è iniziare concentrandosi molto sulle nozioni di base dello sviluppo web, dello sviluppo software e dell'ingegneria del software. Una base così solida ti aiuta ad acquisire qualsiasi framework JavaScript in modo rapido ed efficace.

Conclusione

Complimenti per il tuo impegno nel comprendere il confronto tra framework e librerie JavaScript. Non sceglierai spesso framework o librerie, a meno che tu non lavori a progetti greenfield o come consulente. Tuttavia, quando si presentano tali decisioni, maggiore è la tua conoscenza dell'argomento, più sei consapevole della tua decisione.

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