5 ms·
How JavaScript works: The building blocks of Web Workers
- streptomycin 9y agoI wish Shared Workers had more browser support (currently just Chrome and Firefox). Service Workers are great, but not for long-running processes. With a Shared Worker, you can have one instance of your app that will actually keep running continually as long as you have a tab open. Then you can treat multiple open tabs as multiple different clients of the Shared Worker. All state and communication with the server can be handled by the Shared Worker, reducing a lot of duplicated effort and cross-tab coordination. It's pretty great... but only in Chrome and Firefox.
- paws 9y agoI realize it's not the same thing, but just FYI, Safari 11.1 is apparently adding ServiceWorker support. [1] One year ago it didn't seem very likely this would land. Maybe the future holds some promise for SharedWorkers on Safari too. [1] https://developer.apple.com/safari/technology-preview/release-notes/ https://developer.apple.com/safari/technology-preview/releas...
- deleted 9y ago[deleted]
- giancarlostoro 9y agoAnother feature I love that I wish were in more than just Chrome and Firefox: BroadcastChannel. If you want to post to an iFrame or Window, you gotta find it's object. With BroadcastChannel you just join the "channel" and post away, and anyone can listen to that channel, each channel is unique as well. It's so much better than hunting down the DOM element and then doing postMessage. Apparently it is also available to WebWorkers. Makes sending messages through iFrames / new windows / tabs a breeze. Don't ask me why I'm using iFrames in 2018 though :) https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel https://developer.mozilla.org/en-US/docs/Web/API/BroadcastCh...
- lioeters 9y agoWell-written article - I'll enjoy reading the rest of the series in depth. One nit to pick: "Web Workers run in an isolated thread in the browser. As a result, the code that they execute needs to be contained in a separate file. That’s very important to remember." This isn't totally true. It is possible to create an "object URL" [0] from a string and run that as a worker, instead of from a separate file: new Worker(URL.createObjectURL(new Blob([ 'self.onmessage = function(msg) { ... }' ])) I've seen this technique used in several libraries for WebAudio, to run a more accurate timer/scheduler. [0] https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL https://developer.mozilla.org/en-US/docs/Web/API/URL/createO...
- zlatkov 9y agoGood catch. Will add this example :)
- kipple 9y agoAnother nit to pick: "Copying the message: the message is serialized, copied, sent over, and then de-serialized at the other end. The page and worker do not share the same instance, so the end result is that a duplicate is created on each pass. Most browsers implement this feature by automatically JSON encoding/decoding the value at either end." This is untrue, modern workers use the structured clone algorithm[0][1], not JSON.stringify() & JSON.parse(). This algorithm has many advantages, such as preserving object references, supporting built-ins like Maps and Sets, and allowing cyclical/recursive structures. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... [1] https://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#safe-passing-of-structured-data https://www.w3.org/TR/2012/CR-html5-20121217/infrastructure....