Re: [w3ctag/spec-reviews] Progressive Web Apps (#123)

On July 5, 2016 at 4:35:22 PM, Andrew Betts (notifications@github.com) wrote:
> > It's a design strategy, that is supported by underlying standards. The ability to feature-detect,
> de-sugar, and polyfill are critical, architecturally, to "progressiveness"
>
> That sounds like one reasonable opinion. Objectively there is disagreement about what
> progressiveness means. At some level, who cares. Let's just say it's a marketing term
> and it means what you want it to mean in the context in which you use it!


No, it's much more serious than you think. We've had these kinds of
screw-ups before where, for instance, aspects of the Geolocation API
were labelled [NoInterfaceObject], which meant they were not
accessible to developers for polyfilling.

Then, whole bunch of other specs copy/pasted Geolocation because it
was, for a while, deemed a "good API"(TM). Then a bunch of us had to
go and track down all the specs that were using [NoInterfaceObject]
and yell at people to remove that (mostly because they didn't know
what it actually did).

I believe Geolocation still makes incorrect use of
[NoInterfaceObject], and we never managed to fix that in the web
platform: but we learned a valuable lesson around "progressive
enhancements" during that time.


> > > The additional element PWAs bring is to say that all sites should be PWAs and all PWAs
> should be standalone/fullscreen.
>
> > I would argue this is not true at all - and it's just an accident of history
>
> Currently, the community Lighthouse validator will fail any candidate PWA that does
> not declare standalone or fullscreen in its manifest display property. So what I am saying
> is true, I believe, in relation to Google's definition of PWAs.

I don't know what the Lighthouse validator is, but we should get that
fixed ASAP.

> In reality whether or not an app passes a particular ruleset offered by a validator doesn't
> matter unless those rules are being enforced with some kind of carrot (eg an install prompt)
> or stick (eg deranking in search). If a popular browser refuses to pop an install prompt
> unless the app is standalone, then all apps will be standalone, regardless of whether
> that is appropriate for their use case, regardless of what the default in the spec is.

Correct. It's a bit of a race to the bottom.

> That's how developer incentives work. The history of the web is littered with examples
> of how developers and browsers are influenced by each other's behaviour, not by what
> the spec says.

Again, I can only agree: but I think Google got the message pretty
loud and clear that their current default is not ideal. Again, I still
think what Google did was good and right - they are aggressively
experimenting and allowing us all to learn from their experience.

> So I'm not sure where that leaves us in terms of commenting on architectural issues, because
> I guess we are mostly talking about vendor-specific behaviours that are not the subject
> of specs - and Google, Mozilla, Opera and Microsoft are looking at different heuristics
> and rules for their respective install prompts.

You are correct with respect to the above: so, there is a cautionary
tale there about market dominance and the unintended consequences of
that position: You are absolutely correct that people are currently
being forced into "standalone", and that's not great.

> What may well shake out here is that the
> practical definition of a PWA is the union of all the rules and heuristics that each vendor
> comes up with to earn an install prompt in their browser.
>
> Since I can't find any solid ground for an architecture discussion here I'm happy to close
> this.

Fair enough. Was fun chat tho :)


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/123#issuecomment-230401717