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

> 1) As awesome as Service Workers are, approximately 0% of web apps (even top tier web apps) currently use them, it's probably going to take several years for this technology to become widespread. Is it fair to insist that adoption of the W3C web manifest is fully dependent on the adoption of Service Workers, given that one is significantly more straightforward to add to an existing web app than the other? 

No. It's why I'm insisting we look at other uses - like using them to create beautiful speed dial boxes. 

> Is no cross-platform Facebook web app really better than a cross-platform Facebook web app that doesn't provide a great offline experience? Should we be forcing that product decision on all app developers?

Yes. An experience that I can't access when I'm offline is not an experience: it's just an `about:blank` web page :( That should hopefully never happen for a web app. 

2) Is the registration of a Service Worker alone really a good indication of quality, or that the app provides an offline experience? An app could register a Service Worker for another reason and not provide any offline experience at all.

The indicator is the use of a cache, not the service worker itself. Yes, this will require complicated heuristics to determine what is "scaffolding" and what is "content" - but we can evolve those over time. 

> 3) What if someone actually wants to create an app which doesn't use Service Workers? 

 :see_no_evil: :hear_no_evil: :speak_no_evil:  BLASPHEMY!! :see_no_evil: :hear_no_evil: :speak_no_evil:   

> What if the entire purpose of an app is not to store any data on your device, but you still want to add it to your homescreen with a shiny icon and it open with no URL bar?

The user will/should always have the option to "add to homescreen" - irrespective of browser heuristics. 

> 4) Maybe it's a fair assumption that Service Worker registrations will survive the install process, but what if it isn't? What if the browsing context on a given operating system uses a completely different rendering engine to the application context it installs?

This is very academic. I just don't see this ever happening. All this stuff assumes very tight integration between the browser and the OS. Just like we (Moz) don't allow other engines to be installed on FxOS - and iOS doesn't allow other engines, it's unlikely anyone will be able to "brain transplant" an install of a web application. 

>  Wouldn't it be helpful to be able to populate the Service Worker cache at install time so that it works offline the first time you launch it?

If and only if we see situations like the above actually occurring in the market. Otherwise, we would just be solving a theoretical problem, "just in case":tm:.  

5) Is it really that evil to have a web app which works online in the browser and only downloads all of its assets to your device if you actively "install" it, rather than if you just happen to visit one of its pages in the browser? Should we be taking that design decision away from developers?

The architectural model that we've chosen for installable web apps is to not let the developer know if the app is installed or not (they should not care). This is to avoid "INSTALL MY APP TO GET THE FULL EXPERIENCE" badges all over the web, as happened with iOS. It's a tradeoff.  

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