Perché usare TypeScript

Il linguaggio JavaScript è un linguaggio di programmazione molto popolare, versatile e potente; tuttavia, mantenere una codebase JavaScript di complessità crescente, comporta una sfida non da poco: 

• la maggior parte degli errori potrà essere riscontrata solo dopo aver lanciato la nostra web app, a causa del type system dinamico di questo linguaggio; 
• sarà sempre più difficile capire in che modo è possibile accedere correttamente a un certo dato, se non si sa esattamente da dove viene e che trasformazioni ha subito. 

Prendiamo ad esempio il seguente codice: 

function sum(a, b) { 
 return a + b; 
} 
const result = sum(false, "hello"); 
console.log(result); // -> "falsehello"

La funzione sum è, probabilmente, pensata per sommare due numeri, eppure JavaScript processerà la somma senza protestare; in questo esempio (e in un’infinità di situazioni analoghe) il nostro codice JavaScript gestisce con apparente successo casistiche che, normalmente, si verificano solo quando il codice è progettato male, oppure al presentarsi di casi limite non gestiti correttamente. 

Vediamo un altro esempio: 

const model = null; 
const message = { }; 
console.log(model.name); // -> TypeError: Cannot read properties of null (reading 'name') 
console.log(message()); // -> TypeError: message is not a function

Nell’esempio, le due variabili hanno volutamente nomi fuorvianti per sottolineare un problema al quale siamo costantemente esposti lavorando con linguaggi dinamici come JavaScript: la responsabilità di definire, processare e accedere alle variabili in modo consistente è totalmente in carico al programmatore. 

In questo caso, abbiamo introdotto dei bug semplicemente andando a leggere una proprietà su una variabile con valore null, oppure tentando di chiamare una variabile che non è una funzione; JavaScript ha, giustamente, segnalato che questi sono errori di tipo, ma ha potuto farlo solo in esecuzione, quindi troppo tardi. 

Ovviamente, negli esempi presentati qui sopra, l’occhio del programmatore è una risorsa sufficiente ad individuare e risolvere il problema. Tuttavia, man mano che il nostro progetto cresce (e verosimilmente può crescere molto più di così), sarà sempre più difficile prevedere quale sarà il ciclo di vita di una variabile e in quali punti del codice verrà processata. 

Ma quindi, allora, che senso ha usare JavaScript?

JavaScript non ha niente che non vada di per sé, ma quando lavoriamo con questo linguaggio dovremo fare particolare attenzione a molti errori che sono riscontrabili solo testando l’applicazione; d’altra parte, se un errore può essere riscontrato prima che la nostra web app vada in esecuzione, TypeScript farà di tutto per aiutarci a prevenirlo. 

In definitiva, TypeScript è nato per soddisfare le esigenze di scalabilità dei progetti JavaScript, mettendo a disposizione (come il nome stesso suggerisce) un potente sistema di tipi, validato a compile time, che ci consentirà di dichiarare quali tipi di dato stiamo processando e si assicurerà che ci sia sempre consistenza fra questi. 

Consideriamo anche che al crescere di un progetto, cresce anche il numero di contributori; un type system rigoroso ci permetterà anche di documentare in modo formalmente rigoroso le API del nostro codice. Non è un caso che moltissime librerie scritte in semplice JavaScript forniscano comunque tutte le definizioni di tipo in TypeScript, in modo da fissare il corretto utilizzo delle variabili e delle funzioni messe a disposizione. 

Note su questa guida 

Essendo un superset di JavaScript, TypeScript in sé è un linguaggio molto semplice da approcciare, e può essere utilizzato a diversi livelli di complessità, in base all’esperienza e alla conoscenza del suo sistema di tipi. 

Riguardo al sistema di tipi, bisogna fare una premessa importante per affrontare questa guida: il type system di TypeScript è molto complesso. 

Ovviamente, la sua complessità è tutt’altro che superflua e, anzi, per certi versi, offre una versatilità senza pari tra i linguaggi di programmazione. 

Tuttavia, questa complessità rende pressoché impossibile procedere in modo perfettamente lineare. 

In questa guida incontrai spesso espressioni del tipo “come abbiamo visto” o “più avanti approfondiremo”: questo perchè riteniamo più opportuno introdurre concetti utili ed esemplificativi appena ne abbiamo l’occasione, con la promessa di approfondirli in modo più strutturato a tempo debito; l’alternativa sarebbe procedere in modo più lineare, ma sacrificando notevolmente la ricchezza di esempi e casi d’uso per i costrutti che incontreremo: sarebbe un peccato, no?