Quali sono i casi d'uso per i Web Worker? [chiuso]

174

Sto cercando uno scenario reale per l'utilizzo dell'API Web Workers .

javascript html web-worker

— Sergey Ilinsky
fonte

Sono supportati da piattaforme mobili / webkit?

— dmp,

Non lo so per certo, ma immagino che lo siano.

— Sergey Ilinsky,

Supporto per browser @danp: caniuse.com/webworkers

— Dheeraj Vepakomma

Ho scritto un caso in cui abbiamo usato per la prima volta un web worker, poi ho deciso che stavamo meglio senza di esso - windward.net/blogs/web-workers-abandon/#.Vl3QdXarQ-U

— David Thielen

Risposte:

143

John Resig (di fama jQuery) ha un sacco di esempi interessanti di utilizzo dei web worker qui : giochi, grafica, criptovaluta.
Un altro uso è l'I / O Web: in altre parole, gli URL di polling in background. In questo modo non blocchi l'interfaccia utente in attesa dei risultati del polling.
Un altro uso pratico: in Bespin, stanno usando Web Worker per evidenziare la sintassi, che non vorresti bloccare la modifica del codice mentre stai usando l'app.
Da Mozilla : un modo in cui i lavoratori sono utili è consentire al codice di eseguire calcoli ad alta intensità di processore senza bloccare il thread dell'interfaccia utente.

Come esempio pratico, pensa a un'app che ha una grande tabella di #s (questo è il mondo reale, BTW - tratto da un'app che ho programmato ~ 2 anni fa). Puoi cambiare un # in una tabella tramite il campo di input e un sacco di altri numeri in colonne diverse vengono ricalcolati in un processo abbastanza intenso.

Il vecchio flusso di lavoro era: Cambia il #. Vai a prendere un caffè mentre JavaScript crunch attraverso le modifiche ad altri numeri e la pagina web non risponde per 3 minuti - dopo che l'ho ottimizzato all'inferno e viceversa. Torna con un caffè. Cambia un secondo #. Ripeti più volte. Fai clic sul pulsante SALVA.

Il nuovo flusso di lavoro con i lavoratori potrebbe essere: modificare il #. Ricevi un messaggio di stato in cui viene ricalcolato qualcosa ma puoi cambiare altri #. Cambia più #s. Al termine della modifica, attendere che lo stato cambi in "tutti i calcoli completati, ora è possibile rivedere gli # finali e salvare".

— DVK
fonte

Grandi collegamenti! Non avevo mai sentito parlare di Lavoratori ... mmm, Lavoratori. (È ora di fare una lunga doccia calda ...)

— Peter Rowell,

So che questa è una risposta di due anni, ma volevo solo ricordare che non dovresti aver bisogno di Web Worker per l'articolo n. 2 (URL di polling). XHR avviene in modo asincrono e non si blocca; non è necessario eseguire richieste XHR su un thread separato. (Certo, in un'app moderna vorresti usare WebSocket invece del polling.)

— josh3736

@ josh3736 - Hai ragione ma ora sono curioso di sapere se fare molte richieste parallele XHR aync può in qualche modo rendere il browser infelice? Inoltre, sono necessarie risorse locali per elaborare le risposte XHR in cui i lavoratori potrebbero essere utili.

— DVK,

Se tutte le richieste parallele si trovano sullo stesso server, raggiungerai il limite per nome host da qualche parte tra 2 e 9 connessioni simultanee. (Suppongo che il limite si applichi a tutte le connessioni, siano esse avviate dal thread principale o da un lavoratore.) Naturalmente, se hai 10 richieste simultanee in esecuzione contemporaneamente, probabilmente dovrai ripensare la progettazione della tua applicazione.

— josh3736,

Scusa la mia semplice domanda, ma a cosa ti riferisci come "#" nel tuo esempio sopra?

— shrewdbeans

Li ho usati per inviare grandi quantità di dati dal browser al server. Ovviamente, puoi farlo con le normali chiamate AJAX, ma se questo occupa una delle preziose connessioni per nome host. Inoltre, se l'utente esegue una transizione di pagina durante questo processo (ad esempio, fa clic su un collegamento), gli oggetti JavaScript della pagina precedente scompaiono e non è possibile elaborare i callback. Quando viene utilizzato un web worker, questa attività avviene fuori banda, quindi hai una migliore garanzia che verrà completata.

— Kevin Hakanson
fonte

Ma devi scambiare il messaggio con il web-worker. Quando il costo di questa operazione merita il vantaggio?

— Danielo515,

Un altro caso d'uso:

Compressione / decompressione dei file in background, se sono presenti molte immagini e altri file multimediali che vengono scambiati dal server in formato compresso.

— SBR
fonte

Questo non dovrebbe accadere in JavaScript. Le immagini sono già compresse (PNG, JPEG) utilizzando algoritmi progettati per comprimere in modo efficiente i dati delle immagini. Lanciare un altro livello di compressione in alto può effettivamente aumentare la dimensione dei dati. Per altri tipi di dati (ad esempio un file JSON di grandi dimensioni), la compressione deve essere gestita dal browser utilizzando il gzipping HTTP standard. Se stai facendo compressione in JavaScript, probabilmente stai sbagliando .

— josh3736,

Vedo alcuni utenti che squalificano il caso d'uso, ma ecco cosa intendevo dire. considera un'applicazione come MS Word, come un potente editor di documenti attraverso il quale puoi incorporare immagini, file musicali, dati, fogli Excel ecc. tutti in UN file. e considera di avere un client basato sul Web, un client desktop e un client IOS / Android. Per questo tipo di caso d'uso, è possibile archiviare tutto il contenuto del file in un file zip e decomprimerlo su ciascun client.

— sabato

Il bookmarklet Instapaper comprime la pagina salvata prima di inviarla al server. Risparmia tempo e larghezza di banda.

— Stevendaniels,

@ josh3736 L'unica cosa che un browser può fare è eseguire il gunzip di un file da un server web (o cache del browser). Non può decomprimere i dati dalla memoria locale, né da un websocket, e non può comprimere affatto. Le app Web inviano una quantità sempre crescente di dati a monte e la compressione per questo è estremamente utile. Ugualmente valido un anno fa quando questo è stato pubblicato: se non riesci a pensare a casi d'uso validi per la compressione JavaScript, probabilmente ti manca l'immaginazione.

— Adria,

@Adria: lo standard websocket sta aggiungendo il supporto per la compressione . Se hai a che fare con le immagini generate nel browser ( <canvas>), puoi ottenere i dati delle immagini in un formato compresso (ad esempio png). Il mio punto non era che non è mai appropriato comprimere in JS; il mio punto è che nella maggior parte dei casi , è non è , e per la maggior parte dei casi - soprattutto a che fare con le immagini, che è ciò che questa risposta parla - c'è un'alternativa migliore per posizionare il proprio compressione.

— josh3736,