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 è un fattore determinante per il peso complessivo della pagina ed è lo stesso 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. Dovresti invece 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, le librerie e i framework vengono spesso confusi e più ne sai su entrambi, 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, 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. Non c'è molta magia:
- 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 queste differenze:
- Il codice del framework comprende più tecniche e le rimuove nella propria API opinativa.
- Gli sviluppatori non hanno il controllo completo su come e quando si verificano le operazioni. Ad esempio, non devi preoccuparti di come e quando Vue scrive la stringa
'Hello, world'
nella pagina. - L'istanziazione della classe
Vue
comporta alcuni effetti collaterali, comuni quando si utilizzano framework, mentre una raccolta può offrire funzioni pure. - Il framework prescrive un determinato 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 alleggeriscono del carico cognitivo perché non devi capire tutto da solo.
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ò rivelarsi nel tempo.
Ti ricordiamo che in genere non si confronta una libreria con un framework perché sono cose diverse che svolgono attività diverse. Tuttavia, più conosci le due opzioni, più sei in grado di decidere quale sia la 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 sostituire con un altro pacchetto. Potresti dover sostituire un pacchetto quando:
- Devi apportare aggiornamenti a un pacchetto non più gestito.
- Scopri che il pacchetto presenta troppi bug per poterci lavorare.
- Scopri un nuovo pacchetto che soddisfa meglio le 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 posto, 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 strumenti per sviluppatori che ne semplificano l'utilizzo complessivo. 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 ridurre al minimo 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 delle eccezioni. 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 bundling è solo un aspetto del rendimento web, ma ha un grande effetto sulle prestazioni, soprattutto con 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);
Parcel è abbastanza intelligente da rimuovere dichiarazioni di importazione, definizioni di funzioni e comportamento, tra gli altri elementi, per creare codice altamente ottimizzato.
Il bundling è solo un aspetto del rendimento web, ma ha un grande effetto sulle prestazioni, soprattutto con librerie più grandi. In genere, l'eliminazione delle risorse non utilizzate è 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, ti consigliamo di 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 libreria aumentano, puoi utilizzare l'eliminazione degli alberi per ridurle. In alternativa, puoi utilizzare un'alternativa più piccola alla libreria JavaScript. Per ulteriori informazioni, vedi 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, vedi 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 essere alla ricerca di candidati che si sentano a proprio agio con questi framework.
Puoi utilizzare questo 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.
- Prendiamo ad esempio uno sviluppatore che non conosce a fondo le nozioni di base dello sviluppo software o web, ma viene 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 queste decisioni, più conoscenze hai sull'argomento, più informata sarà la tua decisione.
Come hai appreso, la scelta del framework e, in alcuni casi, della libreria può influire notevolmente sulla tua esperienza di sviluppo e sugli utenti finali, ad esempio in termini di prestazioni.