fix(blog): glossary refactor terms in 2023 labs post

Signed-off-by: Alessandro De Blasis <alex@deblasis.net>
Co-authored-by: Cursor <cursoragent@cursor.com>

Author: deblasis

src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md

@@ -72,13 +72,13 @@ Il problema è che React a volte può essere *troppo* reattivo: può ri-renderiz
 
 Il nostro obiettivo con React Forget è assicurare che le app React abbiano di default la giusta quantità di reattività: che le app ri-renderizzino solo quando i valori di state cambiano in modo *significativo*. Dal punto di vista dell'implementazione significa memoizzare automaticamente, ma crediamo che l'inquadratura della reattività sia un modo migliore di capire React e Forget. Un modo di pensarci è che React attualmente ri-renderizza quando cambia l'identità dell'oggetto. Con Forget, React ri-renderizza quando cambia il valore semantico — senza il costo runtime di confronti profondi.
 
-In termini di progressi concreti, dall'ultimo aggiornamento abbiamo iterato sostanzialmente sul design del compilatore per allinearlo a questo approccio di reattività automatica e incorporare feedback dall'uso interno del compilatore. Dopo refactor significativi al compilatore a fine scorso anno, abbiamo iniziato a usarlo in produzione in aree limitate in Meta. Prevediamo di open-sourcarlo una volta provato in produzione.
+In termini di progressi concreti, dall'ultimo aggiornamento abbiamo iterato sostanzialmente sul design del compilatore per allinearlo a questo approccio di reattività automatica e incorporare feedback dall'uso interno del compilatore. Dopo rifattorizzazioni significative al compilatore a fine scorso anno, abbiamo iniziato a usarlo in produzione in aree limitate in Meta. Prevediamo di open-sourcarlo una volta provato in produzione.
 
 Infine, molte persone hanno espresso interesse su come funziona il compilatore. Non vediamo l'ora di condividere molti più dettagli quando avremo provato il compilatore e lo open-sourceremo. Ma ci sono alcuni punti che possiamo condividere ora:
 
 Il core del compilatore è quasi completamente disaccoppiato da Babel, e l'API core del compilatore è (approssimativamente) old AST in, new AST out (mantenendo i dati di posizione nel sorgente). Sotto il cofano usiamo una rappresentazione del codice custom e una pipeline di trasformazione per fare analisi semantica a basso livello. Tuttavia, l'interfaccia pubblica principale al compilatore sarà tramite Babel e altri plugin del build system. Per facilitare i test abbiamo attualmente un plugin Babel che è un wrapper molto sottile che chiama il compilatore per generare una nuova versione di ogni funzione e sostituirla.
 
-Mentre refactoravamo il compilatore negli ultimi mesi, volevamo concentrarci sul perfezionare il modello di compilazione core per assicurarci di gestire complessità come condizionali, loop, riassegnazioni e mutazioni. Tuttavia JavaScript ha molti modi di esprimere ciascuna di queste funzionalità: if/else, ternari, for, for-in, for-of, ecc. Cercare di supportare l'intero linguaggio fin dall'inizio avrebbe ritardato il punto in cui avremmo potuto validare il modello core. Invece abbiamo iniziato con un sottoinsieme piccolo ma rappresentativo del linguaggio: let/const, if/else, for loop, oggetti, array, primitivi, chiamate di funzione e altre poche funzionalità. Man mano che acquisivamo fiducia nel modello core e perfezionavamo le nostre astrazioni interne, abbiamo espanso il sottoinsieme supportato. Siamo anche espliciti sulla sintassi non ancora supportata, loggando diagnostiche e saltando la compilazione per input non supportato. Abbiamo utility per provare il compilatore sui codebase Meta e vedere quali funzionalità non supportate sono più comuni così da prioritizzarle. Continueremo ad espandere incrementalmente verso il supporto dell'intero linguaggio.
+Mentre rifattorizzavamo il compilatore negli ultimi mesi, volevamo concentrarci sul perfezionare il modello di compilazione core per assicurarci di gestire complessità come condizionali, loop, riassegnazioni e mutazioni. Tuttavia JavaScript ha molti modi di esprimere ciascuna di queste funzionalità: if/else, ternari, for, for-in, for-of, ecc. Cercare di supportare l'intero linguaggio fin dall'inizio avrebbe ritardato il punto in cui avremmo potuto validare il modello core. Invece abbiamo iniziato con un sottoinsieme piccolo ma rappresentativo del linguaggio: let/const, if/else, for loop, oggetti, array, primitivi, chiamate di funzione e altre poche funzionalità. Man mano che acquisivamo fiducia nel modello core e perfezionavamo le nostre astrazioni interne, abbiamo espanso il sottoinsieme supportato. Siamo anche espliciti sulla sintassi non ancora supportata, loggando diagnostiche e saltando la compilazione per input non supportato. Abbiamo utility per provare il compilatore sui codebase Meta e vedere quali funzionalità non supportate sono più comuni così da prioritizzarle. Continueremo ad espandere incrementalmente verso il supporto dell'intero linguaggio.
 
 Rendere reattivo il JavaScript semplice nei componenti React richiede un compilatore con profonda comprensione della semantica così da capire esattamente cosa fa il codice. Con questo approccio stiamo creando un sistema di reattività in JavaScript che ti permette di scrivere codice di prodotto di qualsiasi complessità con la piena espressività del linguaggio, invece di essere limitati a un domain specific language.