Progressive Web Apps

[torgo]

@slightlyoff wrote a post defining progressive web apps. Many people are now talking about PWAs and building PWAs but there is no clear definition and some have started building PWAs which do not seem to embrace web best practices (e.g. thematic consistency). Should the TAG take a role in encouraging progressive web apps are built in the context of the web and not as just another way to build a mobile app?

[triblondon]

This is a topic of great interest in the developer community. Lots of commentary on this members may like to review. W3C member orgs are indicated.

• Beyond Progressive Web Apps Matthias Beitl
• The importance of URLs Stuart Langridge
• On URLs in Progressive Web Apps Bruce Lawson (Opera)
• Regressive web apps Jeremy Keith
• The ideal web experience Dion Almer
• State of the Gap Remy Sharp
• Regression towards being mean Jeremy Keith
• Progressive web apps and our regressive approach Chris Heilmann (Microsoft)
• Not the post I wanted to be writing Alex Russell (Google)
• Yet another blog about the state and future of progressive web apps Ada Edwards

I would suggest we consider these issues:

1. Definition of "progressiveness": What does it mean, should people do it, etc.
2. Canonical content addressing: Is it a problem if the same content is available in different forms from different URLs (eg intended to be used with different devices or viewing contexts, m-dot etc). Do PWAs encourage non-canonical copies of content and is that an architectural problem for the web?
3. Containment: Features that make websites less integrated into the fabric of the web and more like self-contained applications (often called "seamless"), are these bad for the web? Eg. hiding URLs and browser chrome, lack of deep linking ability, lack of discoverability in search etc.

It's also worth noting ad applauding the fact that the campaign to promote progressive web apps has had a positive impact on the reputation of the web as an alternative to native apps on mobile platforms.

[triblondon]

This is a topic of great interest in the developer community. Lots of commentary on this members may like to review. W3C member orgs are indicated.

• Beyond Progressive Web Apps Matthias Beitl
• The importance of URLs Stuart Langridge
• On URLs in Progressive Web Apps Bruce Lawson (Opera)
• Regressive web apps Jeremy Keith
• The ideal web experience Dion Almer
• State of the Gap Remy Sharp
• Regression towards being mean Jeremy Keith
• Progressive web apps and our regressive approach Chris Heilmann (Microsoft)
• Not the post I wanted to be writing Alex Russell (Google)
• Yet another blog about the state and future of progressive web apps Ada Edwards

I would suggest we consider these issues:

1. Definition of "progressiveness": What does it mean, should people do it, etc.
2. Canonical content addressing: Is it a problem if the same content is available in different forms from different URLs (eg intended to be used with different devices or viewing contexts, m-dot etc). Do PWAs encourage non-canonical copies of content and is that an architectural problem for the web?
3. Containment: Features that make websites less integrated into the fabric of the web and more like self-contained applications (often called "seamless"), are these bad for the web? Eg. hiding URLs and browser chrome, lack of deep linking ability, lack of discoverability in search etc.

It's also worth noting ad applauding the fact that the campaign to promote progressive web apps has had a positive impact on the reputation of the web as an alternative to native apps on mobile platforms.

[slightlyoff]

I don't understand this issue. There isn't a spec to review, although the TAG was given a preview of all the PWA thinking (and largely what has come to pass) in 2013 and supported it. Also, the TAG weighed in on the relevant specs (SW, Manifest, Permissions, Push, and a few others). What's left that the TAG can actually weigh in on meaningfully (i.e., not per-browser UI decisions).

[slightlyoff]

I don't understand this issue. There isn't a spec to review, although the TAG was given a preview of all the PWA thinking (and largely what has come to pass) in 2013 and supported it. Also, the TAG weighed in on the relevant specs (SW, Manifest, Permissions, Push, and a few others). What's left that the TAG can actually weigh in on meaningfully (i.e., not per-browser UI decisions).

[marcoscaceres]

I agree. Examining an aspirational blog post is probably not a great use of the TAG's time. It would be best to maybe revise some of the underlying specs that constitute PWAs instead; as many of those specs have been updated, have spun off new features (e.g., background sync) or are now in some form of "V2".

On 7 Jun 2016, at 6:29 AM, Alex Russell notifications@github.com wrote:

I don't understand this issue. There isn't a spec to review, although the TAG was given a preview of all the PWA thinking (and largely what has come to pass) in 2013 and supported it. Also, the TAG weighed in on the relevant specs (SW, Manifest, Permissions, Push, and a few others). What's left?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[marcoscaceres]

I agree. Examining an aspirational blog post is probably not a great use of the TAG's time. It would be best to maybe revise some of the underlying specs that constitute PWAs instead; as many of those specs have been updated, have spun off new features (e.g., background sync) or are now in some form of "V2".

On 7 Jun 2016, at 6:29 AM, Alex Russell notifications@github.com wrote:

I don't understand this issue. There isn't a spec to review, although the TAG was given a preview of all the PWA thinking (and largely what has come to pass) in 2013 and supported it. Also, the TAG weighed in on the relevant specs (SW, Manifest, Permissions, Push, and a few others). What's left?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[cwilso]

I'd say, actually, that the TAG might want to look in to some of these issues, but not as a review of "Progressive Web Apps".

• Definition of progressiveness, and how best to build a progressive experience across modern browsers and devices
• strategies for offline and instant loading
• Canonality
• Encouraging deep linking
• Thematic consistency

Overall, the point of progressive web apps is simply to raise the bar for web-platform-based user experiences - to provide reliable, performant and engaging experiences.

I'd argue quite strongly that hiding URLs in browser chrome and similar browser UI decisions aren't useful to have the TAG investigate, BTW.

[cwilso]

I'd say, actually, that the TAG might want to look in to some of these issues, but not as a review of "Progressive Web Apps".

• Definition of progressiveness, and how best to build a progressive experience across modern browsers and devices
• strategies for offline and instant loading
• Canonality
• Encouraging deep linking
• Thematic consistency

Overall, the point of progressive web apps is simply to raise the bar for web-platform-based user experiences - to provide reliable, performant and engaging experiences.

I'd argue quite strongly that hiding URLs in browser chrome and similar browser UI decisions aren't useful to have the TAG investigate, BTW.

[torgo]

Good comments. Considering all the energy being spent in the web community discussing and debating this topic it really feels like the TAG should say something here. I like @cwilso's idea of focusing in on architectural principles. Please note we can change the name of the issue but I do think these fit together. In any case we are due to discuss on today's call.

[torgo]

Good comments. Considering all the energy being spent in the web community discussing and debating this topic it really feels like the TAG should say something here. I like @cwilso's idea of focusing in on architectural principles. Please note we can change the name of the issue but I do think these fit together. In any case we are due to discuss on today's call.

[triblondon]

I have a keen interest in lots of aspects of PWAs, so I'm painfully aware of not wanting to detail us into a discussion with no purpose.

Chris's suggested topics look good and I'd maybe narrow further to just progressiveness, canonality and thematic consistency, which seem like the weighty architectural issues here.

[triblondon]

I have a keen interest in lots of aspects of PWAs, so I'm painfully aware of not wanting to detail us into a discussion with no purpose.

Chris's suggested topics look good and I'd maybe narrow further to just progressiveness, canonality and thematic consistency, which seem like the weighty architectural issues here.

[torgo]

Discussed on June 8th teleconerence. Agreed to keep working in this issue on refining the scope of work here. General support for the notion of progressive webapps and a call for ensuring such developments continue to follow web architecture principles.

[torgo]

Discussed on June 8th teleconerence. Agreed to keep working in this issue on refining the scope of work here. General support for the notion of progressive webapps and a call for ensuring such developments continue to follow web architecture principles.

[mnot]

Somewhat relevant from Eran:
https://hueniverse.com/2016/06/08/the-fucking-open-web/

Progressive web apps might be the future but if you are a startup trying to build new experiences, front end web development is probably at its lowest point. Mobile Safari is the new IE6. We have more amazing technology than ever before but we also have so much diversity of platforms, browsers, and screen types, that building a consistent experience pretty much means using almost none of it.

...

We are going to build native apps because it turns out, it’s cheaper. It’s cheaper to build multiple proprietary applications than one responsive web app. As a CEO I can plan and predict the cost of building native apps, even with the required upgrades and annual breaking changes. I can’t when it comes to the web.

Now, it doesn’t mean we are giving up. I much rather build for the web and nothing else. But it pisses me off every time I see a Twitter thread about how native apps are destroying the free world. Open standards are always going to be inferior to closed ones.

[mnot]

Somewhat relevant from Eran:
https://hueniverse.com/2016/06/08/the-fucking-open-web/

Progressive web apps might be the future but if you are a startup trying to build new experiences, front end web development is probably at its lowest point. Mobile Safari is the new IE6. We have more amazing technology than ever before but we also have so much diversity of platforms, browsers, and screen types, that building a consistent experience pretty much means using almost none of it.

...

We are going to build native apps because it turns out, it’s cheaper. It’s cheaper to build multiple proprietary applications than one responsive web app. As a CEO I can plan and predict the cost of building native apps, even with the required upgrades and annual breaking changes. I can’t when it comes to the web.

Now, it doesn’t mean we are giving up. I much rather build for the web and nothing else. But it pisses me off every time I see a Twitter thread about how native apps are destroying the free world. Open standards are always going to be inferior to closed ones.

[marcoscaceres]

Don't feed the troll, @mnot.

[marcoscaceres]

Don't feed the troll, @mnot.

[triblondon]

I see this on the agenda for this week. Maybe we can progress this by sorting out what is architecture and what is not, and whether PWAs have anything to say about the bits that are.

• "Progressiveness": is this a marketing buzzword that means whatever you want it to mean, or should it have a technical definition? If the latter, then I think it would be helpful for us to offer one, and determine how or whether PWAs fit that definition. If the former, then this is not a technical concern.
• Canonical content: The very purpose of the web platform is to offer interop between proprietary systems. Therefore is the use of web platform to deliver platform specific experience (the likes of m.) an architectural concern? This may be an interesting question to answer but I suspect Alex will argue that PWAs do no such thing, and the focus on mobile is simply an expression of the urgency of the need for the web to do better on that platform. I would accept that with some hope amid positive signs of change on this front.
• Containment: The ability to display sites in a standalone/fullscreen manner is certainly architecture, and is part of a spec that has already got wide support. The additional element PWAs bring is to say that all sites should be PWAs and all PWAs should be standalone/fullscreen. That containment arguably does not suit all use cases and is why the spec offered the developer a range of options in the first place.

So, if you accept my logic above, then this issue boils down to:

1. If 'progressive' is a technical term, then what does it mean?
2. Does the development of the Lighthouse testing tool and the rules it contains constitute a narrowing of the manifest specification?

It's worth reflecting on the fact that while specs might be canonical, one powerful vendor's interpretation of 'the good parts' can be orders of magnitude more powerful as an influence on developer behaviour.

[triblondon]

I see this on the agenda for this week. Maybe we can progress this by sorting out what is architecture and what is not, and whether PWAs have anything to say about the bits that are.

• "Progressiveness": is this a marketing buzzword that means whatever you want it to mean, or should it have a technical definition? If the latter, then I think it would be helpful for us to offer one, and determine how or whether PWAs fit that definition. If the former, then this is not a technical concern.
• Canonical content: The very purpose of the web platform is to offer interop between proprietary systems. Therefore is the use of web platform to deliver platform specific experience (the likes of m.) an architectural concern? This may be an interesting question to answer but I suspect Alex will argue that PWAs do no such thing, and the focus on mobile is simply an expression of the urgency of the need for the web to do better on that platform. I would accept that with some hope amid positive signs of change on this front.
• Containment: The ability to display sites in a standalone/fullscreen manner is certainly architecture, and is part of a spec that has already got wide support. The additional element PWAs bring is to say that all sites should be PWAs and all PWAs should be standalone/fullscreen. That containment arguably does not suit all use cases and is why the spec offered the developer a range of options in the first place.

So, if you accept my logic above, then this issue boils down to:

1. If 'progressive' is a technical term, then what does it mean?
2. Does the development of the Lighthouse testing tool and the rules it contains constitute a narrowing of the manifest specification?

It's worth reflecting on the fact that while specs might be canonical, one powerful vendor's interpretation of 'the good parts' can be orders of magnitude more powerful as an influence on developer behaviour.

[marcoscaceres]

On July 5, 2016 at 1:47:42 PM, Andrew Betts (notifications@github.com) wrote:

I see this on the agenda for this week. Maybe we can progress this by sorting out what is
architecture and what is not, and whether PWAs have anything to say about the bits that
are.

• "Progressiveness": is this a marketing buzzword that means whatever you want
  it to mean, or should it have a technical definition? If the latter, then I think it would
  be helpful for us to offer one, and determine how or whether PWAs fit that definition.
  If the former, then this is not a technical concern.

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". For example,

if(navigator.whatever){
  // progressively enhance
} else {
  // doing it ol' school
}

Same principle in CSS - where, for instance, you once had a default
bg-color where gradients are not supported. The is are all part of the
architecture (and was in place long before the expression "progressive
web design" was coined). It's a real thing. It's an architectural
concern for standards engineers: and it's quite evident the design of
Service Workers.

• Canonical content: The very purpose of the web platform is to offer interop between
  proprietary systems. Therefore is the use of web platform to deliver platform specific
  experience (the likes of m.) an architectural concern? This may be an interesting
  question to answer but I suspect Alex will argue that PWAs do no such thing, and the focus
  on mobile is simply an expression of the urgency of the need for the web to do better on that
  platform. I would accept that with some hope amid positive signs of change on this front.

Agree.

• Containment: The ability to display sites in a standalone/fullscreen manner
  is certainly architecture, and is part of a spec that has already got wide support.

It's actually part of 3 specs: web manifest, orientation lock, and
full screen API.

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 that this happened for a period of time (in Chrome). Opera
supports PWAs with browser as the display mode. I would not be
surprised if Google started to support "browser" as one of the
installability signals.

Speaking of which, those are non-normative in the spec:
https://w3c.github.io/manifest/#installability-signals

That containment arguably does not suit all use cases and
is why the spec offered the developer a range of options in the first place.

Not only that: web manifest makes "browser" the default.

So, if you accept my logic above, then this issue boils down to:

1. If progressive is a technical term, then what does it mean?

Make it detectable - make it polyfillable... or make it so it can be
de-sugared. If it can't, that's ok: but then work on enabling future
things to be (e.g., Houdini).

1. Does the development of the Lighthouse testing tool and the rules it contains constitute
   a narrowing of the manifest specification?

Sorry, I don't know what this is asking.

It's worth reflecting on the fact that while specs might be canonical, one powerful vendor's
interpretation of 'the good parts' can be orders of magnitude more powerful as an influence
on developer behaviour.

Agree - but we've been fortunate that vendors have been behaving in an
open and inclusive manner. At Mozilla, we are legitimately excited to
see what Google, Opera, and Samsung have been doing (not just as at
the lowly Engineer level - but throughout the company). We are even
more thrilled to hear Microsoft talking about PWAs, and are looking
forward to seeing what they come out with over the next year or two.
The PWA Summit, though Google-heavy in the first day, really showed
the power of inclusion: not only of vendors, but also of the dev
community (e.g., giving folks like Jeremy Keith a chance to ruthlessly
question implementers, product managers, standards folks - and break
through any marketing BS - it was a little uncomfortable, but oh my
was it so refreshing!).

Many people are watching, and not uncritically, what is happening in
this space: and yes Google is dominating the discussion right now, but
there are plenty of people willing to call BS (and have!) on various
assumptions. This has yielded quite a few course corrections - which
has been great.

[marcoscaceres]

On July 5, 2016 at 1:47:42 PM, Andrew Betts (notifications@github.com) wrote:

I see this on the agenda for this week. Maybe we can progress this by sorting out what is
architecture and what is not, and whether PWAs have anything to say about the bits that
are.

• "Progressiveness": is this a marketing buzzword that means whatever you want
  it to mean, or should it have a technical definition? If the latter, then I think it would
  be helpful for us to offer one, and determine how or whether PWAs fit that definition.
  If the former, then this is not a technical concern.

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". For example,

if(navigator.whatever){
  // progressively enhance
} else {
  // doing it ol' school
}

Same principle in CSS - where, for instance, you once had a default
bg-color where gradients are not supported. The is are all part of the
architecture (and was in place long before the expression "progressive
web design" was coined). It's a real thing. It's an architectural
concern for standards engineers: and it's quite evident the design of
Service Workers.

• Canonical content: The very purpose of the web platform is to offer interop between
  proprietary systems. Therefore is the use of web platform to deliver platform specific
  experience (the likes of m.) an architectural concern? This may be an interesting
  question to answer but I suspect Alex will argue that PWAs do no such thing, and the focus
  on mobile is simply an expression of the urgency of the need for the web to do better on that
  platform. I would accept that with some hope amid positive signs of change on this front.

Agree.

• Containment: The ability to display sites in a standalone/fullscreen manner
  is certainly architecture, and is part of a spec that has already got wide support.

It's actually part of 3 specs: web manifest, orientation lock, and
full screen API.

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 that this happened for a period of time (in Chrome). Opera
supports PWAs with browser as the display mode. I would not be
surprised if Google started to support "browser" as one of the
installability signals.

Speaking of which, those are non-normative in the spec:
https://w3c.github.io/manifest/#installability-signals

That containment arguably does not suit all use cases and
is why the spec offered the developer a range of options in the first place.

Not only that: web manifest makes "browser" the default.

So, if you accept my logic above, then this issue boils down to:

1. If progressive is a technical term, then what does it mean?

Make it detectable - make it polyfillable... or make it so it can be
de-sugared. If it can't, that's ok: but then work on enabling future
things to be (e.g., Houdini).

1. Does the development of the Lighthouse testing tool and the rules it contains constitute
   a narrowing of the manifest specification?

Sorry, I don't know what this is asking.

It's worth reflecting on the fact that while specs might be canonical, one powerful vendor's
interpretation of 'the good parts' can be orders of magnitude more powerful as an influence
on developer behaviour.

Agree - but we've been fortunate that vendors have been behaving in an
open and inclusive manner. At Mozilla, we are legitimately excited to
see what Google, Opera, and Samsung have been doing (not just as at
the lowly Engineer level - but throughout the company). We are even
more thrilled to hear Microsoft talking about PWAs, and are looking
forward to seeing what they come out with over the next year or two.
The PWA Summit, though Google-heavy in the first day, really showed
the power of inclusion: not only of vendors, but also of the dev
community (e.g., giving folks like Jeremy Keith a chance to ruthlessly
question implementers, product managers, standards folks - and break
through any marketing BS - it was a little uncomfortable, but oh my
was it so refreshing!).

Many people are watching, and not uncritically, what is happening in
this space: and yes Google is dominating the discussion right now, but
there are plenty of people willing to call BS (and have!) on various
assumptions. This has yielded quite a few course corrections - which
has been great.

[triblondon]

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!

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.

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. 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.

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. 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.

[triblondon]

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!

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.

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. 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.

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. 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.

[marcoscaceres]

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 :)

[marcoscaceres]

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 :)

[torgo]

Discussed on TAG call 6 July 2016.

[torgo]

Discussed on TAG call 6 July 2016.

[torgo]

Is there an issue that TAG could feed back to Lighthouse testing tool? Agreed to query Lighthouse project on the manifest test specifically (stand alone / full screen)...

[torgo]

Is there an issue that TAG could feed back to Lighthouse testing tool? Agreed to query Lighthouse project on the manifest test specifically (stand alone / full screen)...

[torgo]

Agreed to keep issue pending lighthouse discussion - but continue to discuss specifics in this area and open up a new issue on canonical URLs.

[torgo]

Agreed to keep issue pending lighthouse discussion - but continue to discuss specifics in this area and open up a new issue on canonical URLs.

[marcoscaceres]

I cited some scary numbers for them to get a sense of why "standalone" as a default is really dangerous for the ecosystem (in the it diminishes trust in web applications), and bad for users in general... worst case, browsers will skip standalone and always do "minimal-UI" because most apps are not usable without a back button or access to the URL bar.

[marcoscaceres]

I cited some scary numbers for them to get a sense of why "standalone" as a default is really dangerous for the ecosystem (in the it diminishes trust in web applications), and bad for users in general... worst case, browsers will skip standalone and always do "minimal-UI" because most apps are not usable without a back button or access to the URL bar.

[marcoscaceres]

• minimal-ui, even.

[marcoscaceres]

• minimal-ui, even.

[torgo]

Discussed at Stockholm f2f and agreed to close.

[torgo]

Discussed at Stockholm f2f and agreed to close.