4 ms·
I work on the same team (Web DevRel) as the "service worker guy" you mention (Jake Archibald). Alex Russell (who introduced the "PWA" and is now advocating for
by kaycebasques 8y ago
I work on the same team (Web DevRel) as the "service worker guy" you mention (Jake Archibald). Alex Russell (who introduced the "PWA" and is now advocating for the "Never-Slow Mode" idea you may have heard about recently) works on Chrome but collaborates with us frequently.
> When I first heard someone talking about "Progressive Web Apps" I thought they were talking about "Progressive Enhancement"
Progressive enhancement is indeed where the P in PWA comes from. The core idea is to ship great sites for all users, and progressively upgrade with the latest web capabilities (service workers for offline, manifest for adding to homescreen and full-screen displays, and so on) when a user's device supports it. If the user's device doesn't support it, they should still get a good, traditional web experience: fast, secure, usable.
> Turns out doing a PWA is just basically about using the "Service Workers" API [2] and the practices around that.
Your first impression about progressive enhancement was closer to the mark. The PWA Checklist [1] is the canonical document about what constitutes a PWA. We created that doc in November 2016 [2] to try to clear up the massive confusion about the definition of a PWA, but apparently to no avail.
Under the "Baseline PWA" checklist you'll notice that there's mention of service workers and manifest files, but there's also mention of loading fast on 3G, having mobile-friendly design, being secure, supporting all browsers, and so on. Again, the core idea is to ship good experiences for all users, and progressively enhance the UX when possible.
It'd be an interesting postmortem to study why the "PWA" term has been so notoriously confusing. IMO part of the problem was that we as a team weren't 100% crystal-clear on the definition at the start. But to be fair, I think we did straighten out our messaging pretty early on. The PWA Checklist that I linked to which has been out since November 2016 is evidence of this. But by that time it was already too late. PWA became a buzzword, and the blogging community seemed to conflate "PWA" with "promising new web platform capabilities" (service workers and manifests). I don't mean to shift blame. We (Web DevRel) most likely caused that conflation. I think the takeaway is that this is a lesson on what can happen when you're not 100% clear on messaging right from the start.
[1] https://developers.google.com/web/progressive-web-apps/checklist https://developers.google.com/web/progressive-web-apps/check...
[2] https://github.com/google/WebFundamentals/commits/master/src/content/en/progressive-web-apps/checklist.md https://github.com/google/WebFundamentals/commits/master/src...
- nicoburns 8y agoI think the confusion comes from the fact that one of the key principles of "Progressive Enhancement" was making the site accessible to everyone by providing support for browsers that either don't support JavaScript or have it disabled. This version of the website often also supported much older browsers (e.g. IE6-8, but also lynx, etc) that weren't supported by the enhanced version of the website. In contrast, the PWA checklist makes no mention of support for browsers without JavaScript or much older browsers (and in practice very few PWAs provide such a fallback, as they are almost all SPA JavaScript apps where implementing this kind of fallback is difficult). As such, it is many ways the antithesis of the original Progressive Enhancement concept.