Foto Andrea Mangano
Andrea Mangano

Perchè usare TypeScript nella tua applicazione JavaScript

Articolo
3 maggio 2020
10m
TypeScript ha raggiunto una grande popolarità negli ultimi anni ed è sempre più adottato nello sviluppo di applicazione in JavaScript. In questo articolo, fedele all'esperienza maturata negli ultimi due anni, elenco vantaggi e svantaggi di utilizzo e alcuni particolari contesti dove ne consiglio l'adozione.
TypeScript
Vantaggi e svantaggi
Scenari utilizzo
Aiutami a diffonderlo

Premessa

Fino a qualche anno fa, rifiutavo l’idea di scrivere le mie applicazioni web in TypeScript.

Perchè avrei dovuto? Ne avevo realmente bisogno?

A queste domande cercherò, a distanza di due anni, di dare risposta tenendo fede alla mia personale esperienza.

Sia chiaro che, questo articolo non ha l’obiettivo di convincerti che è bene o male (ogni convinzione ognuno la matura da sè), ma piuttosto intende raccogliere alcuni falsi miti, immotivati timori, vantaggi (e svantaggi) che ho sperimentato nell’utilizzare TypeScript nel mio lavoro quotidiano.

Cercherò, in ultima battuta, di delineare alcuni contesti in cui ne consiglio l’adozione.

Perchè NON usavo TypeScript: perplessità e timori

Ho da sempre lavorato come sviluppatore front-end. Il mio linguaggio principale è JavaScript e raramente mi ero imbattuto in ecosistemi fortemente tipizzati.

In linea di massima, avevo la sensazione che TypeScript mi avrebbe creato più noie che vantaggi e che fosse overkill per le mie reali necessità.

C’erano inoltre, motivi più concreti (o almeno ritenuti all’epoca tali) a sostegno del mio rifiuto:

  • Verbosità del codice: avrei sicuramente scritto più linee di codice rispetto all’uso puro di JavaScript; avrei dovuto creare tipi ed interfacce, signature per funzioni, etc…;

  • Impiego maggiore di tempo nella scrittura del codice: associavo alla verbosità, l’idea che potessi sprecare del tempo utile (ed indispensabile in progetti con deadline stringenti);

  • Issue aperte: avevo il timore di imbattermi in una o più delle innumerevoli issue ai tempi irrisolte e perdermi tra trick ed improbabili soluzioni;

  • Documentazione: mancava un’accurata ed esaustiva documentazione per l’integrazione e l’uso con i principali framework di sviluppo;

  • Pochi boilerplate: c’era inoltre una bassa quantità di boilerplate per app preconfigurati con TypeScript; la maggior parte di quelli presenti erano il frutto del lavoro di singoli sviluppatori ed erano spesso poco supportati ed aggiornati;

  • Librerie non tipizzate: altro problema era rappresentato dall’assenza di definizioni di tipo nelle principali librerie npm da me utilizzate. Occorreva ignorare i tipi per il package a livello globale e usare la libreria senza il supporto dei tipi in scrittura;

  • Librerie non correttamente tipizzate: caso simile, ma differente, alcune librerie scritte in JavaScript avevano rilasciato separatamente definizioni di tipo per TypeScript (i classici pacchetti @types/package-name) ma le definizioni non erano coerenti al codice della libreria JavaScript (causa di sviste e dimenticanze conseguenti agli aggiornamenti della libreria).

Il mio primo progetto TypeScript: gli ostacoli iniziali e la senzazione di aver fatto una scelta sbagliata

Ho iniziato ad usare TypeScript nel 2018.

Ero in procinto di iniziare un nuovo progetto quando, in comune accordo con il mio team, decidemmo di scrivere il Frontend dell’applicativo in React e Typescript.

Cosa ci aveva convinti?

I nostri clienti erano startup e medie aziende:

  • Le specifiche dei prodotti cambiavano frequentemente;

  • Gli applicativi crescevano velocemente senza controllo;

  • Componenti di altri team subbentravano nei progetti in corso per assicurare la consegna nei tempi previsti;

  • Aggiunte funzionali o modifiche causavano puntualmente bug , la maggior parte dei quali per l’impossibilità di avere uno strumento a supporto del refactoring.

Di norma, tutto diventava ben presto ingestibile, sopratutto nei progetti sprovvisti di adeguati test e idonea documentazione.

Qualcuno asserirà che queste sono conseguenze di problemi non solo tecnici, ma anche (o soprattutto) di gestione. Concordo pienamente.

Ma ci aveva convinto l’idea che TypeScript potesse dare ordine al codice, che potesse garantire una scalabilità maggiore degli applicativi ed aiutarci nei quotidiani cambi di contesto quando le esigenze organizzative, ci avrebbero costretti a spostarci da un progetto all’altro.

Iniziai per primo lo sviluppo. A distanza di un paio di settimane, non ero molto soddisfatto:

  • La poca esperienza mi aveva rallentato: la risoluzione di alcuni errori di compilazione mi aveva sottratto tempo generando situazioni di stallo;

  • Non era stato facile il setup iniziale dell’applicativo: Non c’erano starter kit per React adeguati alle nostre esigenze. A fatica ne avevo riadattato uno sprecando parecchio tempo;

  • Era stato necessario gestire i pacchetti npm sprovvisti di tipi aggiungendoli manualmente o ignorandoli;

  • Ultima, ma forse la peggiore tra le cose, avevo saltato la prima consegna e non ero del tutto riuscito a giustificare l’uso di TypeScript.

In tutta sincerità, la tentazione di far un passo indietro e tornare nella mia “confort zone” era molto forte. Ma ero prima curioso di vedere che effetto avesse TypeScript sugli altri componenti del team.

TypeScript in un team Junior

Altri sviluppatori si unirono al progetto progetto qualche settimana dopo. Si trattava di sviluppatori con qualche anno di esperienza sul Frontend e nulla esperienza in TypeScript.

Li lasciai provare da sè, senza troppe dritte e controllo per capire un po’ la loro reazione e percezione.

Per alcuni di loro fù abbastanza traumatizzante. Si ritrovarono bloccati quasi del tutto nello scrivere il codice. Il focus era diventata la mera compilazione, rispetto alla logica e alla qualità di ciò che stavano scrivendo.

Sembrava ci fosse lì, accanto a loro, un maestro pronto a bacchettarli per ogni singolo errore grammaticale, mentre a fatica cercavano di trovare la frase giusta per formulare un pensiero.

Gli errori a compile-time non permettevano loro la piena libertà di sperimentare. Era quello il punto.

Provai quindi a supportarli cercando di rendergli semplice tutto ciò con cui avevo, nelle settimane precedenti, litigato.

Diedi loro alcuni esempi, di crescente difficoltà, di componenti React scritti in TypeScript.

Successivamente condivisi loro un ricettario TypeScript di pattern React. Era un modo rapido per avere dei riferimenti senza perdersi tra i mille articoli in rete (Es. https://github.com/typescript-cheatsheets/react-typescript-cheatsheet).

Il confronto con qualcosa già visto, aiutava la comprensione e infondeva fiducia.

Qualcosa iniziò a muoversi. Bisognava attenersi alle “regole”, come qualsiasi linguaggio, prenderci confidenza e assimilarle.

Nel frattempo, nelle mie possibilità, cercavo di anticipare i problemi più complessi.

I vantaggi di TypeScript: benefici a lungo termine

Cosa accadde nei mesi successivi?

Dopo aver superato gli ostacoli iniziali, al crescere delle righe di codice, comminciarono ad essere più limpidi i vantaggi all’intero team:

  • Il codice appariva più ordinato e leggibile; permetteva a noi sviluppatori di ricordare (o comprendere) più velocemente di cosa si occupava ogni singola parte;

  • Le funzioni di completamento automatico e refactoring in VSCode funzionavano in modo più accurato, non perché l’IDE fosse più intelligente di altre, ma perchè TypeScript ne semplificava il lavoro;

  • Aggiungere o modificare funzionalità era più rapido e sicuro: la funzione di completamento del codice evitava ricerche nei file, la tipizzazione statica rilevava molti bug funzionali durante la scrittura del codice;

  • Evitando bug comuni, potevamo dedicare maggior tempo alla correzione di quelli con maggiore complessità;

  • A costo zero, tramite l’adozione di alcuni tool, avevamo generato automaticamente la documentazione per l’uso delle props dei componenti di interfaccia;

  • La qualità del codice era migliorata perchè era migliorata la sua manutenibilità: la codebase era piú solida alla sostituzione di librerie terze o integrazioni di sviluppi paralleli. Semplicemente TypeScript non compilava quando l’uso di funzioni e componenti non era in linea con le definizioni dei tipi;

  • Inoltre, il dover definire puntualmente tipi ed interfacce, dava l’occasione di disegnare con più cura le API dei componenti UI, di generalizzare i modelli dei dati a garanzia di una maggiore consistenza e coerenza tra i componenti.

Le interruzioni, dovute ai dubbi sull’utilizzo di funzioni scritti in precedenza, erano sensibilmente diminuite. Era anche diminuita la paura di utilizzare codice altrui.

Quello che inizialmente sembrava tempo sprecato, diventava ora tempo guadagnato e una complessiva maggiore agilità e autonomia del team.

La mia nuova senzazione fù di soddisfazione. Erano quelle regole e costrizioni, inizialmente fastidiose ed apparentemente inutili, a darci un metodo di scrittura strutturato e condiviso, e un codice sicuramente più solido.

Quando ha senso usare e NON usare TypeScript

Oggi, rispetto a due anni fa, lavoro in una nuova società, con persone di comprovata esperienza in linguaggi tipizzati, e sicuramente più preparati di me su questi argomenti. È stata quasi, e ribadisco QUASI, una scelta naturale quella di utilizzare TypeScript nella scrittura del Frontend.

Nonostante le ottime premesse, non sono mancati i dubbi iniziali per chi, prima di allora, non l’aveva mai provato e qualche difficoltà nella configurazione dei progetti.

Ciò nonostante, se qualcuno mi chiedesse: “Consiglieresti sempre l’uso di TypeScript?” la mia risposta sarebbe: “Assolutamente no!”

Ci sono casi in cui puoi vivere tranquillamente senza o casi in cui, è meglio evitare:

  • Progetto molto piccolo: Su una code base non estesa, TypeScript non porta grandi benefici, ma un aumento notevole di righe di codice in annotazioni (a mio parere) non giustificato;

  • Team di figure junior o con poca esperienza in TypeScript: C’è una curva di apprendimento variabile legata alla conoscenza di ecosistemi tipizzati. Il mio consiglio è di avventurati in un progetto in TypeScript solo se hai tempo extra e scadenze non imminenti. È sicuramente più veloce scrivere qualcosa in JavaScript. La mancanza di un sistema di tipi rende facili le modifiche;

  • Prototipazione, esperimenti e studio: Evitalo se stai costruendo un prototipo, se vuoi velocemente portare avanti piccoli esperimenti o se stai apprendendo concetti di sviluppo front-end, a meno che, stai sperimentando o studiando proprio TypeScript! :D

Dall’altro canto, ci sono circostanze ideali per l’uso di TypeScript:

  • Codebase estesa: Quando la quantità di codice è estesa, TypeScript può aiutarti ad evitare molti errori comuni, ti dà maggiori garanzie su piccoli e grandi refactoring, permettendoti di introdurre con maggiore facilità (e sicurezza) cambiamenti radicali alla tua applicazione;

  • Team grande: TypeScript ti dà rigore e consistenza, in più facilità agli sviluppatori la comprensione, la modifica o l’utilizzo di codice altrui;

  • Team esperto: L’esperienza abbassa la cuva di apprendimento. Se l’investimento di tempo iniziale è basso, valuta vivamente i vantaggi di utilizzo nel contesto del tuo progetto;

  • Team di figure junior con poca esperienza in JavaScript: Sembrerebbe in contrasto al punto precedente e a quanto detto prima, ma il realtà non lo è. Se lavori con persone con poca esperienza in JavaScript, TypeScript potrebbe evitare una miriade di piccoli e grandi errori nel tuo applicativo. La libertà di JavaScript si traduce nella necessità di avere una consapevolezza di ciò che stai facendo. Un sistema tipizzato fa sì che sia più difficile rompere le cose;

  • La libreria o il framework utilizzato consigliano TypeScript

  • Sviluppo di alcune tipologie di progetti: Su alcuni applicativi, esempio nel campo medico o finanziario, lo vedo come una scelta obbligata. Anche un banale errore di type checking, può avere effetti disastrosi durante l’elaborazione dati;

  • Aggiungerei anche l’opzione: Se lo usi sempre e sai che avrai vita difficile senza! :D

Fai inoltre attenzione a non cadere preda di concezioni sbagliate che potrebbero portarti a non utilizzare TypeScript o, contrariamente, ad utilizzarlo per benefici che non puoi avere.

Sbagli se pensi che il codice generato sia più grande se usi TypeScript. Non è aggiunto nessun codice extra per il controllo dei tipi runtime. Il controllo avviene in fase di transpiling e tutte le annotazioni di tipo sono rimosse da codice JavaScript generato.

TypeScript non è uno strumento sostituitivo ai test. TypeScript garantisce un controllo sui tipi, non sulle logiche e funzioni dell’applicativo. Il codice potrebbe compilare ma ciò non ti garantisce che la sua esecuzione abbia il risultato atteso;

Ultima cosa, ma non meno rilevante per la mia personale esperienza, TypeScript non è la soluzione, nè il mezzo adatto, per convertire nel minor tempo possibile sviluppatori non JavaScript al mondo dello sviluppo front-end.

Conclusioni

TypeScript sta diventando un’opzione fondamentale per le organizzazioni che hanno la necessità di sviluppare progetti complessi e con una grande codebase. Personalmente, lo reputo in tali casi, un must-to-have.

La sua natura di linguaggio orientato agli oggetti, permette di mantenere il codice pulito, scalabile, coerente, con maggiore semplicità nel debug, non dimenticando che può essere utilizzato per lo sviluppo di applicazioni JavaScript sia lato client che lato server.

Inoltre, TypeScript, consente di facilitare il lavoro di gruppo, di aumentarne la velocità e di migliorare la manutenibilità dell’intero progetto, nonchè la confidenza degli sviluppatori con il codice.

Se sei qui, vuol dire che ne hai sicuramente sentito parlare. La sua popolarità è cresciuta negli ultimi anni anche grazie all’adozione da parte di alcuni importanti framework di sviluppo e in un gran quantitativo di librerie su npm.

Non credo che TypeScript possa essere l’unica risposta per migliorare l’intero ecosistema di sviluppo JavaScript, ma ne è sicuramente un valido strumento.

Non sei convinto? Provare è l’unico modo per farsi un’idea propria. Perchè non oggi?

TypeScript
Vantaggi e svantaggi
Scenari utilizzo

Post precedenti