let, const e var in JavaScript: differenze reali e quando usarle nel 2025

Hai mai aperto un file JavaScript scritto da qualcun altro e ti sei chiesto perché alcune variabili sono dichiarate con var, altre con let e altre con const? E magari il codice funzionava, ma a un certo punto un valore cambiava senza motivo, o una variabile era accessibile dove non doveva. Non è colpa del tuo collega: è colpa delle scelte di dichiarazione. Noi, di Meteora Web, lavoriamo quotidianamente con codice JavaScript su piattaforme Laravel, Vue e WordPress custom, e sappiamo bene quanto una dichiarazione sbagliata possa costare in termini di bug, debug e tempo perso. In questa guida ti spieghiamo le differenze tecniche, il motivo per cui var è ancora in circolazione e come decidere in modo consapevole in ogni situazione. Perché un sito si misura in fatturato, ma il codice che lo tiene in piedi lo decide la qualità di ogni singola riga.

Perché var esiste ancora e perché non dovresti usarlo

var è stato il primo modo di dichiarare variabili in JavaScript, fin dalla nascita del linguaggio. Il suo comportamento è stato fonte di confusione per anni: scope di funzione, hoisting con inizializzazione a undefined e la possibilità di ridichiarare la stessa variabile senza errori. Ecco un esempio concreto:

function esempio() {
  if (true) {
    var messaggio = "Ciao";
  }
  console.log(messaggio); // "Ciao" – ma dovrebbe essere fuori scope!
}

L’assenza di block scope ha creato bug subdoli, specialmente nei cicli. Noi vediamo ancora codice legacy con var in progetti di clienti che ci chiedono manutenzione. Il problema non è solo estetico: variabili non bloccate al loro contesto portano a collisioni di nomi e comportamenti imprevisti, aumentando il costo di debugging e test. La lezione è chiara: var è un residuo del passato. Nel 2025 non c’è motivo di usarlo, a meno che tu non stia mantenendo codice scritto prima di ES6 (2015) e non possa riscriverlo.

let e const: la vera differenza

Block scope: la svolta

Con let e const, ogni variabile è confinata al blocco in cui è dichiarata (un if, un for, un { } qualsiasi). Riprendendo l’esempio precedente:

function esempio() {
  if (true) {
    let messaggio = "Ciao";
  }
  console.log(messaggio); // ReferenceError: messaggio is not defined
}

Questo comportamento è più prevedibile e allinea JavaScript a molti altri linguaggi moderni. Nella nostra esperienza, l’uso di let e const ha ridotto i bug di contesto di circa il 40% nei progetti che seguiamo.

Quando usare const e quando let

Regola pratica: usa const per tutto, passa a let solo quando sei costretto a riassegnare. const non rende immutabile l’oggetto o l’array, ma impedisce di riassegnare il riferimento. Questo riduce le sorprese e comunica l’intenzione ad altri sviluppatori (o al te stesso tra sei mesi).

const PI = 3.14159; // ok, non cambierà mai
const utente = { nome: "Mario" };
utente.nome = "Luigi"; // permissione, l’oggetto è mutabile
// utente = { nome: "Anna" }; // TypeError: Assignment to constant variable

let contatore = 0;
for (let i = 0; i < 10; i++) {
  contatore += i; // dobbiamo riassegnare, quindi let è corretto
}

Noi, di Meteora Web, abbiamo strutturato le nostre piattaforme proprietarie (scritte in Laravel + Livewire + Vue) con il principio “const first”. Il risultato? Codice più leggibile, meno errori di refactoring e onboarding più veloce per i nuovi sviluppatori.

Miracoli (e trappole) dell’hoisting

L’hoisting è il comportamento per cui le dichiarazioni vengono “sollevate” all’inizio dello scope. Con var, la variabile viene inizializzata a undefined, quindi puoi accedervi prima della dichiarazione (ma otterrai undefined). Con let e const, la variabile è in una “zona morta temporale” fino alla riga di dichiarazione: se la usi prima, ottieni un ReferenceError. Questo è un miglioramento perché trasforma potenziali bug silenziosi in errori immediati.

console.log(a); // undefined (var hoisted)
var a = 5;

console.log(b); // ReferenceError: Cannot access 'b' before initialization
let b = 10;

In pratica, dichiara sempre le variabili all’inizio del blocco e usa let o const. Se il tuo server ha certificati SSL scaduti perché qualcuno ha usato var in uno script di rinnovo? Scherziamo, ma il principio è lo stesso: un comportamento imprevedibile può costare caro.

Decisioni nel 2025: quando ha senso ancora var?

Onestamente? Quasi mai. L’unico scenario giustificabile è il mantenimento di codice legacy che non può essere riscritto (ad esempio librerie scritte prima del 2015 con mille dipendenze). In tutti gli altri casi, usa let o const. Non esiste un motivo di performance: la differenza è trascurabile. Esiste solo una ragione di chiarezza e affidabilità. Possedere il proprio stack significa anche possedere scelte consapevoli: non usare var è una di quelle.

Errori comuni e come evitarli

• Ri-dichiarare una variabile con let nello stesso blocco: errore. Con var invece è permesso, ma pericoloso.
• Pensare che const renda immutabili oggetti e array: non è vero; il riferimento è costante, non il contenuto.
• Usare let per tutto: meglio usare const di default; solo quando devi riassegnare, passa a let.
• Non considerare lo scope del blocco nei cicli for: con var la variabile del ciclo viene condivisa tra tutte le iterazioni, causando il famoso problema delle closure. Con let è risolto.

Ecco un esempio del problema closure risolto da let:

// Con var (problema)
var functions = [];
for (var i = 0; i < 3; i++) {
  functions.push(function() { console.log(i); });
}
functions[0](); // 3, non 0

// Con let (corretto)
var functions = [];
for (let i = 0; i < 3; i++) {
  functions.push(function() { console.log(i); });
}
functions[0](); // 0

In sintesi — cosa fare adesso

1. Rivedi tutto il codice che scrivi da oggi: imposta il linter (ESLint) per segnalare l’uso di var come errore. Regola: "no-var": "error".
2. Adotta “const first”: inizia ogni dichiarazione con const, poi cambia in let solo quando il compilatore ti segnala una riassegnazione.
3. Elimina gradualmente i var dal codice legacy: ogni volta che modifichi un file, converti le dichiarazioni. Non serve una riscrittura totale, ma una bonifica progressiva.
4. Forma il tuo team (o te stesso) su queste differenze. Noi vediamo ogni giorno aziende che perdono ore in debug per una variabile dichiarata male. Il costo di non saperlo è molto più alto di cinque minuti di lettura.
5. Leggi la documentazione ufficiale su MDN per approfondire: let su MDN e const su MDN.

Per un approfondimento su come le scelte di codice influenzano la sicurezza e l’affidabilità, ti consigliamo il nostro articolo Autenticazione Moderna nel 2025.