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.

[sicking]

I really think the way to go here is to merge the functionality that ShareWorkers and Service Workers provide. As Service Workers are currently implemented, they are effectively Shared Workers, except you can't get to them using new ServiceWorker(url) syntax.

Instead there's a level of indirection involved, since a Service Worker is identified by a scope which in turns maps to a url, rather than a url directly.
And the syntax for getting the Service Worker doesn't use constructors.

Other than those two differences, there's very little that separate Service Workers and Shared Workers in current implementations.

[lewispham]

@sicking ServiceWorker is vastly different from SharedWorker. ServiceWorker has a temporary life time while SharedWorker persists until all pages are closed. ServiceWorker will be automatically terminated when there is no more tasks to handle. This single point make it hardly comparable with SharedWorker.

BTW, I've already proposed the idea of merging ServiceWorker with SharedWorker by extending its lifetime. The ServiceWorker team refused to take this idea because they're afraid of ServiceWorker being blocked by background processes. I still against their point though.

I think this issue is still not as important, at least at this time. If SharedWorker is really going to be removed, the future of modern web applications won't be so bright.

[sicking]

My point is that current implementations of Service Workers do not in fact give them temporary lifetimes.

They are not shut down until the last page that used them is closed, the same as Shared Workers

[wanderview]

My point is that current implementations of Service Workers do not in fact give them temporary lifetimes.

They are not shut down until the last page that used them is closed, the same as Shared Workers

This is incorrect. Both chrome and firefox shutdown the worker thread even though a controlled window is still active. See:

https://dxr.mozilla.org/mozilla-central/source/dom/push/test/test_serviceworker_lifetime.html

[dcerisano]

SharedWorkers are in-between WebWorkers and ServiceWorkers in terms of complexity. They are more functional than WebWorkers, and faster than ServiceWorkers, which have a security overhead.

Likely future designs may extend WebWorker functionality, and/or allow ServiceWorkers to operate without security. I have noticed that SharedWorkers are much slower than basic WebWorkers due to the extra thread management they require.

ServiceWorker is slowest because it requires secure Websockets (SSL), XHR and other securable endpoints.
EDIT: @indolering thanks for the heads-up, currently ServiceWorkers may only be used in secure contexts, as @asutherland notes below.

[asutherland]

@dcerisano Although ServiceWorkers may only be used in secure contexts, this does not translate to any security overhead once they are installed. (And indeed, since HTTPS allows use of HTTP/2, sites like https://www.httpvshttps.com/ help demonstrate that they can have drastically superior transport performance.) Once installed, a ServiceWorker is exclusively served out of the browser's local storage, so network transport does not enter into things.

Both ServiceWorkers and SharedWorkers may be subject to higher communication latencies in multi-process(-capable) browsers for postMessage/friends because of the potential for cross-process communication. But they should not be any slower in their actual CPU-bound processing performance. Dedicated Workers do benefit from being easily co-located in the same process with the pages/workers that spawn them, but once cross-process-capable APIs like MessageChannel/BroadcastChannel are involved, they are subject to the same communication latencies of Shared and Service Workers.

[indolering]

FWIW, SharedWorkers and ServiceWorkers are critical to decentralized web efforts. But if Apple already ripped out shared workers and Edge isn't willing to implement them, then perhaps the best move would be to extend ServiceWorkers.

[GrosSacASac]

Shared worker are good to control multiple pages, without using a service worker. Using the least responsibility principle I claim shared worker to stay. https://en.wikipedia.org/wiki/Principle_of_least_privilege

I don't always want to create a proxy between browser and server.

[indolering]

@GrosSacASac Apple already added and then removed support for shared workers. Enhancing service workers might be the only way to get this functionality added to other browsers....

[dinoluigivercotti]

Chrome for Windows, Mac, Linux, Android and iOS represents over 80% of all browsers, and is increasing.

Shared Workers solve the problems mentioned above while providing a clean separation of concerns between the various worker types.

Shared Workers are being used in large scale commercial web deployments, and becoming more pervasive. The genie is not going back in the bottle that easily.

Mozilla supports Shared Workers (actually a superior implementation) as does Opera. The longer this situation persists, the less likely Google will be to change things.

The others will just have to fall in line, or risk not being able to support these new generation web apps. Keep in mind Shared Workers allow near desktop app complexity, scalabilty, and performance - people are willing to pay for web apps that do that.

[indolering]

ServiceWorker is slowest because it requires secure Websockets (SSL).

@dcerisano I believe that Mozilla and Google are committed to not preventing future APIs from interacting with non-encrypted communications. If anything, your basically arguing for dropping shared workers 😈.

@GrosSacASac What if they made intercepting requests an opt-in feature?

@dinoluigivercotti Yeah! Screw 20% of users!

[GrosSacASac]

What if they made intercepting requests an opt-in feature? --> That would be not enough, shared worker have the ability to be multiple per page. And other features.

[indolering]

@GrosSacASac Yeah, that's what I figured. I guess the onus is on us to make SharedWorkers more useful. Maybe we just need to make SharedWorkers and WebWorkers less of a PITA to work with and provide a unified API.

[annevk]

Closing this per #2887 (comment). It seems there's some potential interest still from others and neither Chrome nor Firefox is inclined to remove.

[indolering]

Just wanted to followup with some thoughts: WebWorker, Shared WebWorker, and Service Worker are just different execution environments for the actor model – but without the niceties of a built-in API.

The Actor model is a natural fit for async-native modern JS: just define an interface via export and spawn a new worker. Instead, we are stuck hand-rolling an API, which prevents code sharing between projects.

Something needs to be done to reboot *Workers, very few users are willing to maintain 3 different code paths, fight obscure bugs sans a proper debugging environment, and auditing port.channel and origin/function issues is a nightmare.

I've seen similar proposals in the past (spawn and frozen realms?) but perhaps *WebActors could be the way out of the current *WebWorker chicken-and-egg stalemate.

[indolering]

Argh, sorry @annevk I just reread your penultimate post :p I just reviewed the ticket and @zcorpan's comment encouraging discussion prompted me to post. I'll stop hijacking this thread.

[SowingSadness]

We are using SharedWorker in big project. We have 1M+ uniq users every day.
SharedWorker+WebSocket save a lot of money for us.
ServiceWorker have no durable lifetime. We can't use it with websocket, cos ServiceWorker can shutdown in any moment.

[GrosSacASac]

@SowingSadness what is the project ? Are you using sharedworker to keep a persistent worker open across tabs ?
Have you tried to use simple worker + postmessage ? You can emulate shared worker that way. (at a great cost of efficiency)

I also hope that sharedworker stays in the html spec

[SowingSadness]

@GrosSacASac Hi. online.sbis.ru is that project. You can't use postmessage for cross tab messaging cos you haven't tab reference.
We are using localstorage + websocket in one tab for browser without sharedworker support, but in this case you can lost a message.

[GrosSacASac]

It is true there is no way to get the all the tabs references under the same origin out of nowhere. That is why Window.postMessage() is still limited and shared worker required.

[dcerisano]

Service Workers are just request handlers (like a thread pool). They exist to serve requests to services (eg. a cloud service or remote database) and expire. This prevents the DOM thread from blocking during requests. The term 'Worker' only means that work is being done off the DOM thread - any patterns that might block the UI. There won't be a single monolithic "Über Worker" redesign, as has been suggested - that might sound good to a project manager, but it would be an antipattern. Rather, look for more worker patterns soon, eg. GL Workers (Vulkans!).

[playground]

What is the alternative to Shared Worker if not all modern browsers are supporting it?

[GrosSacASac]

@playground

• Design web app so that it does not require multiple tabs open
• Share the work and the state on a separate server via HTTP for example
• Define a master ui main thread + window.postmessage
• Some things can be done with a service worker
• replicate the work on each tab and use localstorage, indexdb and co to share state

[dcerisano]

@playground when people start complaining about poor webapp performance, browser-shaming will force Shared Workers to become universally supported.

[SowingSadness]

@dcerisano shared worker is not about perfomance, it's about economy money in traffic and server infrastructure.

@GrosSacASac try to send messages from server to browser of 10 million users. All your suggestion not economy true

[GrosSacASac]

@SowingSadness

That is why browsers should support Shared Workers

[playground]

@GrosSacASac my use case does not require multiple tabs open, however does require some heavy lifting in the web worker and also leveraging indexedDB. I was exploring ways that I can spread the workload amount multiple workers to improve processing time since all devices come with multiple cores these days. With window.postmessage, one can only pass around structured data, I need a way to stitch all results back together and it's been proving to be a difficult task. I think Shared workers would be an ideal solution in this case.

[dcerisano]

@SowingSadness, not everything is about money - that would be depressing.

The Shared Worker pattern is about UI responsiveness and unblocking the user experience in complex web applications - ie seamless browser performance.

Ironically, the reason some browsers do not support Shared Workers is that they are too cheap to pay for the required development, testing and maintenance. They obviously consider user experience to be external to their business models.

[newtack]

Shared worker is critical for a project we work on. Hope that Microsoft and Apple support it.

[SowingSadness]

@newtack i think support will not be. In chrome a shared worker is buggy.

We used the shared worker for one websocket channel to browser in a domain. Today we have dropped support and migrate to a BroadcastMessage + logic in pages.

[newtack]

Thanks @SowingSadness.
Can you point me to a link with more info on BroadcaseMessage?
What benefits/downsides does this approach have, other than obviously being supported by all browsers?

[SowingSadness]

@newtack sorry, i mean a Broadcast Channel.
We have to many clients with slow PC. And we have responsibility for our product. In Chrome are using the shared worker not available for us. In Firefox, debugging the shared worker is hard, Cos you can’t attached to JS and can’t watching network requests.
In result this technology to expencive and don't bring profit

[newtack]

@SowingSadness Got it and thanks for the answer.
When I looked at caniuse.com neither Safari nor Edge support it. Do you not support those browsers or do you have another solution for them?

[SowingSadness]

@newtack we are using own polifill. It work around a localStorage. If your target mobile Safari too, you should forget about all technology of between tabs work. Cos the browser is big heap of bugs.

[ianlovejoy]

I also value 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 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.

(FYI I posted a nearly identical comment on a similar WebKit thread)