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

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,

```js
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).

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


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