timcase
commented
5 years ago I don't think adding PWA features to this template is a good idea. It's my opinion that the typical user of your template is just building a plain old web app and they won't be doing anything PWA so this imposes a default that most won't use. The second reason is more subtle but I think more important, I think Elm users should not be given the idea that creating a PWA could be as simple as generating an app manifest and serviceworker.js and attached your project to them.
An app manifest will allow a user of an app to add the app to their mobile home screen and then launch the app as if it were native. App manifests can be generated and I think the most useful generator can be found at www.pwabuilder.com because the generator builds an app manifest based on values and app icons uploaded by the user. Any app manifest you provide in a starter kit might be placeholder but it's not very helpful.
The real problem however is with service workers. Service workers allow for the really interesting features for which a person might want to do a PWA. For instance, caching and offline functionality. In order to take advantage of serviceworkers an app must make it's requests with the fetch api. Elm makes it's requests with xmlhttprequest and thus is INCOMPATIBLE with building a service worker out of the box.
In short
- Most elm webpack starter kit users are not building a PWA so it's a poor choice for a default
- Adding it as a default in a starter kit kinda implies that doing a PWA in Elm is so easy that it's something you can just add to any Elm project. It's not. The people who really need to do PWA will able to add this themselves manually.
I don't mean to be a debbie downer and I hope somebody contradicts me by saying PWA in Elm is easy, but I found that not to be the case and I'm trying to help others learn what I did the hard way.
source: https://www.reddit.com/r/elm/comments/7yjiao/elm_progressive_web_apps_service_workers_and/
rlopzc
Info
Related
14