Remove shared workers?

[annevk]

Both Apple and Microsoft are against implementing them I learned. They are rarely used. There is reportedly some usage on Google properties and Firefox OS may use them, neither seems super persuasive.

Should probably add a deprecation warning to start.

[wanderview]

Personally this seems premature to me. Maybe once an alternative like foreign fetch exists it might be possible, but until then what are the reasonable alternatives?

[jrburke]

Here is the use case from Firefox OS:

Apps in Firefox OS can have multiple windows open against them. One could be serving as the main app window, one could be in use by a web activity, part of another app flow.

We want to run the backend data services in a shared worker:

• Saves memory/resources vs multiple workers.
• Logical code isolation for backend development. Knowledge that only one instance of it will be active simplifies development.
• Allows gating or serializing IO work in one location. This is particularly useful in the email app on FirefoxOS, where it uses mozTCPSocket to talk to mail servers. We only want one thing in the browser doing that work.

Additionally, we would like to see the ability for a Service Worker to use the same Shared Worker for Service Worker entry points like background sync, for the same reasons above.

In the Service Worker example, there may or may not be an existing window open for the email app, and we do not want to take the hit to create one just to create a worker. Ideally the Service Worker could trigger spinning up the Shared Worker. If it is already running, just communicate with it. If a browser window for the app is created while the background sync is running, it would just communicate with the Shared Worker that could already be running.

More in-depth notes on how the Firefox OS SMS app uses a shared worker

If Shared Workers are going away, it would be helpful to know what mechanism is available to achieve similar results.

[azasypkin]

One more important use case for the Firefox OS SMS app is that code hosted inside SharedWorker could potentially create in-memory data view (e.g. based on the data extracted from IndexedDB) for the super fast access.

The app itself will consist of several pages, every page is a separate document, to navigate between pages we'll use real links that will navigate user from one document to another and it's important to keep this in-memory data view alive between navigations so that page2 will use the same in-memory data view created by page1 almost for free.

IIRC SharedWorker is kept between page navigations if they are bound to the same domain, please correct me if I'm wrong. BFCache and Prerendering that we're going to use will likely benefit by SharedWorkers as well.

[annevk]

@wanderview it doesn't really matter if it's not being implemented.

[annevk]

IIRC SharedWorker is kept between page navigations if they are bound to the same domain, please correct me if I'm wrong.

Is that implemented? The specification allows for it in theory, though is somewhat vague on the specifics, but that was a fairly recent change.

A lot of the use cases seem to be handled fine by service workers, perhaps combined with foreign fetch.

[wanderview]

@wanderview it doesn't really matter if it's not being implemented.

It matters if you want to actually want to convince browsers that have implemented it to rip it out.

[azasypkin]

Is that implemented? The specification allows for it in theory, though is somewhat vague on the specifics, but that was a fairly recent change.

@wanderview will know for sure, but yeah, I see that SharedWorker survives between two pages in Firefox, see example (everything is logged in console). And it doesn't work like this in Chrome Beta.

[kinu]

I also feel that it's a bit too early to remove it. ServiceWorker could be the alternative, yes, but as already mentioned on this thread there seem some usage ServiceWorker doesn't work really well, and it'd be probably good to investigate a bit and make it clear what usage scenarios we will be disregarding by killing SharedWorker.

One more important use case for the Firefox OS SMS app is that code hosted inside SharedWorker could potentially create in-memory data view (e.g. based on the data extracted from IndexedDB) for the super fast access.

Actually one of the use cases we hear in Chrome/Blink is something similar to this (though it's not for across page navigations in our case), having SharedWorker as a common backend for multiple pages to do efficient caching (and opening multiple pages for the site seems to be kind of common usage).

[sicking]

As it currently stands, Shared Workers are dramatically easier to use than Service Workers. That makes me reluctant to remove Shared Workers.

Specifically, with a Shared Worker you can simply do

w = new SharedWorker(url);

and you have a reference to an object which can provide a service though a postMessage based API.

Service Workers require that you wait for registration to happen and for resources to be downloaded. You can work around this by using a separate Service Worker with a dummy scope, to handle your database/network connections. But this feels very hacky and also means that that Service Worker can't be managed by your fetch-intercepting Service Worker.

[lewispham]

I think this is generally a bad idea. It's also very sad that SharedWorker is underestimated everywhere, including those leading browsers like Chrome, Edge or Safari.

SharedWorker encourages developers to build well architectured web apps. Without SharedWorker, things like persistent connections (including WebSocket and WebRTC connections), single connection to database, emitting messages to multiple web pages are almost impossible. All these features are not mandatory for traditional web applications, where AJAX, session, cookies and other old technologies are still the king. But this is not the case for modern, offline web apps, which should be designed with a modern architecture instead.

The above design will highly improve the efficiency of web apps. Not to mention about their AJAX-lessness, the entire application data can now be managed by a single thread. Main threads are just for rendering user interfaces. That means only DOM and CSS are being executed on a web page. User experience will be vastly improved as a result. Using SharedWorker intializes an extra thread, but it will reduce a huge amount of required resources of both server side and client side. Application using WebRTC might even gain more benefits from using SharedWorker.

In my opinion, not only supporting SharedWorker, but browser vendors should also encourage developers to implement it on modern web applications, which will absolutely be dominant in the near future.

[rianby64]

I was about to learn this new feature... I hope will be interest from implementors to implement this nice feature.

[malko]

@annevk The only reason we didn't use it for our apps was the lack of browser support and caniuse site reporting it as removed or not planned. We definitely wanted to implement our apps as describe by @Tresdin. Please make this feature back to life and please vendors implement it in your browsers this time.