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

Comments

@annevk
Member

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

This comment has been minimized.

Show comment
Hide comment
@wanderview

wanderview Nov 6, 2015

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@jrburke

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

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

This comment has been minimized.

Show comment
Hide comment
@azasypkin

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

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Nov 7, 2015

Member

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

Member

annevk commented Nov 7, 2015

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

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Nov 7, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@wanderview

wanderview Nov 7, 2015

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@azasypkin

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

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

This comment has been minimized.

Show comment
Hide comment
@kinu

kinu 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).

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

This comment has been minimized.

Show comment
Hide comment
@sicking

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

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

This comment has been minimized.

Show comment
Hide comment
@lewispham

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

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

This comment has been minimized.

Show comment
Hide comment
@rianby64

rianby64 Sep 6, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@malko

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

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

This comment has been minimized.

Show comment
Hide comment
@sicking

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

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

This comment has been minimized.

Show comment
Hide comment
@lewispham

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

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

This comment has been minimized.

Show comment
Hide comment
@sicking

sicking 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

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

This comment has been minimized.

Show comment
Hide comment
@wanderview

wanderview Sep 8, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@dcerisano

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

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

This comment has been minimized.

Show comment
Hide comment
@asutherland

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

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

This comment has been minimized.

Show comment
Hide comment
@indolering

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

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

This comment has been minimized.

Show comment
Hide comment
@GrosSacASac

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

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

This comment has been minimized.

Show comment
Hide comment
@indolering

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

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

This comment has been minimized.

Show comment
Hide comment
@dinoluigivercotti

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

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

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering 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!

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

This comment has been minimized.

Show comment
Hide comment
@GrosSacASac

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

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

This comment has been minimized.

Show comment
Hide comment
@indolering

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

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.

@indolering

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering Nov 23, 2016

@dcerisano Mark as deprecated, it will either motivate everyone to either improve the SharedWorker implementation or enhance ServiceWorkers.

@zeropaper How would you decide which tab to store the SharedWorker in?

indolering commented Nov 23, 2016

@dcerisano Mark as deprecated, it will either motivate everyone to either improve the SharedWorker implementation or enhance ServiceWorkers.

@zeropaper How would you decide which tab to store the SharedWorker in?

@whatwg whatwg locked and limited conversation to collaborators Nov 23, 2016

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Nov 23, 2016

Member

I'm locking this for now since we primarily need input from implementers. I certainly did not mean to invite speculation.

Member

annevk commented Nov 23, 2016

I'm locking this for now since we primarily need input from implementers. I certainly did not mean to invite speculation.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 3, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering 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 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

This comment has been minimized.

Show comment
Hide comment
@indolering

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

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

This comment has been minimized.

Show comment
Hide comment
@SowingSadness

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

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

This comment has been minimized.

Show comment
Hide comment
@GrosSacASac

GrosSacASac 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

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

This comment has been minimized.

Show comment
Hide comment
@SowingSadness

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

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

This comment has been minimized.

Show comment
Hide comment
@GrosSacASac

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

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

This comment has been minimized.

Show comment
Hide comment
@dcerisano

dcerisano 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!).

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

This comment has been minimized.

Show comment
Hide comment
@playground

playground Dec 29, 2017

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

playground commented Dec 29, 2017

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

@GrosSacASac

This comment has been minimized.

Show comment
Hide comment
@GrosSacASac

GrosSacASac 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

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

This comment has been minimized.

Show comment
Hide comment
@dcerisano

dcerisano Dec 29, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@SowingSadness

SowingSadness 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

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

This comment has been minimized.

Show comment
Hide comment
@GrosSacASac

GrosSacASac Dec 29, 2017

@SowingSadness

That is why browsers should support Shared Workers

GrosSacASac commented Dec 29, 2017

@SowingSadness

That is why browsers should support Shared Workers

@playground

This comment has been minimized.

Show comment
Hide comment
@playground

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

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

This comment has been minimized.

Show comment
Hide comment
@dcerisano

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

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

This comment has been minimized.

Show comment
Hide comment
@newtack

newtack Oct 7, 2018

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

newtack commented Oct 7, 2018

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

@SowingSadness

This comment has been minimized.

Show comment
Hide comment
@SowingSadness

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

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

This comment has been minimized.

Show comment
Hide comment
@newtack

newtack 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?

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

This comment has been minimized.

Show comment
Hide comment
@SowingSadness

SowingSadness 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

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

This comment has been minimized.

Show comment
Hide comment
@newtack

newtack 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?

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

This comment has been minimized.

Show comment
Hide comment
@SowingSadness

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

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