{"id":1012,"date":"2021-08-09T07:42:00","date_gmt":"2021-08-09T05:42:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/typescript-benefici-pmi-2021\/"},"modified":"2021-08-09T07:42:00","modified_gmt":"2021-08-09T05:42:00","slug":"typescript-benefici-pmi-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/typescript-benefici-pmi-2021\/","title":{"rendered":"TypeScript per aziende: la guida 2021"},"content":{"rendered":"

TypeScript<\/strong> non \u00e8 una moda passeggera: \u00e8 il linguaggio che, nel 2021, ha cambiato il modo in cui le aziende sviluppano applicazioni JavaScript. Secondo lo Stack Overflow Developer Survey 2021, il 76% degli sviluppatori che non lo usano ancora vorrebbe iniziare, e i progetti basati su TypeScript ormai rappresentano circa il 25% del mercato JavaScript globale.<\/p>\n

I typescript benefici<\/strong> sono concreti, misurabili e impattano direttamente sulla qualit\u00e0 del codice, sulla produttivit\u00e0 dei team e sui costi di manutenzione. In questa guida, pensata per developer senior, tech lead e CTO di PMI, vediamo perch\u00e9 TypeScript \u00e8 diventato lo standard de facto per lo sviluppo serio in ambito JavaScript, come si differenzia da JS puro, come introdurlo in azienda e quando ha senso usarlo.<\/p>\n

Microsoft ha rilasciato TypeScript nel 2012, ma \u00e8 dal 2018 in poi che ha conosciuto un’adozione massiva, complice anche il fatto che Angular lo usa nativamente<\/strong> dalla versione 2 e che React e Vue 3 ne supportano l’uso in modo eccellente. Con la versione 4.4 appena rilasciata (agosto 2021), TypeScript continua a evolvere con miglioramenti su control flow analysis e performance del compiler.<\/p>\n

\"Team
Team di sviluppatori che collabora su un progetto TypeScript<\/figcaption><\/figure>\n

Indice dei contenuti<\/h2>\n
    \n
  1. TypeScript: cosa \u00e8 e perch\u00e9 esiste<\/li>\n
  2. Tipizzazione statica vs dinamica<\/li>\n
  3. I 7 benefici concreti di TypeScript<\/li>\n
  4. TypeScript vs JavaScript: differenze pratiche<\/li>\n
  5. Tipi base<\/li>\n
  6. Interfaces e types<\/li>\n
  7. Generics<\/li>\n
  8. TypeScript con React, Vue, Angular<\/li>\n
  9. tsconfig.json e configurazione<\/li>\n
  10. Migrazione graduale da JS a TS<\/li>\n
  11. Errori frequenti<\/li>\n
  12. Domande frequenti<\/li>\n<\/ol>\n

    1. TypeScript: cosa \u00e8 e perch\u00e9 esiste<\/h2>\n

    TypeScript \u00e8 un superset tipizzato di JavaScript<\/strong> sviluppato e mantenuto da Microsoft. Il termine “superset” \u00e8 importante: significa che ogni programma JavaScript valido \u00e8 anche un programma TypeScript valido. TypeScript aggiunge a JavaScript un sistema di tipi statici opzionale e funzionalit\u00e0 che vengono compilate (“transpilate”) in JavaScript standard eseguibile da qualsiasi browser o runtime Node.js.<\/p>\n

    Il problema che TypeScript risolve \u00e8 preciso: JavaScript, nato nel 1995 come linguaggio di scripting per il browser, \u00e8 cresciuto fino a diventare il fondamento di applicazioni enterprise complesse, ma il suo sistema di tipi dinamico mostra limiti evidenti su codebase di centinaia di migliaia di righe. Gli errori di tipo emergono solo a runtime, il refactoring diventa rischioso, l’autocomplete dell’IDE \u00e8 approssimativo.<\/p>\n

    TypeScript nasce per portare a JavaScript ci\u00f2 che linguaggi come Java, C# o Kotlin offrono da decenni: un sistema di tipi che il compilatore pu\u00f2 verificare staticamente, intercettando classi intere di bug prima ancora di eseguire il codice.<\/p>\n

    Per approfondire gli aspetti pi\u00f9 ampi della scelta tecnologica, ti consigliamo la guida pillar sviluppo software custom per PMI<\/a>, dove analizziamo i criteri di valutazione di stack moderni.<\/p>\n

    2. Tipizzazione statica vs dinamica: il cuore della differenza<\/h2>\n

    JavaScript \u00e8 un linguaggio a tipizzazione dinamica<\/strong>: il tipo di una variabile viene determinato a runtime, e pu\u00f2 cambiare durante l’esecuzione. Questa flessibilit\u00e0 ha reso JS rapido da imparare e adatto allo scripting, ma \u00e8 anche la causa di molti bug subdoli.<\/p>\n

    Considera questo esempio JavaScript:<\/p>\n

    function calcolaTotale(prezzo, quantita) {\n  return prezzo * quantita;\n}\n\ncalcolaTotale(\"10\", 3);  \/\/ restituisce \"101010\" \u2014 concatenazione di stringhe!<\/code><\/pre>\n
    JavaScript non si lamenta: moltiplica una stringa per un numero applicando coercion implicita, e produce un risultato semanticamente sbagliato. L’errore emerge solo quando un utente nota un prezzo strano sul carrello.<\/p>\n
    Lo stesso codice in TypeScript:<\/p>\n
    function calcolaTotale(prezzo: number, quantita: number): number {\n  return prezzo * quantita;\n}\n\ncalcolaTotale(\"10\", 3);  \/\/ ERRORE: Argument of type 'string' is not assignable to parameter of type 'number'<\/code><\/pre>\n
    Il compilatore TypeScript<\/strong> (tsc) blocca la compilazione e segnala l’errore esattamente sulla riga problematica. Il bug non arriva mai in produzione. \u00c8 questo il principio della tipizzazione statica<\/strong>: i tipi sono noti e verificati al momento della scrittura del codice, non durante l’esecuzione.<\/p>\n
    3. I 7 benefici concreti di TypeScript<\/h2>\n
    Vediamo nel dettaglio quali sono i vantaggi misurabili che spingono sempre pi\u00f9 aziende \u2014 incluse molte PMI che sviluppano web app e PWA<\/a> custom \u2014 ad adottare TypeScript.<\/p>\n
    3.1. Cattura precoce degli errori<\/h3>\n
    Uno studio pubblicato nel 2017 (“To Type or Not to Type”) ha analizzato bug fix nei repository GitHub e ha stimato che il 15% dei bug in JavaScript public sarebbe stato intercettato da TypeScript<\/strong>. Per progetti aziendali con logica di dominio complessa, la percentuale \u00e8 probabilmente pi\u00f9 alta.<\/p>\n
    3.2. Autocomplete intelligente<\/h3>\n
    Con tipi espliciti, l’IDE (in particolare VSCode, sviluppato anch’esso da Microsoft) sa esattamente quali metodi e propriet\u00e0 sono disponibili su ogni oggetto. L’autocomplete diventa preciso, riducendo i tempi di sviluppo e i typo.<\/p>\n
    3.3. Refactoring sicuro<\/h3>\n
    Rinominare un metodo in una codebase JavaScript \u00e8 un atto di fede: si fa search-and-replace e si spera che i test coprano i casi rotti. In TypeScript, il rename \u00e8 un’operazione sicura: il compilatore segnala ogni punto di rottura immediatamente.<\/p>\n
    3.4. Scalabilit\u00e0 del team<\/h3>\n
    Su progetti con 5+ developer, TypeScript funziona da contratto formale tra moduli. Un developer che modifica una funzione esposta sa esattamente cosa accade ai chiamanti perch\u00e9 il sistema di tipi rende esplicite le dipendenze.<\/p>\n
    \"Schermo
    Codice TypeScript con syntax highlighting in editor moderno<\/figcaption><\/figure>\n
    3.5. Documentazione vivente<\/h3>\n
    I tipi sono documentazione che non pu\u00f2 andare fuori sincrono con il codice. Una funzione con firma function getUser(id: number): Promise<User><\/code> dice tutto quello che serve sapere: cosa accetta, cosa restituisce, ed \u00e8 verificabile dal compilatore.<\/p>\n
    3.6. Onboarding pi\u00f9 rapido<\/h3>\n
    Un nuovo developer che entra in un progetto TypeScript pu\u00f2 navigare il codice con il “Go to Definition” e capire tipi e contratti senza dover decifrare commenti obsoleti o leggere implementazioni intere.<\/p>\n
    3.7. Qualit\u00e0 del codice<\/h3>\n
    I tipi spingono naturalmente verso architetture pi\u00f9 pulite: interfacce esplicite, separazione di responsabilit\u00e0, gestione esplicita dei valori null\/undefined (con strictNullChecks<\/code>). Il risultato \u00e8 codice pi\u00f9 mantenibile a lungo termine.<\/p>\n
    4. TypeScript vs JavaScript: differenze pratiche<\/h2>\n
    Quando si parla di typescript vs javascript<\/strong>, \u00e8 importante chiarire che TypeScript non sostituisce JavaScript: lo arricchisce. Vediamo le differenze pratiche pi\u00f9 rilevanti per chi deve decidere se introdurlo in azienda:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    Aspetto<\/th>\nJavaScript<\/th>\nTypeScript<\/th>\n<\/tr>\n<\/thead>\n
    Sistema di tipi<\/td>\nDinamico, runtime<\/td>\nStatico, compile-time<\/td>\n<\/tr>\n
    Strumenti necessari<\/td>\nNessuno (browser\/Node)<\/td>\nCompilatore tsc<\/td>\n<\/tr>\n
    Curva di apprendimento<\/td>\nBassa<\/td>\nMedia (per chi conosce JS)<\/td>\n<\/tr>\n
    Refactoring<\/td>\nRischioso<\/td>\nSicuro e guidato<\/td>\n<\/tr>\n
    Errori di tipo<\/td>\nA runtime<\/td>\nIn compilazione<\/td>\n<\/tr>\n
    Velocit\u00e0 sviluppo iniziale<\/td>\nPi\u00f9 rapida<\/td>\nLeggermente pi\u00f9 lenta<\/td>\n<\/tr>\n
    Manutenibilit\u00e0 a lungo termine<\/td>\nDifficile su grandi codebase<\/td>\nEccellente<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    La sintesi: per uno script di 200 righe, JavaScript va benissimo. Per un’applicazione enterprise, una integrazione API<\/a> mission-critical o un gestionale personalizzato<\/a>, TypeScript ripaga l’investimento iniziale moltiplicato per anni di manutenzione.<\/p>\n
    5. Tipi base: string, number, boolean, array, object, any<\/h2>\n
    I tipi primitivi di TypeScript ricalcano quelli di JavaScript:<\/p>\n
    let nome: string = \"Mario\";\nlet eta: number = 35;\nlet attivo: boolean = true;\nlet ruoli: string[] = [\"admin\", \"editor\"];\nlet utente: { id: number; email: string } = { id: 1, email: \"a@b.it\" };\n\n\/\/ Type inference: TS deduce il tipo da solo\nlet citta = \"Roma\";  \/\/ inferito come string\ncitta = 42;          \/\/ ERRORE<\/code><\/pre>\n
    Il tipo any<\/code> disabilita il type checking e va usato solo come “via di fuga” temporanea. Una codebase TS sana ha pochissimi any<\/code>; al loro posto si usano unknown<\/code> (pi\u00f9 sicuro) o tipi specifici.<\/p>\n
    Esistono anche void<\/code> (funzioni senza return), never<\/code> (funzioni che lanciano sempre eccezioni), null<\/code> e undefined<\/code>. Con l’opzione strictNullChecks<\/code> attiva, TypeScript distingue rigorosamente tra valori potenzialmente null\/undefined e valori sempre definiti, prevenendo il classico bug “Cannot read property of undefined”.<\/p>\n
    6. Interfaces e types: dare forma agli oggetti<\/h2>\n
    La tipizzazione statica js<\/strong> con TypeScript brilla quando si descrivono strutture dati complesse. Per questo esistono interface<\/code> e type<\/code>:<\/p>\n
    interface Utente {\n  id: number;\n  email: string;\n  nome?: string;        \/\/ opzionale\n  readonly createdAt: Date;  \/\/ immutabile\n}\n\ntype RuoloUtente = \"admin\" | \"editor\" | \"viewer\";  \/\/ union type\n\nfunction creaUtente(dati: Utente, ruolo: RuoloUtente): Utente {\n  return { ...dati, createdAt: new Date() };\n}<\/code><\/pre>\n
    Le interface<\/code> sono pensate per descrivere “forma” di oggetti e supportano l’estensione (extends<\/code>) e la dichiarazione multipla (declaration merging). I type<\/code> sono pi\u00f9 flessibili e supportano union, intersection e tipi mappati.<\/p>\n
    Una regola pratica diffusa nei team: usa interface<\/code> per le forme di oggetti pubblici, type<\/code> per union, intersection e alias<\/strong>. Entrambi sono validi e in molti casi intercambiabili.<\/p>\n
    7. Generics: il superpotere di TypeScript<\/h2>\n
    I generics<\/strong> sono ci\u00f2 che separa TypeScript da una semplice “annotazione di tipi” e lo rende un sistema di tipi avanzato. Permettono di scrivere componenti riutilizzabili che funzionano con qualsiasi tipo, mantenendo la type safety.<\/p>\n
    function primo<T>(array: T[]): T | undefined {\n  return array[0];\n}\n\nconst numero = primo([1, 2, 3]);        \/\/ tipo: number | undefined\nconst parola = primo([\"a\", \"b\", \"c\"]);  \/\/ tipo: string | undefined<\/code><\/pre>\n
    I generics sono ovunque: nelle Promise (Promise<User><\/code>), negli array (Array<number><\/code>), nei Map, nei componenti React (React.FC<Props><\/code>). Padroneggiarli \u00e8 il salto qualitativo che trasforma un developer “che usa TypeScript” in uno “che pensa in TypeScript”.<\/p>\n
    Per casi avanzati, TypeScript offre anche conditional types<\/strong>, mapped types<\/strong> e template literal types<\/strong> (introdotti nella 4.1), che permettono di esprimere relazioni complesse tra tipi a livello di compilatore.<\/p>\n
    \"Frontend
    Frontend developer al lavoro su componenti React in TypeScript<\/figcaption><\/figure>\n
    8. TypeScript con React, Vue e Angular nel 2021<\/h2>\n
    L’ecosistema frontend nel 2021 ha abbracciato TypeScript in modo praticamente universale.<\/p>\n
    Angular<\/h3>\n
    Angular (di Google) \u00e8 scritto in TypeScript ed \u00e8 il framework pi\u00f9 “TS-first”: ogni progetto Angular nasce con TypeScript di default. Decoratori, dependency injection e moduli sfruttano il sistema di tipi pesantemente.<\/p>\n
    React<\/h3>\n
    React non impone TypeScript, ma il supporto \u00e8 eccellente. Create React App offre un template TS pronto (npx create-react-app my-app --template typescript<\/code>). Componenti funzionali, hooks (useState<T><\/code>), Context API: tutto si tipizza in modo elegante.<\/p>\n
    Vue<\/h3>\n
    Vue 3, rilasciato a fine 2020, \u00e8 stato riscritto interamente in TypeScript e offre un’esperienza eccellente con la Composition API. Il supporto in Vue 2 era pi\u00f9 limitato; Vue 3 chiude il gap con React.<\/p>\n
    Anche framework backend come NestJS<\/strong> (basato su Node.js, ispirato ad Angular) e ORM moderni come TypeORM<\/strong> e Prisma<\/strong> usano TypeScript come scelta primaria. Per progetti di automazione<\/a> backend o full-stack, lo stack TS \u00e8 ormai una scelta naturale.<\/p>\n
    8.1. TypeScript con Node.js e backend<\/h2>\n
    Sul lato server, TypeScript ha conquistato un ruolo dominante in ecosistemi Node.js moderni. Express resta il framework pi\u00f9 diffuso e si tipizza facilmente con @types\/express<\/code>. NestJS, ispirato all’architettura di Angular, offre dependency injection, decoratori e modularit\u00e0 native in TypeScript ed \u00e8 una scelta crescente per applicazioni enterprise.<\/p>\n
    Per la persistenza dati, ORM come TypeORM<\/strong>, Sequelize<\/strong> e (dal 2021) Prisma<\/strong> generano modelli typed automaticamente dallo schema database, fornendo autocomplete e type checking sulle query. \u00c8 un cambiamento qualitativo enorme rispetto al SQL grezzo o ai query builder non tipizzati.<\/p>\n
    Anche AWS Lambda, Cloudflare Workers e altre piattaforme serverless offrono runtime Node.js compatibili con TypeScript, abbassando le barriere all’adozione anche su architetture moderne distribuite.<\/p>\n
    9. tsconfig.json e configurazione<\/h2>\n
    Il file tsconfig.json<\/code> \u00e8 il cuore di ogni progetto TypeScript. Definisce quali file compilare, in che target ECMAScript trasformarli e quali check applicare.<\/p>\n
    {\n  \"compilerOptions\": {\n    \"target\": \"ES2020\",\n    \"module\": \"ESNext\",\n    \"moduleResolution\": \"node\",\n    \"strict\": true,\n    \"esModuleInterop\": true,\n    \"skipLibCheck\": true,\n    \"forceConsistentCasingInFileNames\": true,\n    \"outDir\": \".\/dist\",\n    \"sourceMap\": true\n  },\n  \"include\": [\"src\/**\/*\"],\n  \"exclude\": [\"node_modules\", \"dist\"]\n}<\/code><\/pre>\n
    L’opzione strict: true<\/code><\/strong> \u00e8 fondamentale: attiva tutti i check rigorosi (strictNullChecks<\/code>, noImplicitAny<\/code>, strictFunctionTypes<\/code>) ed \u00e8 ci\u00f2 che separa un progetto “TS serio” da uno che usa TypeScript come JavaScript con annotazioni.<\/p>\n
    Per progetti nuovi, partire con strict: true<\/code> \u00e8 la regola d’oro. Per migrazioni da JavaScript, conviene attivare i check progressivamente.<\/p>\n
    10. Migrazione graduale da JavaScript a TypeScript<\/h2>\n
    Una delle qualit\u00e0 migliori di TypeScript \u00e8 la possibilit\u00e0 di introdurlo gradualmente<\/strong> in una codebase JS esistente. Non serve un big bang: si pu\u00f2 procedere file per file.<\/p>\n
      \n
    1. Setup iniziale<\/strong>: installa TypeScript (npm install --save-dev typescript<\/code>), genera tsconfig.json<\/code> con npx tsc --init<\/code>, attiva allowJs: true<\/code> e checkJs: false<\/code>.<\/li>\n
    2. Rinomina file critici<\/strong>: cambia l’estensione da .js<\/code> a .ts<\/code> partendo dai moduli pi\u00f9 stabili e ad alto valore. Aggiungi tipi dove servono.<\/li>\n
    3. Tipizza le librerie esterne<\/strong>: installa i type definitions DefinitelyTyped (npm install --save-dev @types\/node @types\/lodash<\/code>).<\/li>\n
    4. Attiva strict gradualmente<\/strong>: prima noImplicitAny<\/code>, poi strictNullChecks<\/code>, poi gli altri.<\/li>\n
    5. Imponi TS sul nuovo codice<\/strong>: nuove feature solo in TypeScript. Questa policy by default ferma il debito tecnico.<\/li>\n<\/ol>\n
      Aziende come Slack, Airbnb, Bloomberg, Microsoft (ovviamente) e molte altre hanno migrato codebase di milioni di righe a TypeScript con questo approccio incrementale. Il ROI emerge dopo i primi 6-12 mesi di adozione.<\/p>\n
      10.1. ROI della migrazione: cosa aspettarsi<\/h2>\n
      Una domanda ricorrente da parte di tech lead e CTO \u00e8: quanto tempo serve perch\u00e9 TypeScript ripaghi l’investimento?<\/em> La risposta dipende da fattori specifici (dimensione del team, complessit\u00e0 del dominio, qualit\u00e0 del codice JS di partenza), ma in base alle esperienze documentate nel 2020-2021 emergono pattern ricorrenti.<\/p>\n