Re: [slightlyoff/ServiceWorker] consider allowing multiple worker thread instances for a single registration (#756)

@jakearchibald 
> Can you explain when & why you're calling clients.claim()?

The when is pretty much every SW I've authored since I learned you could call clients.claim().  The why is to stop myself from quietly sobbing in shame for not being able to control SW lifecycles the way I want to when I'm in development.  It's just a thick callous I've developed over one of the friction-points in SW development.  I think I picked it up from an article a while back and it really seems to have made things easier for me in dev.  Thanks for that video link - I try to keep myself up-to-date on all things Jake Archibald and I missed that somehow.

> How would this be different to option 2 of #756 (comment)? (except option 2 doesn't need extra API)
> 
> The SW would still be killed when it isn't used though, so global state would still be unreliable.

Maybe it wouldn't be different than #2, but I was under the assumption that all of that was under the umbrella of the "whole SW is concurrent".  I have come to *enjoy* the fact that SW global state is ephemeral, because it enforces some good practices... but I still see a marked difference between "There is 1 of these in active state and it might die at any time" and "There are an unpredictable number of these things active and they die".  The latter is harder for me to reason about.  I am a renowned idiot so that could have a lot to do with why it would it's difficult for me to grasp.

There are some other really cool things I could think of to do with an API like that (a way to share some stuff more easily with the client)... but I digress; maybe with your #2, we are basically talking about the same approach.

> I get that there's a fear of concurrency here, but do you have an example of something you're doing now that would break with concurrency?

https://github.com/bkimmel/bkimmel.github.io/blob/master/serviceworker_bgs/sw.js
The most fun example I can think of: This dark pattern where I abuse sync / event.waitUntil to violate the user's privacy by notifying myself the next time they turn their browser on with no consent on their part.  (I sent this to you a few months back on Twitter. I proved it in practice a couple of versions of Chrome ago, haven't tested it since.)  This would still work, but would it maybe send 20x messages home for 20x concurrent SWs?  Or can you make it so that just one SW gets the sync and the other ones you spun up don't?

But more generally, any pattern where I wait in the SW for a message from the client... since as it was pointed out above, now I have absolutely no idea which evil SW twin will get the message to proceed.  Ben helpfully pointed out BroadcastChannel, but last I checked it wasn't in Chrome yet.  The short story is I don't have anything in production that does this and I think I could eventually adapt my way of thinking to accomodate.

Overall, I love the work you guys do and if you say "calm down, it'll be OK" then I'll snap to.  I'm just baring my ignorance here for the potential benefit of anyone else who is riding the "special bus" with me and has difficulty thinking about how this would work.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/756#issuecomment-238025410