Re: [manifest] Integration with service workers (#161)

> That's a fair point. I guess the developer would have to specify a separate Service Worker in the manifest as an installation script, which then in turn registers other Service Workers which would also be registered in the browser. 

This is exactly what I don't want to ever see happen - and what worries me most about SW in the manifest. IMO, declarative solutions that allow for this level of discrimination ends up harming users most of all, because it (unwittingly) ends up only making features available to a subset of user agents - even if the developer wants to do the right thing, the manifest simply can't help them there. This is why the SW API is a better solution for all this.  
 
The consequences of adding SWs to manifest being: 
* the app will expect install in order to work properly. Ignoring legacy and no-supporting UAs with no ability to fallback (unlike the imperative SW API, which forces you into treating SW as a progressive enhancement). 
* The apps just start nagging users to "install my app! do it!! DO IT!!! DO!... IT!..." in order to get the "full experience". This is bad. 
* It increases the risk of: "this works best in Browsers X and Y!" which support service workers.

In the interest of not replicating features, and given the problems already outlined, I'm going to close this feature request. I think we should revisit this in a year or so once we've seen how people are using SWs in the wild. If search engines start working as marketplaces, then we can again revisit this.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/161#issuecomment-70196564