call functions in web worker from main thread (et vice versa)
index.html
<button type="button" id="counter"></button>
<script src="wokry-turkey.min.js"></script>
<script>
const counterButton = document.getElementById('counter')
const worker = workyTurkey.expose(
{
// the `render` function will be available in the worker
render (value) {
counterButton.textContent = value
}
},
new Worker('worker.js')
)
counterButton.addEventListener('click', function () {
// call the `increment` function exposed by the worker
worker.increment()
})
</script>
worker.js
loadScripts('worky-turkey.min.js')
let counter = 0;
const ui = workyTurkey.expose({
// the `increment` function will be available in the main thread
increment(value = 1) {
counter += value
// call the `render` function exposed by the ui thread
ui.render(counter)
}
});
// call the `render` function exposed by the ui thread
ui.render(counter)
…
worky-turkey uses proxies, whose are supported in all evergreen browsers: caniuse proxy
What's about Comlink?
worky-turkey is heavily inspired by Comlink. But there are use cases, you just don't need the super power of Comlink.
Comparend to Comlink, worky-turkey...
- only supports function calls
- does not return anything (just fire and forget)
- does not support callbacks as function parameter (just Transferables. As rule of thumb: only use primitives, plain objects and arrays as parameter)
- is written in less than 25 lines of code 😎 (~300 bytes minified, ~240 bytes gzipped)
This is great if you just want the other side know, that something has to be done.
This is not so great if you rely on the result of the other sides function call.
Of course, you can postMessage
something like { fn: 'doSomething', params: ['foo', 42] }
and handle it accordingly on the other side, but it simply feels more naturally to call worker.doSomething('foo', 42)
.