Perché TypeScript è il futuro del web development(e sì, a volte ti fa anche imprecare)

Te la metto così: finché il progetto è piccolo, JavaScript è una goduria. Scrivi, refresh, funziona.

Poi arriva il momento in cui il repo diventa un "coso" con:

• Next.js per il frontend (App Router)
• Node 20 dietro (o edge functions)
• un monorepo con pnpm + (Turborepo/Nx)
• API che passano da REST a tRPC o viceversa
• schema in Prisma
• validazione con Zod
• test con Vitest
• e dieci persone che toccano gli stessi file

Ed è lì che JavaScript, da solo, inizia a lasciarti scoperto. TypeScript invece ti mette una rete sotto. Non perché "è figo", ma perché ti evita ore buttate.

La scena che (quasi) tutti abbiamo vissuto

Hai presente quando rinomini una proprietà in un DTO? Tipo userId → id. Tu la cambi "dove serve", fai due ricerche nel codice, i test passano… e in produzione compare un bug in una pagina che non apri da settimane.

Non è un bug "misterioso". È il classico: da qualche parte qualcuno si aspettava ancora userId. Con TypeScript, quel qualcuno… te lo dice il compilatore. Non quando un utente ti scrive "non va", ma mentre stai ancora salvando il file.

Il punto non è "mettere i tipi": è rendere refactor e manutenzione una cosa normale

La promessa reale di TypeScript non è "meno bug" in astratto. È più concreta:

• refactor più coraggiosi (e più veloci)
• contratti chiari tra componenti, servizi e librerie
• editor che smette di essere un bloc-notes e diventa un copilota serio (autocomplete, jump-to-definition, rename che non rompe tutto)

E questa roba diventa vitale appena smetti di avere "un progetto" e inizi ad avere un prodotto che vive anni.

L'adozione graduale è la cosa più sottovalutata (soprattutto nei legacy)

Una cosa che vedo spesso nei team: "TS è bello, ma migrare tutto è impossibile". E invece puoi iniziare senza migrare tutto:

• Type-check anche nei file .js con JSDoc
• converti solo i moduli più critici (API client, shared types, form complesse)
• lasci intatto quello che non vale la pena toccare

Questo approccio "a macchie" funziona bene in stack reali: un po' di legacy, un po' di nuovo, un po' di "non tocchiamo quel file che porta sfortuna".

Una posizione opinabile (ma onesta): TypeScript può diventare una religione, e lì fa danni

Ora, parte scomoda: TypeScript non è automaticamente sinonimo di qualità.

Se inizi a scrivere tipi come se stessi facendo origami con i generics, puoi finire con:

• tipi lunghi tre schermate
• errori incomprensibili
• gente che bypassa tutto con as any "perché devo consegnare"

Dove investo davvero:

• ai confini del sistema (API, DB, input utente)
• su modelli e payload che girano ovunque
• su refactor "pericolosi"

Dove non mi impicco:

• su micro-ottimizzazioni tipologiche che capiamo solo in due

E sì: a volte TypeScript ti fa perdere mezz'ora per una cosa che "a occhio era ovvia". Succede. Ma spesso quella mezz'ora la recuperi dieci volte dopo.

Esempio minuscolo (non scontato): config tipizzata + validata

Questo è un pattern che torna continuamente in Node/Next: leggere env vars, validarle, e poi usarle senza paura. In JavaScript ti fidi, poi crasha. In TypeScript fai pace tra runtime e tipi.

import { z } from "zod";

// 1) Validazione a runtime (quello che TS NON può fare da solo)
const EnvSchema = z.object({
  NODE_ENV: z.enum(["development", "test", "production"]),
  API_BASE_URL: z.string().url(),
  FEATURE_FLAGS: z
    .string()
    .default("")
    .transform(s => new Set(s.split(",").filter(Boolean))),
});

// 2) Env "sicuro": se manca qualcosa, fallisce subito
export const env = EnvSchema.parse(process.env);

// 3) Tipi inferiti automaticamente
export const isFeatureOn = (flag: string) => env.FEATURE_FLAGS.has(flag);

Questo non è "tipi per sport": è prevenire bug reali tipo API_BASE_URL=htp://... che ti rompono metà app nel modo più stupido possibile.

Perché dico che è "il futuro" (e non solo un trend)

Perché il web moderno sta andando in una direzione precisa:

• più complessità
• più integrazioni
• più riuso di componenti e pacchetti
• più team

In quel contesto, TypeScript non è una moda: è un modo pragmatico per scalare senza trasformare ogni release in una lotteria.

E poi diciamolo: quando ti abitui a fare rename symbol e vedere tutto allinearsi senza tremare… tornare indietro è dura.