5 ms·

When I first heard someone talking about "Progressive Web Apps" I thought they were talking about "Progressive Enhancement" [1]. Turns out doing a PWA is just

When I first heard someone talking about "Progressive Web Apps" I thought they were talking about "Progressive Enhancement" [1]. Turns out doing a PWA is just basically about using the "Service Workers" API [2] and the practices around that. This nice article does a lengthy trace on the origins of the "PWA" term [3]. The same guy that started the "Service Workers" spec in Github [4] created the PWA marketing campaign, apparently. Makes me wonder why he thought it was more marketable to sell this PWA idea more than the simpler and more direct message: "use Service Workers". The PWA campaign also reminds me of the less successful "Offline First" campaign from a couple of years ago [5]. 1: https://alistapart.com/article/understandingprogressiveenhancement https://alistapart.com/article/understandingprogressiveenhan... 2: https://jakearchibald.github.io/isserviceworkerready/ https://jakearchibald.github.io/isserviceworkerready/ 3: https://medium.com/@amberleyjohanna/seriously-though-what-is-a-progressive-web-app-56130600a093 https://medium.com/@amberleyjohanna/seriously-though-what-is... 4: https://github.com/w3c/ServiceWorker/tree/c49c878cdcbaf7a81e9e8cf3cca9970787017a19 https://github.com/w3c/ServiceWorker/tree/c49c878cdcbaf7a81e... 5: http://offlinefirst.org/ http://offlinefirst.org/

abraae 8y ago
Maybe he took his lead from the success of "Ajax" as opposed to "XMLHttpRequest Objects".
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 ago
  I 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.

abraae 8y ago

Maybe he took his lead from the success of "Ajax" as opposed to "XMLHttpRequest Objects".

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