Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove shared workers? #315

Closed
annevk opened this issue Nov 6, 2015 · 60 comments
Closed

Remove shared workers? #315

annevk opened this issue Nov 6, 2015 · 60 comments

Comments

@annevk
Copy link
Member

@annevk annevk commented Nov 6, 2015

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
Copy link
Member

@wanderview wanderview commented Nov 6, 2015

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
Copy link

@jrburke jrburke commented Nov 6, 2015

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
Copy link

@azasypkin azasypkin commented Nov 6, 2015

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
Copy link
Member Author

@annevk annevk commented Nov 7, 2015

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

@annevk
Copy link
Member Author

@annevk annevk commented Nov 7, 2015

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
Copy link
Member

@wanderview wanderview commented Nov 7, 2015

@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
Copy link

@azasypkin azasypkin commented Nov 10, 2015

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
Copy link

@kinu kinu commented Nov 13, 2015

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
Copy link

@sicking sicking commented Nov 28, 2015

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
Copy link

@lewispham lewispham commented Sep 6, 2016

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.

picetalk application architecture

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
Copy link

@rianby64 rianby64 commented Sep 6, 2016

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

@malko
Copy link

@malko malko commented Sep 6, 2016

@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
Copy link

@sicking sicking commented Sep 6, 2016

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
Copy link

@lewispham lewispham commented Sep 6, 2016

@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
Copy link

@sicking sicking commented Sep 8, 2016

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
Copy link
Member

@wanderview wanderview commented Sep 8, 2016

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
Copy link

@dcerisano dcerisano commented Sep 22, 2016

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
Copy link

@asutherland asutherland commented Sep 22, 2016

@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
Copy link

@indolering indolering commented Nov 2, 2016

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
Copy link

@GrosSacASac GrosSacASac commented Nov 19, 2016

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
Copy link

@indolering indolering commented Nov 19, 2016

@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
Copy link

@dinoluigivercotti dinoluigivercotti commented Nov 20, 2016

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
Copy link

@indolering indolering commented Nov 20, 2016

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
Copy link

@GrosSacASac GrosSacASac commented Nov 20, 2016

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
Copy link

@indolering indolering commented Nov 20, 2016

@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
Copy link
Member Author

@annevk annevk commented Aug 3, 2017

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

@annevk annevk closed this Aug 3, 2017
@indolering
Copy link

@indolering indolering commented Aug 5, 2017

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
Copy link

@indolering indolering commented Aug 5, 2017

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
Copy link

@SowingSadness SowingSadness commented Oct 14, 2017

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
Copy link

@GrosSacASac GrosSacASac commented Oct 14, 2017

@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
Copy link

@SowingSadness SowingSadness commented Oct 15, 2017

@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
Copy link

@GrosSacASac GrosSacASac commented Oct 15, 2017

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
Copy link

@dcerisano dcerisano commented Oct 15, 2017

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
Copy link

@playground playground commented Dec 29, 2017

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

@GrosSacASac
Copy link

@GrosSacASac GrosSacASac commented Dec 29, 2017

@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
Copy link

@dcerisano dcerisano commented Dec 29, 2017

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

@SowingSadness
Copy link

@SowingSadness SowingSadness commented Dec 29, 2017

@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
Copy link

@GrosSacASac GrosSacASac commented Dec 29, 2017

@SowingSadness

That is why browsers should support Shared Workers

@playground
Copy link

@playground playground commented Dec 29, 2017

@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
Copy link

@dcerisano dcerisano commented Dec 30, 2017

@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
Copy link

@newtack newtack commented Oct 7, 2018

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

@SowingSadness
Copy link

@SowingSadness SowingSadness commented Oct 7, 2018

@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
Copy link

@newtack newtack commented Oct 7, 2018

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
Copy link

@SowingSadness SowingSadness commented Oct 7, 2018

@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
Copy link

@newtack newtack commented Oct 7, 2018

@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
Copy link

@SowingSadness SowingSadness commented Oct 7, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.