WebWorkers e WebSocket

di , in .NET,

Avete mai fatto applicazioni che facessero uso intensivo di codice Javascript? Avete notato quanto siano lente? Avete mai sognato di poter parallelizzare il vostro codice Javascript? Avete mai desiderato ricevere notifiche in tempo reale dal server senza bisogno di fare polling AJAX?

Se avete risposto si ad almeno una di queste domande allora WebWorkers e WebSockets fanno al caso vostro. Ma partiamo dai WebWorkers.

Javascript è single-threaded. Attraverso un sapiente uso dei metodi setTimeout e setInterval potete creare codice asincrono, ma sempre single-threaded. Questo in moltissime applicazioni va più che bene, ma che mi dite di applicazioni che devono andare periodicamente sul server a recuperare dati, fare pesanti calcoli ed aggiornare la UI di conseguenza? In questi casi avere un thread-separato rispetto al thread principale aiuta parecchio ad ottimizzare le performance in quanto la UI non viene bloccata mentre si processano I dati. Finalmente, grazie ai WebWorkers introdotti con HTML5 e Javascript5, creare più thread in Javascript diventa possibile. Non abbiamo a disposizione un framework evoluto, ma una serie di API che consentiranno nel futuro di averne.

Il concetto alla base dei WebWorkers è molto semplice: definiamo un file JS che contiene il codice da far girare in un altro thread e poi inizializziamo un thread passandogli in input l'indirizzo del file JS. Ovviamente possiamo passare dei parametri al nuovo thread e ricevere dati dal thread stesso. Quest'ultima feature è fondamentale in quanto il thread secondario non può accedere al DOM che è accessibile solo dal thread principale. Insomma, il concetto è che I WebWorkers ci permettono di fare applicazioni molto più veloci e responsive che in passato.Benchè supportati ormai da tutti I browser, la nota dolente è alcuni browser come chrome e firefox supportano I WebWorkers solo attraverso il prefisso (Moz o WebKit).

Il discorso dei WebSocket invece è (se possibile) ancora più interessante. Il protocollo HTTP è basato sul concetto di richiesta/risposta: il client chiede il server risponde. Per far arrivare degli aggiornamenti dati dal server al client senza che l'utente aggiorni la pagina, utilizziamo la tecnica del polling unito all'uso di XmlHttp per essere asincroni. Questa tecnica simula le notifiche real-time ma offre numerosi svantaggi. Il primo è un incredibile overhead di rete: se io voglio scambiare con il server pochissimi dati, comunque la richiesta è molto corposa per via delle intestazioni http. Il secondo overhead è a livello di canali di comunicazione visto che se ne devono stabilire 2 per ogni richiesta. Con I WebSocket il discorso cambia radicalmente. Possiamo infatti creare con il server  un canale bidirezionale attraverso il quale il browser può ricevere e inviare dati al server in realtime senza polling; il tutto si basa inoltre sulle porte 80 e 443 e quindi senza avere problemi di firewall. Questo significa abbattere gli overhead precedenti poiché si crea un solo canale e poichè non essendoci HTTP non ci sono nemmeno le intestazioni HTTP ad incrementare la corposità dei messaggi inviati.

Insomma, WebWorkers e WebSocket rappresentano grosse novità che faranno parte del nostro toolset nei mesi a venire. Non sono ancora perfettamente integrati in tutti I browser, ma lo saranno molto a breve quindi vi consiglio di dargli una bella occhiata ;).

 

Stay tuned.

Commenti

Visualizza/aggiungi commenti

WebWorkers e WebSocket 1010 1
| Condividi su: Twitter, Facebook, LinkedIn, Google+

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Nella stessa categoria
I più letti del mese