Update article.md

Definitivo

Author: pierangelomiceli

2-ui/99-ui-misc/03-event-loop/article.md

@@ -3,20 +3,20 @@
 
 Sia il flusso di esecuzione di Javascript, che quello di Node.js, sono basati sull' *event loop*.
 
-Comprendere come funziona un event loop è importante sia per una question di ottimizzazione dell'esecuzione del codice, ma a volte, anche per creare delle architetture migliori.
+Comprendere come funziona un event loop è importante sia per una questione di ottimizzazione dell'esecuzione del codice, ma a volte, anche per creare delle architetture software migliori.
 
-In questo capitolo affronteremo l dettagli teorici sul funzionanento, dopodichè prenderemo in esame alcune applicazioni pratiche.
+In questo capitolo affronteremo i dettagli teorici sul funzionanento, dopodichè prenderemo in esame alcune applicazioni pratiche.
 
 ## Event Loop
 
-Il concetto di *event loop* è molto semplice. Esiste un loop infinito, nel quale il motore di Javascript rimane in attesa di un task (compito, operazione) da eseguire, lo esegue, dopodichè si rimette in attesa per altri tasks. (rimane in sleep, inattivo o dormiente, ma pronto per essere di nuovo richiamato). 
+Il concetto di *event loop* è molto semplice. Esiste un loop infinito, nel quale il motore di Javascript rimane in attesa di un task (compito o operazione da eseguire), lo esegue, quindi si mette in attesa per altri tasks (rimane in sleep, inattivo o dormiente, ma pronto per essere di nuovo richiamato). 
 
 A grandi linee, l'algoritmo del motore è così:
 1. Fino a quando ci sono task:
     - eseguili, cominciando da quello meno recente.
 2. Rimani in attesa fino a quando non c'è un altro task da eseguire, quindi vai al passo 1.
 
-Questa è una trasposizione di quello che vediamo quando navighiamo in una pagina web. Il motore di Javascript non fa nulla per la maggior parte del tempo, e va in esecuzione quando si attiva uno script/handler/evento.
+Questa è una trasposizione di quello che vediamo mentre navighiamo in una pagina web. Il motore di Javascript non fa nulla per la maggior parte del tempo, e va in esecuzione quando si attiva uno script/handler/evento.
 
 Esempio di tasks:
 
@@ -44,30 +44,30 @@ Ancora due dettagli:
 1. Il rendering non avviene mai quando il motore sta eseguendo un task. Non importa se questo impiega molto tempo. I cambiamenti al DOM vengono renderizzati (ridisegnati sul browser) solo dopo che il task viene completato.
 2. Se un task impiega troppo tempo, il browser non puiò eseguire altri tasks, processare altri eventi utente, e così dopo un certo periodo di tempo viene scaturito un alert di "Pagina bloccata" (Page Unresponsive) che ci suggerisce di terminare il task e l'intera pagina. Questo succede in concomitanza di una serie di calcoli complessi, o in seguito ad errori di programmazione che portano loop infiniti.
 
-Questa era la teoria, ma vediamo come applicare questi concetti.
+Ok, questa era la teoria, ma vediamo come mettere in pratica questi concetti.
 
 ## Caso d'uso 1: Spezzettamento di task affamati di CPU (processi intensivi)
 
-Poniamo il caso che abbiamo un task affamato di CPU.
+Poniamo il caso che abbiamo un task affamato di CPU (CPU-hungry process).
 
 Per esempio, la syntax-highlighting (usata per colorare ed evidenziare gli esempi del codice in questa pagina) è abbastanza pesante per la CPU.
 Per evidenziare il codice, compie delle analisi, crea molti elementi colorati, e li aggiunge al documento -- un testo di grosse dimensioni può impiegare molto tempo.
 
-Mentre il motore è occupato con l'evidenziatura, non può fare le altre cose relative al DOM, processare gli eventi dell'utente, etc. può persino causare "singhiozzamenti" al pc o addirittura "inchiodarlo", la qual cosa è inaccettabile.
+Mentre il motore è occupato con l'evidenziatura, non può fare altre cose relative al DOM, processare gli eventi dell'utente, etc. può, può  persino causare "singhiozzamenti" al pc o addirittura "inchiodarlo", la qual cosa è inaccettabile.
 
-Possiamo quindi tirarci fuori da questo tipo di problemi, spezzettando i task grossi in piccoli pezzi. Evidenzia le prime 100 righe, quindi schedula un `setTimeout` (con zero-delay) con altre 100 righe, e così via fino alla fine.
+Possiamo quindi tirarci fuori da questo tipo di problemi, spezzettando i task grossi in piccoli pezzi da eseguire. Evidenzia le prime 100 righe, quindi schedula un `setTimeout` (con zero-delay) con altre 100 righe, e così via fino alla fine.
 
 Per dimostrare questo tipo di approccio, e per amore della semplicità, anzichè evidenziare una sintassi, prendiamo una funzione che conti i numeri da `1` a `1000000000`
 
-Se esegui il codice sotto, il motore si inchioderà per qualche istante. Per il JS server-side (lato server) questo è chiaramente visibile, ma se lo stai eseguendo nella finestra del browser, provando a cliccare gli altri pulsanti -- potrai notare che non verrà gestito nessun altro evento fino a quando il conto non sarà terminato.
+Se esegui il codice sotto, il motore si inchioderà per qualche istante. Per il JS server-side (lato server) questo è chiaramente visibile, ma se lo stai eseguendo nella finestra del browser, provando a cliccare gli altri pulsanti -- potrai notare che non verrà gestito nessun altro evento fino a quando il conteggio dei numeri non sarà terminato.
 
 ```js run
 let i = 0;
 
 let start = Date.now();
 
 function count() {
-  //fa un lavoro pesante!
+  //un lavoro pesante!
   for (let j = 0; j < 1e9; j++) {
     i++;
   }
@@ -80,15 +80,15 @@ count();
 Il browser potrebbe anche mostrare l'avviso "lo script sta impiegando troppo tempo" the script takes too long".
 
 
-Ora, dividiamo l'operazione con l'ausilio di un `setTimeout` annidato:
+Ora invece, dividiamo l'operazione con l'ausilio di un `setTimeout` annidato:
 
 ```js run
 let i = 0;
 
 let start = Date.now();
 
 function count() {
-  //fai una parte del lavoro pesante (*)
+  //fai una parte del lavoro pesante :-) (*)
   do {
     i++;
   } while (i % 1e6 != 0);
@@ -110,13 +110,13 @@ Una singola esecuzione di `count` fa una parte dell'operazione `(*)`, e rischedu
 2. La seconda esecuzione conta: `i=1000001..2000000`.
 3. ...e cos&igrave; via.
 
-Ora, se arriva un nuovo task da eseguire mentre il motore &egrave; occupato ad eseguire il passo 1 (ad esempio un evento `onclick`), quest'ultimo viene messo in coda e viene eseguito subito dopo il completamento del passo 1, e subito prima del passo successivo. Questi periodici "ritorni" all'event loop tra una esecuzione di  `count` e l'altra, fornisce abbastanza "aria" al motore Javascript per occuparsi di qualcos'altro, ad esempio per reagire alle azioni degli utenti.
+Ora, se arriva un nuovo task da eseguire mentre il motore &egrave; occupato ad eseguire il passo 1, poniamo il caso ad esempio che venga sollevato un evento `onclick`, quest'ultimo viene messo in coda ed eseguito subito dopo il completamento del passo 1, ma subito prima del passo successivo. Questi periodici "ritorni" all'event loop tra una esecuzione di `count` e l'altra, fornisce abbastanza "respiro" al motore Javascript per occuparsi di qualcos'altro, ad esempio per reagire alle azioni degli utenti.
 
 La cosa ragguardevole &egrave; che entrambe le varianti -- con e senza la divsione del lavoro di `setTimeout` -- sono comparabili in termini di tempo. Complessivamente, non esiste molta differenza nel tempo di conteggio.
 
-Per renderli un po' pi&ugrave; facciamo un miglioramento.
+Per renderli un po' pi&ugrave; più comparabili, facciamo un miglioramento.
 
-Posizioneremo la schedualzione all'inizio del `count()`:
+Posizioniamo la schedulazione all'inizio del `count()`:
 
 
 ```js run
@@ -139,25 +139,26 @@ function count() {
 count();
 ```
 
-Adesso quando cominciamo con `count()` e vediamo che abbiamo bisogno di richiamarlo pi&ugrave; `count()`, lo scheduliamo subito, prima di fare il lavoro.
+Adesso, quando cominciamo con `count()` e vediamo che abbiamo bisogno di richiamarlo pi&ugrave; `count()`, lo scheduliamo subito prima di fare il lavoro.
 
-Se lo esegui, &egrave; facile notare che impiega meno tempo in modo significativo.
+Se lo esegui, &egrave; facile notare che impiega significativamente meno tempo.
 
 
 Perch&egrave;?  
 
-Semplice: come ben sai, c'&egrave; un ritardo minimo di 4ms all'interno del browser per molte chiamate annidate di `setTimeout`. Anche se noi lo settiamo `0`, sar&agrave; di `4ms`  (o qualcosa in pi&ugrave). Quindi, prima lo scheduliamo, pi&ugrave; veloce sar&agrave; l'esecuzione. 
-Alla fine, abbiamo diviso un task affamato di CPU in porzioni - e adesso non bloccher&agrave; l'interfaccia utente. E il suo tempo di esecuzione complessivo non &egrave; tanto pi&ugrave; lungo.
+Semplice: come saprai, c'&egrave; un ritardo minimo di 4ms all'interno del browser per tantissime chiamate annidate di `setTimeout`. Anche se noi lo abbiamo impostato a `0`, sar&agrave; di `4ms` (o qualcosa in pi&ugrave). Quindi, prima lo scheduliamo, pi&ugrave; veloce sar&agrave; l'esecuzione. 
+Alla fine, abbiamo diviso un task affamato di CPU in porzioni - che adesso non bloccher&agrave; pi&ugrave; l'interfaccia utente. Inoltre, il suo tempo di esecuzione complessivo non &egrave; tanto pi&ugrave; lungo.
+
 
 ## Caso d'uso 2: Indicazione dei progressi di una operazione
 
-Un altro beneficio di dividere task pesanti per gli script del browser &egrave; che possiamo mostrare i progressi di completamento.
+Un altro beneficio nel dividere task pesanti per gli script del browser &egrave; che possiamo mostrare i progressi di completamento.
 
 Solitamente il browser renderizza dopo che il codice in esecuzine viene completato. Non importa se il task impiega tanto tempo. Le modifice al DOM vengono mostrate solo dopo che il task &egrave; terminato.
 
-Da una parte, questo &egrave; grandioso, perch&egrave; la nostra fuznione pu&ograve; molti elementi, aggiungerli uno alla volta al documento e cambiarne gli stili -- il visitatore non vorrebbe mai vedere uno stadio "intermedio", incompleto. Una cosa importante, giusto?
+Da una parte, questo &egrave; grandioso, perch&egrave; la nostra funzione pu&ograve; creare molti elementi, aggiungerli uno alla volta al documento e cambiarne gli stili -- il visitatore, d'altra parte, non vorrebbe mai vedere uno stadio "intermedio" ed incompleto. Una cosa importante, giusto?
 
-Qui c'&egrave; la demo, i cambiamenti a `i` non verrano mostrati fino a quando la funzione nno termina, cos&igrave; vedremo solamente l'ultimo valore:
+Con l'esempio qui sotto abbiamo una dimostrazione, le modifiche all'elemento che rappresenta i valori di `i` non verrano mostrati fino a quando la funzione non termina, cos&igrave; vedremo solamente il valore definitivo:
 
 ```html run
 <div id="progress"></div>
@@ -175,9 +176,9 @@ Qui c'&egrave; la demo, i cambiamenti a `i` non verrano mostrati fino a quando l
 </script>
 ```
 
-...Per&ograve; potremmo volere mostrare qualcosa durante il task, ad esempio una barra di progresso.
+...Tuttavia; potremmo voler mostrare qualcosa durante il task, ad esempio una barra di progresso.
 
-Se noi dividiamo il task pesante in pezzi usando `setTimeout`, allora tra essi, verranno mostrate le variazioni.
+Se andiamo a dividere il task pesante in pezzi usando `setTimeout`, allora tra ognuno di essi, verranno mostrate delle variazioni.
 
 Questo sembra pi&ugrave; carino:
 
@@ -205,21 +206,20 @@ Questo sembra pi&ugrave; carino:
 </script>
 ```
 
-Adesso il `<div>` mostra via via, valori crescenti di `i`,come se fosse una sorta di barra di caricamento.
+Adesso il `<div>` mostra valori sempre crescenti di `i`, come se fosse una sorta di barra di caricamento.
 
 
 ## Caso d'uso 3: fare qualcosa dopo l'evento
 
-In un gestore di evento, potremmo decidere di postporre alcune azioni, fino a che l'evento non risalga i vari livelli di stack (bubbling up) e non venga gestito su tutti questi livelli.
-Possiamo farlo, avvolgendo (wrapping) il codice all'interno dei `setTimeout` a ritardo zero.
+In un gestore di evento, potremmo decidere di postporre alcune azioni, fino a che l'evento non risalga i vari livelli dello stack (bubbling up) e non venga gestito su tutti questi livelli.
+Possiamo farlo, avvolgendo (wrapping) il codice all'interno di istruzioni `setTimeout` a ritardo zero.
 
-Nel capitolo <info:dispatch-events> abbiamo visto un esempio: dell'evento custom  `menu-open`, viene fatto il dispatch dentro `setTimeout`, cos&igrave; che esso viene richiamato dopo che l'evento click &egrave; stto del tutto gestito.
+Nel capitolo <info:dispatch-events> abbiamo visto un esempio: dell'evento custom  `menu-open`, viene fatto il dispatch dentro `setTimeout`, cos&igrave; che esso viene richiamato dopo che l'evento click &egrave; stato del tutto gestito.
 
 
 ```js
 menu.onclick = function() {
   // ...
-
   //crea un evento custom con l'elemento dati cliccato sul menu'
   let customEvent = new CustomEvent("menu-open", {
     bubbles: true
@@ -230,16 +230,16 @@ menu.onclick = function() {
 };
 ```
 
-## Macrotasks e Microtasks
 
+## Macrotasks e Microtasks
 
-insieme ai *macrotasks*, descritti in questo capitolo, esistono i *microtasks*, menzionati nel capitolo <info:microtask-queue>.
+Insieme ai *macrotasks*, descritti in questo capitolo, esistono i *microtasks*, menzionati nel capitolo <info:microtask-queue>.
 
-Microtasks provengono esclusivamente dal nostro codice. Solitamente vengono creati dalle promises: una esecuzione di un gestore `.then/catch/finally` diventa un  microtask. I microtasks vengono usati anche "sotto copertura" dagli `await`, dato che anche questi sono solo un'altra forma di gestione delle promise.
+I microtasks provengono esclusivamente dal nostro codice. Solitamente vengono creati dalle promises: una esecuzione di un gestore `.then/catch/finally` diventa un  microtask. I microtasks vengono usati anche "sotto copertura" dagli `await`, dato che anche questi non sono altro che un'altra forma di gestione di promises.
 
-C'&egrave; anche una funzione speciale `queueMicrotask(func)` che accoda `func`per l'esecuzione nella coda dei microtask.
+C'&egrave; anche una funzione speciale `queueMicrotask(func)` che accoda `func` per l'esecuzione nella coda dei microtask.
 
-**Immediatamente dopo ogni *macrotask*, il motore esegue tutti i task dalla coda  *microtask* queue, prima di ricominciare a eseguire ogni altro macrotask o renderizzare o qualunque altra cosa.**
+**Immediatamente dopo ogni *macrotask*, il motore esegue tutti i task dalla coda *microtask*, prima di ricominciare a eseguire ogni altro macrotask o renderizzare o qualunque altra cosa.**
 
 Per esempio, guardate questo:
 
@@ -252,24 +252,24 @@ Promise.resolve()
 alert("code");
 ```
 
-Che sta succedendo all'ordine qui?
+Cosa succeder&agrave; all'ordine delle operazioni in questo script?
 
-1. `code` viene mostrato prima, dato che &egrave; un chiamata regolare e sincrona.
+1. `code` viene mostrato per primo, dato che &egrave; un chiamata regolare e sincrona.
 2. `promise` viene mostrato per secondo, perch&egrave; `.then` passa attraverso la coda di microtask, e viene eseguito dopo il codice corrente.
 3. `timeout` viene mostrato come ultimo perch&egrave; &egrave; anhe questo un microtask.
 
-L'immagine pi&ugrave; esausitva di un event loop &egrave; &egrave; questa:
+L'immagine pi&ugrave; esausitva di un event loop &egrave; questa:
 
 ![](eventLoop-full.svg)
 
 **Tutti i microtasks vengono completati prima di ogni altra gestione degli eventi o rendering o qualunque altro macrotask che prende parte nell'esecuzione**
 
-Questo &egrave; importante perch&egrave; garantisce che l'ambiente applicativo rimanga intatto (nessuna modifica alle coordinate del puntatore del mouse, nessun dato dalle reti, etc) tra i microtasks.
+Questo &egrave; importante perch&egrave; garantisce che l'ambiente applicativo rimanga intatto (nessuna modifica alle coordinate del puntatore del mouse, nessun dato dalle reti, etc) tra i vari microtasks.
 
-Se volessimo eseguire una funzione in maniera asincrona (dopo il codice in esecuzione), ma prima che avvengano cambiamenti nella finestra del browser, o nuvi eventi vengano gestiti, potremmo schedularla con `queueMicrotask`.
+Se volessimo eseguire una funzione in maniera asincrona (dopo il codice in esecuzione), ma prima che avvengano cambiamenti nella finestra del browser, o che nuovi eventi vengano gestiti, potremmo schedularla con `queueMicrotask`.
 
-Questo qui un esempio con la "conteggio barra di progresso", del tutto simi a quella precedente, ma vengono usati `queueMicrotask` invece di `setTimeout`.
-Come puoi vedere che renderizza alla fine. Esattamente come se fosse del codice sincrono:
+Questo qui &egrave; un esempio della funzion "conteggio barra di progresso", del tutto simile alla precedente, ma vengono usati `queueMicrotask` invece di `setTimeout`.
+Come puoi notare, renderizza il valore del conteggio alla fine. Esattamente come se fosse del codice sincrono:
 
 ```html run
 <div id="progress"></div>
@@ -299,7 +299,7 @@ L'immagine pi&ugrave; esausitva di un event loop &egrave; questa:
 
 ![](eventLoop-full.svg)
 
-Il pi&ugrave; dettagliato algoritmo dell'event loop (sebbene ancora semplicistico rispetto alla [specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)):
+Questo &egrave; il pi&ugrave; dettagliato algoritmo dell'event loop: (sebbene ancora semplicistico rispetto alla [specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)):
 
 1. Rimuovi dalla coda ed esegui il task meno recente dalla coda dei *macrotask*  (ad esempio "script").
 2. Esegui tutti i *microtasks*:
@@ -310,26 +310,26 @@ Il pi&ugrave; dettagliato algoritmo dell'event loop (sebbene ancora semplicistic
 5. Vai al passo 1.
 
 Per schedulare un nuovo *macrotask*:
-- Use zero delayed `setTimeout(f)`.
+- Usa un `setTimeout(f)` ritardo zero.
 
-Questo potrebbe essere usato per divitere task di calcolopesante in pezzi, di modo che tra questi, il browser possa eseguire altre operazioni.
+Questo potrebbe essere usato per divitere task di calcolo pesante in pezzi più piccoli, di modo che nello spazio tra questi, il browser possa eseguire altre operazioni.
 
 Inoltre, vengono usati nei gestori degli eventi per schedulre una azione dopo che l'evento &egrave; stato del tutto gestito (bubbling completato)
 
 Per schedulare un nuovo *microtask*
 - Usa `queueMicrotask(f)`.
 - Anche i gestori promise passando attraverso la coda dei microtask.
 
-Non ci sono gestori UI o di networking tra i microtask: vengono eseguiti immediatamente uno dopo l'altro
+Non ci possono essere gestioni di UI o di networking tra i microtask, perchè i microtasks vengono eseguiti immediatamente uno dopo l'altro.
 
-Quindi uno potrebbe volere che la coda `queueMicrotask` eseguisse una funzione in maniera asincrona, ma manntenendo il contesto dell'ambiente.
+Ma cosa succederebbe se uno  volesse che la coda `queueMicrotask` eseguisse una funzione in maniera asincrona, mantenendo però il contesto dell'ambiente.
 
 ```smart header="Web Workers"
 Per lunghi calcoli pesanti che non possono bloccare l'event loop, possiamo usare i [Web Workers](https://html.spec.whatwg.org/multipage/workers.html).
 
-Che &egrave; un modo per eseguire del codice in un altro thread parallelo.
+I Web Workers sono un modo per eseguire del codice in un altro thread parallelo.
 
-I Web Workers possono scambiarsi messaggi con il processo principale, ma hanno le loro variabili ed i loro event loop.
+I Web Workers possono scambiare messaggi con il processo principale, ma hanno le loro variabili ed i loro event loop.
 
-I Web Workers non hanno accesso al DOM, quindi sono adatti principalmente per i calcoli, per usare contemporaneamente pi&ugrave; cores CPU.
+I Web Workers non hanno accesso al DOM, quindi sono adatti principalmente per i calcoli, per usare contemporaneamente pi&ugrave; cores della CPU.
 ```