tldr; A list of available functionality and use cases for web workers. Have something to add? Submit a PR.
Web Workers give web developers the apility to run code in multiple threads. This is great, now, what can we do with these threads? This document is meant to help provide context and real world use cases for these little wonders.
A lot of your favorite tools have excellent support for web workers, making them even easier to use!
The file reader api allows you to read uploaded files. You can now upload a file (say csv). send that to a web worker, read the file and parse it to json without blocking the main UI thread.
"IndexedDB is a way for you to persistently store data inside a user's browser. Because it lets you create web applications with rich query abilities regardless of network availability, your applications can work both online and offline."
Web Notifications allow you to send pop up style notifications to users even when they do not have your site open.
Lets you make a network request.
The Fetch API is a modern replacement for XMLHttpRequest and is closer to a lot of the libraries we are used to.
"WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply."
Web assembly is fully capable of being run inside of a web worker! This means we can do some more computationaly heavy tasks taking advantage of wasm but avoiding blocking our main UI thread. For an example take a look at this simple machine learning Tic Tac Toe bot written in Rust and running in wasm.
https://github.com/code-jugglers/brain-games-rust/blob/master/www/scripts/game.worker.ts
Filter large data sets without blocking the UI thread and without making a full round trip to the server.
// filter.worker.js
self.onmessage = (e) => {
const res = e.data.filter((item) => item.flagged);
self.postMessage(res);
};
// app.js
var filterWorker = new Worker('filter-worker.js');
filterWorker.onmessage = function (e) {
// Log filtered list
console.log(e.data);
}
var hugeData = [ ... ];
filterWorker.postMessage(hugeData);You can use web workers to load and run Javascript libraries in separate threads so that none of the downloading or parsing is handled on the main thread
// cool-worker.js
loadScripts('https://large/but/cool/library.js');
self.onmessage = function (e) {
switch(e.data.type) {
case: 'thingIWantToDo':
myLibraryScope.doTheThing(e.data.payload).then(res => {
self.postMessage({
status: 'COMPLETED'
type: e.data.type,
payload: res
})
});
break;
default:
throw new Error(`Action ${e.data.type} is not handled by cool-worker`);
}
}
// app.js
var coolWorker = new Worker('cool-worker.js');
dispatch({
type: 'thingIWantToDo',
payload: 1000
}).then(console.log);
function dispatch(action) {
return new Promise(resolve => {
const listener = res => {
if (res.data.type === action.type && res.data.status === 'COMPLETED') {
resolve(res.data.payload);
coolWorker.removeEventListener('message', listener);
}
};
coolWorker.addEventListener('message', listener);
coolWorker.postMessage(action);
});
}Yes yes yes polling is gross, but sometimes it can be necessary, offload the grossness to a new thread. NOTE: web workers will hold their state but NOT permanently, so don't keep anything in them that you can't get some other way.
// polling-worker.js
self.onmessage = function (e) {
let cache;
const compare = (newData, oldData) => { ... };
var myRequest = new Request('/my-api-endpoint');
setInterval(() => {
fetch(myRequest)
.then(res => res.json())
.then(data => {
if(!compare(data, cache)) {
cache = data;
self.postMessage(data);
}
})
}, 1000)
});
// app.js
var pollingWorker = new Worker('polling-worker.js');
pollingWorker.onmessage = () => {
// render data
}
pollingWorker.postMessage('init');