Shared workers can not communicate across processes currently, so they should better be disabled.
Created attachment 202167 [details]
This patch caused a whole bunch of tests to fail on WK2 bots:
Fixed in <http://trac.webkit.org/changeset/150322>.
Hello, could you consider/discuss reenabling this feature?
"The implementation of Shared Web Workers was imposing undesirable constraints on the engine. The feature never gained any adoption and was eventually removed from the engine."
I understand this, but API itself looks very simple, and easier(-to-use) than service worker.
(In reply to Takahiro Ichihashi from comment #5)
> Hello, could you consider/discuss reenabling this feature?
> "The implementation of Shared Web Workers was imposing undesirable
> constraints on the engine. The feature never gained any adoption and was
> eventually removed from the engine."
> I understand this, but API itself looks very simple, and easier(-to-use)
> than service worker.
What we need is a compelling evidence that Web developers will use shared workers. Given that people don't even use shared workers in the browsers that support it (Chrome & Firefox), the argument for supporting this feature is rather weak. Also understand that the engineering resources spent to make shared worker work is the engineering resource that can't be spent elsewhere like implementing service workers so there is a huge opportunity cost associated with making this feature work across web content processes.
Thanks for your reply.
The reason behind the low adoption rate of the API is probably the immaturity of the developer communities - meaning, it sometimes takes time for new APIs to become mainstream (XHR, formally a vendor-specific Microsoft.XMLHTTP or dynamic <script tag generation technique took 7~8 years to become a core part of web).
Difficultly I found is that, currently it is a bit tricky to make a script that is shared across windows/tabs; in my case there are persistent connections via websocket / webrtc that provides some information periodically, which I want to make it more efficient by just having a one thread/tab that handles such connection even when there're multiple tabs opening, but at this time a polyfill should be made probably by utilizing localStorage events.
Service workers will solve this problem (I'm fine with this API given a lower development priority compared to service worker anyway) but personally I feel that service workers have got so many features, and I believe there's a possibility that shared worker would be loved by many developers with specific needs like the above one. But thanks for your quick reply anyway, pls let me know if anything that I can help.
I work at Chess.com. We're definitely interested in SharedWorkers, but since it's not supported in all browsers and there are no polyfills, we can't use them. So, low adoption rate is inevitable. It'd be nice if you'd reconsider.