[Web Install] Declarative vs Imperative version of cross-origin Web Install

[diekus]

Web Install is an imperative (JS) API. Is this better than declarative? What are the reasons for this?

[photopea]

I think everything would be so much easier if installing was as simple as writing

<a href="//www.google.com" target="_install">Install Google</a> 

and after clicking it, a browser would offer the user to install Google.com (the icon could be taken from the "href" URL from some tag, or its manifest.json). You would be able to install a webapp from an online store of webapps, without even opening a webapp.

I think a browser shouldn't have any trouble preventing the abuse of this mechanism. Just like browsers prevent the abuse of alert() for the past 30 years. Why does everything have to be done in the most complicated way?

[diekus]

hola @photopea! Thanks for the feedback. We definitely want a declarative entry point for the Install API. It is not discarded, and I think it's a perfect complement to the imperative version. We've certainly discussed a declarative version of Web Install, and for the first version we want to push out we've carefully considered how to avoid having multiple versions of the same app installed. You can see these slides that summarize a bit the complexity.

Specially for cross-origin installs, which is where this issue is relevant, we want to make sure that only web apps are allowed to be installed. This implies having a mandatory manifest_id and reinforcing the concept of an install_url as well. Potentially this could all be stated in a declarative way as follows:

<a href="//www.webapp.com" target="_install" app_id="<app id>" install_url="<install url>">Install Web App</a>

Even declaratively things start getting a bit more complex if we want to navigate away from a world where end users have N versions of the same app where N-1 of them aren't being able to be updated by the developer.

Working on the declarative approach allows us to get feedback for a navigator.install(<app id>,<install url>); and gives plenty of flexibility for developers to for example, query if an origin has permission to install apps, and then proactively remove the install UX and display a link using JS.

Nonetheless, I 100% agree and want a declarative version of this API, and I don't see any reason why both, declarative and imperative versions can't coexist. Appreciate the feedback and further discussion you might have on the topic!

cc @dmurph @amandabaker

[diekus]

@photopea following up on this, do you have any use cases you require with the install API that the shape of the API wouldn't be able to fulfill? Please let me know.

[dmurph]

Good to document this idea. I think it could compliment things if it's needed. I don't want to block the existing more flexible API from shipping on this though. This is a good follow-up if there is enough demand.

Cases where this might not be as suited:

• Sites like Adobe Creative Suite, MSFT 360, game sites like GeForce Now etc, which want to somtimes install a number of apps all at once.
  • The JS API makes this possible, although currently we are being conservative with user activation so only one would happen at a time - but possible for future. Especially possible for enterprise devices, where they may 'allow' their internal sites to call this more in this pattern.

[photopea]

I think "installing a webapp" should not be anything more than adding a website into bookmarks, but a bookmark will be on the homescreen, with a special icon, which opens the website without a brower UI. Manifest files should be optional.

I think it is a very wrong path to treat installed apps differently than websites, and to create a "new, parallel standard", making webapps which would exist "parallel" to websites, and developers would basically have to learn a new technology. I am afraid you want to turn "good old websites" into "Android", where apps would be extremely hard to get "verified" to be installed, and a website would require tons of effort to turn into a webapp.

So basically, an installed webapp should be a URL (similar to bookmarks). A specific URL can be "installed" (added to homescreen) just once.

[dmurph]

I think that generally matches how we are treating them as well. Some things 'only' make sense when you have OS integration, like handling files now can work (e.g. photopea can be a file handler for someone double clicking on .png file on their OS). And then now it's an OS entity, let it do things like specify the little 'shortcuts' / 'jumplist' things that appear when you right click on the dock icon on window/mac. But otherwise - yeah it's just a website / tab in a different dressing.

[photopea]

I have a JSON with web games, that I have created. I want to make a simple site, which loads this JSON and lets the visitor play these games, I made this: photopea.com/games.

I want to let the user add an icon of each game to their homescreen. Each game has a different URL, e.g.

• https://www.photopea.com/games/peasmaker
• https://www.photopea.com/games/dino-hunt-2

My PHP generates a custom manifest.json for each of these games (since Chromium doesn't allow it to be generated dynamically within a webpage). However, when I install one game, it considers all games to be installed. Is there a way to overcome this? This link says that it is discouraged to have multiple PWAs on the same domain.

I think that each URL should be allowed to be installed. The installation should be initiated by a website (by a visitor), and not by a web browser (and sending the "beforeinstallprompt" event). A browser should look for manifest.json only after the installation has been requested.

The current limitations do not help anyone, they only overcomplicate everything.