Bug 149850 – Reinstate support for SharedWorkers

• Component: New Bugs
• Status: RESOLVED DUPLICATE

[John Tregoning]

It looks like support for SharedWorkers was removed purposefully @see: https://bugs.webkit.org/show_bug.cgi?id=140344 but no context was provided as to why.

Safari is the only major browser that does not support SharedWorkers. It would be great if Webkit could reinstate it as it enables a lot of possibilities for complex web applications.

[Carlos Alberto Lopez Perez]

There is the following explanation at https://webkit.org/status/#feature-shared-web-workers about the removal:

"""
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.
"""

No idea about how popular is this feature and if nowadays there is more adoption of it.

[Stu Kabakoff]

I would like to see this feature reenabled.

I am trying to hold a websocket in a shared worker, this use case does not fit service worker because service worker is meant to shut down when not in use.

I also want to make a shared worker to provide an API to our local DB, which may occasionally require computation. Service worker is not appropriate for this because work on the service worker blocks network access for all tabs. Service workers cannot spawn other workers to alleviate this problem.

I will use shared worker anyway because support for Safari outside of iOS is not important to this specific project. In iOS we don't expect people to be using two tabs so, against the advice of the standard, we can put our socket in the service worker and use dedicated workers for our DB access.

[Tobias Uhlig]

As a co-founder of the neo.mjs framework:
https://github.com/neomjs/neo

I would like to add some weight here. Chrome has just finished the full support for JS modules inside shared workers and Firefox works as well using webpack based dist versions.

Please take a look at this one (was top1 on Reddit (JS sub) with 5400 views already:

https://medium.com/swlh/chrome-v83-enables-js-module-support-for-sharedworkers-starting-a-new-era-for-multi-browser-dbb20366bddf?source=friends_link&sk=5fb6a90658d292a6af5bd30c24cb239d

SharedWorkers can have a huge impact on mobile too, in case you think about native shells with multiple WebViews which can share their JS related logic.

It would make me very sad in case you keep falling behind on this one.

Best regards,
Tobias

This feature is also important for our product. We have a local database implemented in WebAssembly in a separate worker and want the user to be able to use an application with multiple tabs, but use the same database instance. 

Shared Worker is the standard solution for this problem.

Currently we recommend customers NOT to use Safari on the desktop because of this limitation.

It would be great to have Safari support this feature so we can recommend its use too. Please don't make Chromium the only main player in town by not being competitive.

[Maciej Stachowiak]

This feature was originally removed temporarily during multiprocess bring-up, and actual usage on the web has been pretty low. We're willing to reconsider if there is significant demand.

[Arthur Rubens]

Please reconsider adding shared workers, it would help us a lot!

Please, please reconsider!  I love Safari, but I need SharedWorkers more!

[Alex Lazar]

Please re-consider, we have several projects that we have delivered for Chrome, but we would love to have them working on Safari as well. I think this would be of a huge help. Thanks, Alex & MCRO team.

[Tobias Uhlig]

Created attachment 401525 [details]
Interest in SW on my Medium articles

I would like to add this one, since it is a good indicator on how many devs care about SW.

My article on Chrome adding JS module support for SW already has 6300 views / 1200 reads. JS module support is just a subset of the SW topic in general.

Webkit still has no JS module support for normal (non shared) workers, which leaves the scope of this ticket (but also super important).

To catch up to Chrome, Webkit needs JS module support for workers, SW in general, JS module support for SW.

It took the Chromium team a long time to get there, so please don't underestimate it.

[Tobias Uhlig]

Created attachment 401526 [details]
Use case Firefox OS

https://github.com/whatwg/html/issues/315#issuecomment-154496028

This issue in general is important: there was an official discussion about removing SW, but it got closed in August 2017.

[Maciej Stachowiak]

Recent commenters who are interested in shared workers, can you please share the following info:

- Are there any existing websites or apps you can maktion that would use SharedWorkers if they were brought back, or which currently use SharedWorkers in other browsers?

- Can you tell us more about how you'd like to use SharedWorkers? 

(I recognize some have already commented with a bit more detail; I don't totally get what is meant by "local database" though. Is it using IndexedDB? If yes, why is a shared worker needed? If no, how is it ultimately storing things?)

[Radar WebKit Bug Importer]

<rdar://problem/64348204>

[Tobias Uhlig]

(In reply to Maciej Stachowiak from comment #11)
> Recent commenters who are interested in shared workers, can you please share
> the following info:
> 
> - Are there any existing websites or apps you can maktion that would use
> SharedWorkers if they were brought back, or which currently use
> SharedWorkers in other browsers?
> 
> - Can you tell us more about how you'd like to use SharedWorkers? 
> 
> (I recognize some have already commented with a bit more detail; I don't
> totally get what is meant by "local database" though. Is it using IndexedDB?
> If yes, why is a shared worker needed? If no, how is it ultimately storing
> things?)

Hi Maciej,

thanks for looking into this. I have 5 open tickets left for finishing my current "Expanding Single Page Apps into multiple Browser Windows" sprint. This is entirely based on SharedWorkers and will enable more developers to use SWs in an easy way.

I will share the Blog Post here as soon as it is done, to give you more input on why SWs are so important and what you can do with it.

Here a preview video:
https://www.youtube.com/watch?v=OvwNBMhcgds

(In reply to Radar WebKit Bug Importer from comment #12)
> <rdar://problem/64348204>

We implemented a SQL database in WASM, which works offline (storing information to IndexDb) and synchronizes with the server when online. An application user interface uses the database which is in a SharedWorker and can access the same data/functionality from multiple tabs. We don't need/want multiple instances of the database, that is why we use Shared Workers. 

As an example, let's say you have a CRM application and wanted to look at one contact in one tab, and another contact in another tab. With Shared Workers we can keep one instance of the database.

[Stu Kabakoff]

(In reply to Maciej Stachowiak from comment #11)
> Recent commenters who are interested in shared workers, can you please share
> the following info:
> 
> - Are there any existing websites or apps you can maktion that would use
> SharedWorkers if they were brought back, or which currently use
> SharedWorkers in other browsers?
> 
> - Can you tell us more about how you'd like to use SharedWorkers? 
> 
> (I recognize some have already commented with a bit more detail; I don't
> totally get what is meant by "local database" though. Is it using IndexedDB?
> If yes, why is a shared worker needed? If no, how is it ultimately storing
> things?)

The use cases that I hit fall into one of two categories: networking and data.

- Having a multi-window app with a single WebSocket/WebRTC connection to a server. This is my use case for a real time application.
- Using a wasm database that saves to either IndexedDB or appcache. This library is an example and specifically calls out Safari: https://github.com/wireapp/websql
- An in memory database, in my case we're using LokiDB to react to changes provided by a shared worker holding the socket.
- Synchronizing data in multi-window apps with a single source of truth.

To anyone reading this, we have been able to work around this using leader election from this library: https://github.com/pubkey/broadcast-channel

[Tobias Uhlig]

I just finished my blog article on the neo shared workers setup.

Friends link:
https://medium.com/@tobiasuhlig/expanding-single-page-apps-into-multiple-browser-windows-e6d9bd155d59?source=friends_link&sk=bbfe1dada95c5674669e463f93360822

This one enables other devs to easily craft Apps using SWs.

[Tobias Uhlig]

Hi Maciej,

I will add the current numbers as attachments.
In short: 197 upvotes on Reddit and 4400 views (586 reads) on Medium within 24h.

This might be a good indicator for you to figure out the interest in general on the SW topic.

I did point to this ticket in my article, but sadly devs these days are kind of lazy with providing feedback. It is easier to just hit an upvote button, than to register here to add a +1...

[Tobias Uhlig]

Created attachment 402196 [details]
Reddit prgramming sub numbers

[Tobias Uhlig]

Created attachment 402197 [details]
Medium numbers on the "Expanding SPAs into multiple Browser Window" article (entire based on SWs)

[David Graham]

>Are there any existing websites…that would use SharedWorkers if they were brought back, or which currently use SharedWorkers in other browsers?

We're using a shared worker process to share a single web socket connection across all browser tabs on the github.com origin. We've been using a one-socket-per-tab implementation for years, but open TCP sockets have finally become a bottleneck in our infrastructure.

We still connect an individual socket in each Safari tab because it doesn't support the SharedWorker API. We would like to use the worker in all browsers, though.

[Toca]

I also desire support for shared workers. I have a real time application where it is expected that the user will have multiple tabs open. Real time data streams in as workers provide updates to or complete tasks on different projects. Think 100 - 200 employees providing 1 update every minute, with 3-4 supervisors watching dashboards at personal workstations. Each dashboard is a different browser tab, providing a different view into the data. Each tab/view gets it's data from the ShareWorker which has a WebSocket connection receiving these events in real time.

Without using a SharedWorked, each tab would require it's own WebSocket and would receive it's own copy of the data from the server, which has to push out a copy of the data for each of the tabs/websocket connections.

With a SharedWorked which has a single WebSocket connection that receives a single copy of the data from the server. The data is then pushed out to each tab, which updates it's view accordingly. This concept is central to the application.

[Toca]

Here is a good example of what I would like to accomplish:

https://ayushgp.github.io/scaling-websockets-using-sharedworkers/

[Tyler Gross]

Hello! I work for a team at Amazon Web Services called Amazon Connect. Amazon Connect is a cloud-based call center application. We use SharedWorkers to synchronize communications between contact center agents and customers across multiple tabs. We do not currently support iPads or mobile for this reason. I'd really love to see SharedWorkers come back so we can support future versions of Safari!

[zhenya]

hi! echoing the use case for serving multiple browser tabs with one web socket connection to minimise both resource use on the device and the server. perhaps, if there is no desire from the webkit team to reinstate shared workers, there might be a solution just for that.

[grahamglover]

We are using SharedWorkers to seamlessly popout tabs in a SPA to a separate browser tab. This is supported in all major browsers other than Safari. Please consider re-enabling this.

[Richard Cooke]

I'd also like to use SharedWorkers to be able to share a websocket connection between tabs and also share services.

Using SharedWorkers each tab is only required to run it's own UI service on the main thread, other services could run in a SharedWorker.

In Safari I require a websocket connection to every tab, and a separate service repeating the same work in every tab.

[Luke Westby]

One more for the use case of sharing a WebSocket connection between tabs

[Tobias Uhlig]

Just created a blog post on drag&drop for multi window apps, which is a perfect example on what you can do using SharedWorkers.

Demo video:
https://www.youtube.com/watch?v=AQilsuxy59I

Article (friends link):
https://medium.com/geekculture/web-based-multi-screen-apps-including-drag-drop-5e161da6507b?source=friends_link&sk=3c53f7b9cf882a93fb2929c726bd7721

I would love to enhance this use case more for Safari (Webkit), but this relies on a SharedWorkers implementation.

[Ian Lovejoy]

I also would like this feature, with the same use cases as everyone else: a shared WebSocket connection, and single-threaded access to persistent state.

While it is true that integrity of persistent state stored in IndexedDB can be ensured by transactions (after all we all do this on the server side), this seems like more complexity than should be required for a client app running on the same machine as the data store. Also it defeats some important optimizations such as reliable maintenance of in-memory derived data calculated from the persistent state.

Actually what would be even better than SharedWorker support is simply letting multiple tabs/windows from the same origin share a UI thread and memory space (as I believe is already done when one window opens another?) This would cover all of the above use cases and also eliminate the need for a messaging layer between tabs/windows. This is of course the way all native apps work, and models the user's expectation that multiple tabs/windows reflect different views of an underlying shared model.

Example usage:

// hypothetical new sharedContext property
if (window.sharedContext.userData == null) {
    // guaranteed to only happen once due to shared UI thread
    window.sharedContext.userData = new MySharedControllerObject();
}
const myListener = new MyLocalListenerObject();
window.sharedContext.userData.addListener(myListener);

I think something like this will be required if we are ever going to bring web applications on par with native apps in terms of performance and offline use.

[Ian Lovejoy]

FYI I wrote up the above proposal in a bit more detail. I believe it addresses most of the use cases that have been brought up to motivate SharedWorker support.

https://discourse.wicg.io/t/idea-context-across-tabs-windows/5271

> Are there any existing websites or apps you can maktion that would use SharedWorkers if they were brought back, or which currently use SharedWorkers in other browsers?

https://play.basketball-gm.com/ - video game with ~100k users, 15% of them are in Safari and currently getting a degraded UX due to the lack of shared workers

> Can you tell us more about how you'd like to use SharedWorkers?

In other browsers, I use it to cache data from IndexedDB in memory, and share that cache across tabs (opening different screens of data for the same save is common in my game). In Safari, I run it in a web worker and have some hacky code to prevent you from opening a save in multiple tabs.

In theory this could be done without a shared worker, and indeed an older version of my game worked that way, by passing messages across tabs to invalidate separate caches in each tab. I moved away from that for 3 reasons:

1. Shared worker is faster.

2. Shared worker is simpler.

3. Some browsers throttle JS in inactive tabs, which means if the user is running the game in one tab and then opens another tab to view some other data from the same save, the game gets throttled. With a shared worker, there is only one instance of the game for N open tabs, and it is always active as long as you're viewing one of its tabs.

[ahmad]

I needed to sync redux state b/w tabs, 

My usecase:

1. User filling out a form and see he didn't create an option that is required on this form
2. User opens a new tabs and creates the required option in a separate form
3. User comes back to the first tab to see the created options isn't there and doesn't wanna reload the form as it would lose the unsaved work (can't save either form isn't complete)

I was going to implement a solution using shared worker, but gave up when found out the support for Safari wasn't there,

Please add this feature back.

[Alvaro Junqueira]

Nowadays is necessary creates a Back-end application to share data across opened applications instead of just use a SharedWorker in the Front-end, and that is just to Safari =/
Back with the feature, will save some money for the companies
Nowadays we are just not using Safari to the end users because we don't want to create a back-end, in MAC machines, they need to use Chrome instead

I work on a NASA project named Open MCT, which is a web-based mission control system. Right now the lack of support for shared workers is making it very difficult for some of our missions to use Safari.

Our use case for Shared Workers is that some of our deployments rely on a chunked HTTP response or Server Sent Event connection in order to receive change events from Couch DB. This involves holding a socket open indefinitely, tying up 1 connection per tab. A user can trivially exhaust the entire connection pool for a host just by opening multiple tabs. We can solve this in other browsers using a shared worker.

Multiple instances of our application in many tabs is central to some of our users workflows, and right now we just have to tell them not to use Safari.

WebSockets are not an option because of a lack of support from Couch DB. Even if they were an option, SSEs are still a useful paradigm which is stymied on Safari for lack of Shared Workers.

Here's our project repository if you're interested - https://github.com/nasa/openmct

[Sumer Jabri]

I work on a project called Crafter CMS (https://craftercms.org). We use SharedWorkers to communicate and sync between multiple browsing contexts and share important runtime data and token(s). Because we require the various tabs to be in sync and a single request to fetch the backend — like our auth token — a regular web worker is not suitable and neither is a service worker because its lifespan is intermittent and we require the worker to be alive as long as any number of tabs are open.

The SharedWorker was the right solution for us.

Please add this feature back.

I work for the Italian government where we are setting up various web apps for the general public.

We need to prompt the to use Chrome or Firefox to use our apps, which is annoying.

Thank you!

[Lewis Leighton]

Another vote for reinstating SharedWorker support.

It's increasingly common for applications with realtime streaming capability to synchronise efficient socket connections.

This reduces client and server overhead where connection data (live FX/Stock/Crypto rates for example) are being requested by multiple tabs.

Using SharedWorkers is the natural and obvious choice. 

Speaking from direct experience this is a major bugbear for many developers at large financial/trading companies as it means offering a poorer experience on webkit browsers namely Safari.

[Evan Bovie]

(In reply to Maciej Stachowiak from comment #11)

Our company's use case is similar to the single, persistent server connection for multiple tabs case that other commenters have mentioned. For our AR video conferencing and remote audit product, we're connecting to a message broker over WebSockets, and we need all tabs to receive the same messages to ensure the same state. We're also supporting robust communication for low/no-connectivity environments, and our implementation relies on a single connection (one queue) per browser. This would also help us reduce server and client resource utilization.

Unless we consider complicated workarounds for Safari, we must continue to ask our clients to use Chrome or Firefox.

[Tobias Uhlig]

Hi Maciej,

Could you please define: "We're willing to reconsider if there is significant demand." a bit more in detail?

By now, we have quite a bunch of requests here. A lot more on the neo.mjs project which is gaining more and more traction.

An info like "we need x comments asking for it" would actually help.

Thanks and best regards,
Tobias

[Michael Lin]

Chrome and Firefox both have good support for ShareWorker, which makes this SharedWorker being used more and more. GitHub currently has quite a few technical solutions based on it as well. It can solve the consistency problem of many applications across multiple browser windows and keep a good performance. If Safari could support SharedWorker, it would be a clear boost to overall front-end technology innovation.

Is it possible that you will reconsider its implementation carefully?

[grahamglover]

Any one got some connections to bump this into a backlog review with Safari Developers?  It seems that such a major feature supported by other browsers should be looked at again after all this time - though it also surprises me that only  38 following this issue. 

SharedWorkers are critical for our application for a sharing websocket data across tabs. Please reach out if you have a similar situation and what your current solution is.

[Tyler Gross]

Sadly the solution for our application is "We don't support Safari."

[Tyler Gross]

Almost everything you might be able to do with SharedWorker you can now do with a ServiceWorker. I wonder if this might be able to be implemented using existing ServiceWorker APIs? As some sort of subset of ServiceWorker?

[Graham Esau]

Like many other commenters here, we've been looking for a way of sharing a WebSocket connection between multiple tabs, since it's very common for our users to have our real-time web app open in many tabs concurrently.

SharedWorker seems the ideal solution - the only problem is Safari's lack of support. Because of this, we've spent considerable dev resource on implementing workarounds in our application, and are still encountering difficulty with it. 
This is one of the reasons we're now considering dropping support for Safari.

[grahamglover]

See Also issue 230382 added recently - Implement SharedWorker: https://bugs.webkit.org/show_bug.cgi?id=230382

I gather that means someone is working on it? Perhaps probe there what the status is.

[Brent Fulgham]

*** This bug has been marked as a duplicate of bug 230382 ***