PWA Support

[imhoffd]

We need an official response to devs wanting to create PWAs using Ionic. The first experience they'll have with Ionic is using the CLI. Let's guide them through the process and provide tools and resources for building PWAs.

• https://github.com/ionic-team/ionic-cli/issues/3800

[jgw96]

Just some early thoughts on this:

Needs (imo atleast)

• I think it would be awesome to make this a PWA platform. So just like cordova has an android platform we could have a PWA platform. Im thinking something like ionic build PWA --prod.

• For PWA prod builds we should build a service worker using workbox with pre-caching setup. The user could also customize this using the workbox config file.

• Manifest creation (which our starters already include) but dynamic in that it could link to the icon after ionic resources is ran etc

• PWA build should include the minimum things needed for a PWA, a service worker and a manifest

Nice to have's

• Warnings if javascript bundles get above a certain size (create-react-app and the preact cli do this)
• Easy deploy to a hosting service
• We should also not include the script tag pointing at cordova.js

[mhartington]

Similar to the cordova functionality, I think we can create a ionic pwa set of commands that are more specialized. All it really needs is to run the ionic:build command to be able to deploy. Are we looking to provide more functionality for things such as service worker generation/dynamic manifest creation?

[imhoffd]

We probably don't need to discuss command names, etc. More so talk about the experience and what functionally needs to happen.

📝 A prerequisite to all this is probably me going into the starters and ripping out the initial Cordova integration for good. That means when ionic cordova commands are first run in an app, the integration is activated and all the necessary files (config.xml and default resources) are downloaded, cordova.js include is added to index.html, etc.

📝 We need a way to guide users during/after ionic start. I want to ask them which "platforms" they choose to target, such as Cordova or Electron or PWAs.

[sachingarg05]

If choosing a true PWA or non Cordova implementation, please consider the additional effort needed by app developers (and within Ionic framework) to target both from a unified code base. I suspect something similar to #if CORDOVA ... #elseif PWA might get sprinkled all over the code.

Fixing/supporting ionic cordova build/run browser can let developers have one codebase target both native apps and the web. It will keep the #ifdefs isolated within the plugins and plugin's browser implementation. For many developers (including us), their existing Ionic+Cordova based apps will 'just work'.

Over time we are likely to see many existing Cordova plugins retire, but new ones will definitely appear. Most Cordova plugins already support the browser platform. And Cordova is moving towards making their plugin APIs compatible with standard web APIs wherever possible so that individual plugins can be retired with time. But I am sure there will be other new stuff coming up in native platforms which will require newer plugins till the standard web catches up.

[imhoffd]

Thanks, @sachingarg05. This is why the Cordova browser platform is attractive: it translates Cordova Plugin API code that people have already written in their app into the Web Standards code that I linked to you (https://whatwebcando.today/). (Assuming the Cordova plugin(s) support the browser platform, right?)

[sachingarg05]

Yes, either way the final code that runs in a end-user's browser will do the same thing using same web API :-)

Supporting native PWA builds vs leveraging cordova browser platform will only effect how the code and build scripts are structured etc, both within Ionic and in Apps.

[mhartington]

@dwieeb One of the issues with the cordova browser platform though is the tooling/support around it has been pretty limited. In my test some time ago, it wasn't a viable platform and often the plugin code was less than great.

On the other hand, the cordova folks are starting to migrate all the plugins and their APIs to match the browser standards. We, in theory, could forego any cordova interaction for this, since it will just use the standard API.

[janpio]

📝 The www folder having different content depending on what was built (cordova, pwa, serve) could become a problem. There could be a pwa folder the PWA is "built" into that can be used as the base for a "PWA deploy".

@sachingarg05 Is there an overview of the most popular Cordova plugins and their browser support somewhere?

[janpio]

📝 If you see this "pwa" thing equivalent to a "cordova" integration (and later maybe "electron"), it might be beneficial to have commands to explicitly add/remove/activate/deactivate these. E.g. ionic integration add pwa. ionic integration list or ionic integration remove cordova additionally to the questionnaire that ionic start shows.

[sachingarg05]

@janpio I don't know if that information is available easily but as @mhartington said, it is a mixed bag when it comes to quality of cordova plugin's browser support.

I would imagine that Camera plugin would be one of the very popular plugins, but it has terrible browser implementation which can only work for building/testing/proof-of-concept but absolutely can't be used in a production app. On the other hand the geolocation plugin's browser implementation is great. So it varies.

Only argument I can make in favor of cordova plugins is that it will facilitate pooling of developers' efforts - one person implementing good browser support for a plugin makes it available for everyone. Compared to everyone implementing their own non-cordova implementation for a PWA build.

Your argument in favor of having a single www folder is also important. I haven't tried this, but if the www folder contents are same for different types of builds we can have a single hosted pwa version which is also loaded in the cordova ios/android builds over-the-air.

I just feel that supporting cordova browser platform might be significantly less work for ionic team and app developers compared to adding another pwa 'platform'. But @mhartington 's desire to not have to carry cordova around for a PWA is also understandable.

At the end, its only a code structure and build script issue because in both cases the resulting output code and API calls that run on user's browser will be almost exactly the same. (It won't effect the capabilities of the platform).

[janpio]

(As I don't want to hijack this discussion here to make it about the browser platform - I think Mike has a good point here and making PWA a first class Ionic integration instead of "just" a Cordova platform makes sens - I created two forum topics about this: https://forum.ionicframework.com/t/overhead-or-disadvantages-of-cordova-browser-platform/102459 https://forum.ionicframework.com/t/what-cordova-plugins-actually-have-a-working-thorough-browser-implementation/102460)

[chrisgriffith]

I think adding a PWA template option would be a great start. Some things I would like to see added or changed:

1) update the index.html file to include the various web icons, as well as the apple-web-app meta tags 2) Include a default icon that the manifest.json references in the assets folder 3) have the CLI's resource command generate icons for the manifest.json and update it. 4) Update the app name in the manifest.json if one is supplied in the ionic start command 5) If there is a pwa template, have the service worker code enabled by default 6) Remove reference to the Cordova plugins: splashscreen and statusbar in the app.component.ts file