Categorie
Programmazione

Multi-threading con HTML5: i Web Workers

Una caratteristica che da sempre accompagna l’utilizzo di un browser è il cosiddetto “congelamento” dell’interfaccia durante l’esecuzione del codice JavaScript. Fintanto che il codice JavaScript sta girando nel browser quest’ultimo è completamente inutilizzabile, ovvero non risponde alle richieste dell’utente. Nella maggior parte dei casi, siccome il codice JavaScript esegue task molto semplici e veloci questo congelamento non viene percepito dall’utente. In altri casi, specialmente se il codice contiene qualche bug, invece il problema si manifesta addirittura bloccando il browser.

Questo comportamento costringe i programmatori a scrivere del codice sincrono del browser, che deve  essere veloce e robusto, per evitare di infastidire l’utente. Una soluzione comune è quella di delegare ad una chiamata Ajax o JSON l’esecuzione del codice asincrono, aspettando poi il risultato. Ciò implica una comunicazione client server, per cui la logica del codice asincrono deve trovarsi sul server. Tale situazione conduce ad altri due problemi:

  1. Ogni volta che vogliamo eseguire del codice in modo asincrono dobbiamo aggiungere un componente server nella nostra architettura
  2. Le chiamate Ajax sono limitate dalla  cross-domain policy, per cui non è semplice scambiare messaggi tra un client e un server se quest’ultimo si trova su un altro dominio

Le nuove specifiche HTML5 risolvono questi problemi introducendo il concetto di Web Worker.

I Web Workers permettono un approccio alla programmazione molto simile al classico multi-threading caratteristico dei paradigmi Enterprise, come ad esempio C++ o Java. Ciò risolve il problema del congelamento del browser durante l’esecuzione del codice JavaScript. Inoltre, siccome i Web Worker non hanno a che fare con la tecnologia Ajax, essi non sono limitati dai problemi elencati qui sopra. Il tutto si concretizza nell’esecuzione di codice JavaScript molto semplice, che non richiede particolari conoscenze specifiche: l’utente poco esperto probabilmente si troverà più a suo agio con i Web Worker piuttosto che con le chiamate Ajax o JSON.

Ovviamente non si può avere tutto senza pagare un prezzo. Siccome i Web Workers consentono di eseguire chiamate verso un altro generico URL dobbiamo prestare particolare attenzione quando scriviamo il codice della pagina che si occupa di rispondere, per evitare che sia aperta al pubblico. Inoltre, siccome il Web Worker si trova “in remoto” (poi chiariremo il significato di questa affermazione) esso può essere utilizzato soltanto per elaborare dei dati, esattamente come farebbe il componente server di una chiamata Ajax o JSON. In altre parole  il Web Worker non può essere usato per manipolare il DOM della pagina che esegue la chiamata (che è detta parent page).

Riassumendo i vincoli (o limiti, a seconda dei punti di vista) dei  Web Workers sono:

  1. Sicurezza: necessità di controllare l’origine della chiamata quando il  Web Worker viene invocato
  2. DOM: impossibilità di accedere agli oggetti JavaScript <code>window</code>, <code>document</code> e <code>parent</code> della parent page e quindi di manipolare la pagina che esegue la chiamata

 

Nelle prossime pagine vediamo qualche esempio concreto di Web Worker… al lavoro!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.