Why did Safari drop support for SharedWorker?

Question

Why did Safari drop support for SharedWorker?

And are there any working polyfills using, for example, localStorage and StorageEvent as a communication port? (Yes, the shim would have to detect and recreate the master Worker)

Answer 1

From my understanding the answers here are correct, but it's also due to the lack of SharedWorker adoption by web developers (a chicken and egg type situation).

If you're in need of a polyfill, you can use the one I created. I couldn't find one for one of my projects, so I created this one, https://sharedworker.okikio.dev/.

Note: it doesn't handle cross tab communication, but you can use the CacheStorage API together with a ServiceWorker and MessageChannel or use IndexedDB and ServiceWorker (from @jakearchibald on Twitter) to create a similar effect

Also: I should mention that Safari is working on supporting the BroadcastChannel API, which would cover the cross tab communication aspect, it's currently available in the Webkit Technology Preview

Answer 2

Directly from one of the WebKit Engineers:

The implementation of Shared Web Workers was imposing undesirable constraints on the engine. It never gained any adoption.

Source here

Answer 3

Since safari default's behaviour on cookies is preventing third-party cookies on tracking.

If safari allows us to use SharedWorker, developer(google or tracking company) can use it to access identify between different window tab.

That's the reason why safari drop the SharedWorker, interestingly, it support WebWorker but not SharedWorker.

---

It's my guess, not the official reason.

Answer 4

I can't find any polyfills for SharedWorker.

It seems that one can be created by implementing a StorageEvent based communication port across workers. The downside being that StorageEvents are not portable for WebWorkers, and you have to maintain state across each browser tab and know when to flick on/off each master worker.