I always thought it was a web app that functions reasonably even on older browsers with JS turned off (for example). Then the experience gets "progressively better" if you have a newer browser, and allow JS to execute.
I thought use of the Service Worker API was the primary feature defining a PWA. If it's a SPA and is able to be used offline, then it's a PWA. Also, lots of people then use Web App Install banners for PWAs.
My favorite part of the whole PWA marketing push is that they encourage use of the Service Worker API for offline caching, but leave cache invalidation / cleanup as an exercise to the reader. "Do it the way it makes sense for your application" is a technically correct answer, but I assume translates to "never" for 99% of us with tight deadlines.
> And I'm pretty sure SPA is also not a criteria for PWAs, it's just a suggestion.
Fair enough, you could certainly use Service Worker API for an app with multiple pages. What I was trying to capture with the term SPA is more "web app", although I suppose you could even use Service Worker API with a simple static site.
I have a SPA and have 'converted' it into a PWA. My motivation for that largely has been to better control the way assets are cached on the client, I can now control better with the service worker, but there is one really nice benefit:
With the PWA, android devices (hopefully iPhone soon too) can 'install' the PWA to the device without going through Google Play Store (in fact, you can have the PWA install the android app available on Play Store instead, if you prefer). This makes the web-page appear to the user as an app, with a nice icon, and snappy performance relative to opening a link in chrome (even though it is a chrome instance running the 'installed PWA')
"Progressive Web App" is branding. I think, as a developer, you can feel free to ignore the term entirely and instead focus on the Service Worker API, Notifications API, Push, etc. etc.
However, when you're talking to a product manager or some other higher-up that doesn't have the same level of technical insight, this bundle of technologies becomes very time-consuming to explain. That's when you break out "Progressive Web App" - a web site that progressively becomes more like an app the more people use it.
> a web site, that progressively becomes more like an app the more people use it.
I like how you've given the best definition in this thread, and IMHO shown that it's a concept that goes beyond this or that API, right after giving us the its-marketing-for-nontechnical-idiots spiel.
Heh, I just think "PWAs" are like the famous definition of obscenity - you know it when you see it. But that doesn't translate very well (or, at all) to actual technical requirements, so we talk about specific APIs at appropriate points.
And I wouldn't say the non-technical folks are idiots! They know a lot of stuff I don't, you just need to nail the overlap in what we both know. And given how difficult it is to explain the Service Worker API to even a skilled developer, best to take a pass.
mobile.twitter.com is one that comes to mind - it uses push notifications, lets you add to your home screen and caches at least some stuff offline, though I don't know how much.
All I meant was, if someone asks "What's a desktop app?" or "What's an iOS app?" or "What's a website?" you can rattle off 100 examples without breaking a sweat.
"What's happiness?" on the other hand is subjective. You could describe things that make you happy, but it wouldn't make sense to point to a banana and say "That's happiness." And if you ask "Am I happy?" the answer probably isn't boolean.
"What's a PWA?" seems to fall into the latter category. If so, then we're treading into philosophy territory, which has claimed countless victims over millennia. You can spend a lifetime trying to define love, but at the end of it, you probably won't produce work that can be built on and extended, the way scientific papers can.
It's notoriously difficult to pin down philosophical concepts into discrete buckets of meaning. We have to operate at the resolution of words. They break if you push them too far.
I think it's important to distinguish these two domains. If we can't effortlessly point to dozens of examples of PWAs, it might be better to reject the notion that PWAs can be defined at all.
Another fun thing about mobile.twitter.com: it is built using react-native-web, so it uses <View /> and <Text /> instead of <div /> and <span />. In theory it could share code with a React Native app.
That would meet the true definition of a PWA in my mind. Ideally, a PWA could utilize everything the platform has to offer by running as a native app, but can also run in the browser for an install-free experience.
This has the potential to be an interesting analogy, but I think you need to do a little work in defining "progressive" in the context of music, or else you're just pushing the ambiguity back a step.
"Google plays a central role in this confusion because they are the organization most strongly attempting to blur the lines between the open web and their platform. Google blurs the line between this is a tool to interact with Google products and this is a direction or philosophy for web development. It can be hard to follow."
Well, between PWA and AMP, and Google's recent hard pushes to both developers and corporate America to adopt them, I can see where that confusion would come in.
In the last 6-8 months, I've been watching and fielding inquiries from clients whom Google's approached on AMP, seen Google holding and inviting corporate dev teams (and marketers) to PWA/AMP hackathons, etc. It's really a full-court press these days, and line where the web ends and Google's ecosystem begins is starting to become lost on plenty of people.
Can anyone explain to me what a "downasaur" is? I've not used Android, so I don't know this term.
Also, I'm not sure progressive anything on the web is a better experience for users. I have a reasonably fast connection everywhere I use the web and I find it a much worse experience when I load a website and see a really low-res version of images that suddenly changes to high res. Likewise, seeing all the text laid out in one font only to have it suddenly jump seconds later when it's done "progressively" downloading the font that's barely different from the standard one.
It seems like what would be more helpful is a way to understand the speed of the connection and choose what to send based on that, rather than assuming everyone has a bad connection. Or make it so your web site doesn't need a bunch of cruft like fonts that the user doesn't care about and just loads quickly regardless of connection speed.
I'm guessing it refers to the fact that on Android Chrome, when there is a error connecting to a site, the error screen has a little pixel art dinosaur on it, (which also has a little game included as an easter egg).
Used to work at a PWA shop (yeah they exist) selling PWA at enterprise level and this is how I explain it to people:
SPA + Push Notificaton + Add to Home Screen Launches SPA in Full Screen = PWA
There's nothing proprietary or unique about PWA, it's just another way that Google is telling developers to "organize" their effort around to easily allow people to install SPA.
To the average user, at least on high end phones, it really is jank free (YMMV)....but if you don't have LTE and on 3g, it will be slow regardless where your user will be staring at the loading screen for many seconds.
The progressive philosophy is to display a base level SPA written in some Javascript framework and enhance the experience depending if Service Worker is supported or not (you will need SW for Add-To-Home & Push Notifications).
I agree with the article that Google's desire to push their platform with things like AMP are increasingly confusing. The big strategic hurdle from a competitive landscape is as Amazon is gobbling up e-commerce (I think 1/3 US purchase online is Amazon don't quote me) and they want to promote struggling retailers and e-commerce businesses that buys their ads by making it faster and more like an app that runs in the browser so it's more discoverable.
The whole PWA language seems to be designed around architects and higher decision makers in e-commerce companies who ultimately decide what their farm of developers will get to play with and honestly I don't blame the confusion from folks on the receiving end of PWA marketing message, it's not at all aimed at answering concerns from engineering or finance (CAPEX AND OPEX for what?)
Currently, Google's stance is that the whole web should be either AMP or PWA or PWAMP (https://twitter.com/hashtag/pwamp?lang=en) and it's not clear why the investment should be made and today.
Apparently, the vague messaging from Chrome team is also felt around Google and the general feedback is that it's not seen as a "painkiller" but PWA is more of a "vitamin" from the perspective of retailer executives--sure you made it more engaging and faster to checkout but it doesn't solve our deeper demand issues that is further plagued by highly leveraged brick & mortar expansion decisions 10 years ago which we are now writing off, as we've learned the other thing the internet is for isn't just porn but mindless purchases made on Amazon who convinced the world its okay to pay extra for peace of mind and consistent delivery times.
I understand wikipedia isn't an absolute source, it's a summary of opinions and research. And what follows is my own opinion, though I'm linking to wikipedia for background and context.
Here's why I like this - "progressive" isn't just a nice, modern sounding word, the way "rad" or "radical" doesn't actually mean "nifty" or "cool", even if it came to be used that way in slang. Progressive has a very specific meaning, which is that it was built through progressive enhancement.
Progressive enhancement, to me[1], is a very different principle from the app that is built as a javascript heavy front end, even if that technology gracefully degrades to plain html ("graceful degradation"). Progressive enhancement is just one strategy for achieving graceful degradation (which might not be the primary motivation, it can be a by-product). You work from content, start with the most basic presentation, and add technologies progressively, CSS, JavaScript, and so forth.
I think "progressive" is one of those great sounding words that has come to mean "an excellent and forward looking web experience". This is what happens when you use a great sounding word to describe a more narrow principle or technique (re, RIP, "Agile"). In this case, it was a reasonable use of the word - progressive can mean "in stages" rather than "forward thinking", but there is an ambiguity here, and I think this recent post is a result of that ambiguity.
[1] I say "to me" here not because this is necessarily my own personal opinion, but because I'm not 100% this is the intended meaning. I may follow those reference links in the wikipedia article and see what was meant. I think this is the case (built in stages, progressively), but I have to qualify it here because I'm not sure.
38 comments
[ 2.4 ms ] story [ 85.1 ms ] threadOr am I confusing terminology?
PWA is pretty much all though JS APIs, primarily the Service Worker API.
Two different concepts.
What does "consider" mean here?
And I'm pretty sure SPA is also not a criteria for PWAs, it's just a suggestion.
And also, the install banner is not really yours, it's the browser's functionality.
Per Google:
> Chrome uses a set of criteria and visit frequency heuristics to determine when to show the banner.
[0]: https://workboxjs.org
Fair enough, you could certainly use Service Worker API for an app with multiple pages. What I was trying to capture with the term SPA is more "web app", although I suppose you could even use Service Worker API with a simple static site.
I have a SPA and have 'converted' it into a PWA. My motivation for that largely has been to better control the way assets are cached on the client, I can now control better with the service worker, but there is one really nice benefit:
With the PWA, android devices (hopefully iPhone soon too) can 'install' the PWA to the device without going through Google Play Store (in fact, you can have the PWA install the android app available on Play Store instead, if you prefer). This makes the web-page appear to the user as an app, with a nice icon, and snappy performance relative to opening a link in chrome (even though it is a chrome instance running the 'installed PWA')
However, when you're talking to a product manager or some other higher-up that doesn't have the same level of technical insight, this bundle of technologies becomes very time-consuming to explain. That's when you break out "Progressive Web App" - a web site that progressively becomes more like an app the more people use it.
I like how you've given the best definition in this thread, and IMHO shown that it's a concept that goes beyond this or that API, right after giving us the its-marketing-for-nontechnical-idiots spiel.
And I wouldn't say the non-technical folks are idiots! They know a lot of stuff I don't, you just need to nail the overlap in what we both know. And given how difficult it is to explain the Service Worker API to even a skilled developer, best to take a pass.
"What's happiness?" on the other hand is subjective. You could describe things that make you happy, but it wouldn't make sense to point to a banana and say "That's happiness." And if you ask "Am I happy?" the answer probably isn't boolean.
"What's a PWA?" seems to fall into the latter category. If so, then we're treading into philosophy territory, which has claimed countless victims over millennia. You can spend a lifetime trying to define love, but at the end of it, you probably won't produce work that can be built on and extended, the way scientific papers can.
It's notoriously difficult to pin down philosophical concepts into discrete buckets of meaning. We have to operate at the resolution of words. They break if you push them too far.
I think it's important to distinguish these two domains. If we can't effortlessly point to dozens of examples of PWAs, it might be better to reject the notion that PWAs can be defined at all.
hmm..
That would meet the true definition of a PWA in my mind. Ideally, a PWA could utilize everything the platform has to offer by running as a native app, but can also run in the browser for an install-free experience.
https://developers.google.com/web/fundamentals/codelabs/offl...
Well, between PWA and AMP, and Google's recent hard pushes to both developers and corporate America to adopt them, I can see where that confusion would come in.
In the last 6-8 months, I've been watching and fielding inquiries from clients whom Google's approached on AMP, seen Google holding and inviting corporate dev teams (and marketers) to PWA/AMP hackathons, etc. It's really a full-court press these days, and line where the web ends and Google's ecosystem begins is starting to become lost on plenty of people.
probably drinks obnoxiously obscure 'craft' beers and enjoys farm-to-table heirloom tomatoes too.
Also, I'm not sure progressive anything on the web is a better experience for users. I have a reasonably fast connection everywhere I use the web and I find it a much worse experience when I load a website and see a really low-res version of images that suddenly changes to high res. Likewise, seeing all the text laid out in one font only to have it suddenly jump seconds later when it's done "progressively" downloading the font that's barely different from the standard one.
It seems like what would be more helpful is a way to understand the speed of the connection and choose what to send based on that, rather than assuming everyone has a bad connection. Or make it so your web site doesn't need a bunch of cruft like fonts that the user doesn't care about and just loads quickly regardless of connection speed.
https://i.ytimg.com/vi/XhkHbI_l-0M/maxresdefault.jpg
To the average user, at least on high end phones, it really is jank free (YMMV)....but if you don't have LTE and on 3g, it will be slow regardless where your user will be staring at the loading screen for many seconds.
The progressive philosophy is to display a base level SPA written in some Javascript framework and enhance the experience depending if Service Worker is supported or not (you will need SW for Add-To-Home & Push Notifications).
I agree with the article that Google's desire to push their platform with things like AMP are increasingly confusing. The big strategic hurdle from a competitive landscape is as Amazon is gobbling up e-commerce (I think 1/3 US purchase online is Amazon don't quote me) and they want to promote struggling retailers and e-commerce businesses that buys their ads by making it faster and more like an app that runs in the browser so it's more discoverable.
The whole PWA language seems to be designed around architects and higher decision makers in e-commerce companies who ultimately decide what their farm of developers will get to play with and honestly I don't blame the confusion from folks on the receiving end of PWA marketing message, it's not at all aimed at answering concerns from engineering or finance (CAPEX AND OPEX for what?)
Currently, Google's stance is that the whole web should be either AMP or PWA or PWAMP (https://twitter.com/hashtag/pwamp?lang=en) and it's not clear why the investment should be made and today.
Apparently, the vague messaging from Chrome team is also felt around Google and the general feedback is that it's not seen as a "painkiller" but PWA is more of a "vitamin" from the perspective of retailer executives--sure you made it more engaging and faster to checkout but it doesn't solve our deeper demand issues that is further plagued by highly leveraged brick & mortar expansion decisions 10 years ago which we are now writing off, as we've learned the other thing the internet is for isn't just porn but mindless purchases made on Amazon who convinced the world its okay to pay extra for peace of mind and consistent delivery times.
https://en.wikipedia.org/wiki/Progressive_web_app
I would draw attention to this particular line:
"Progressive - Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet."
https://en.wikipedia.org/wiki/Progressive_enhancement
Here's why I like this - "progressive" isn't just a nice, modern sounding word, the way "rad" or "radical" doesn't actually mean "nifty" or "cool", even if it came to be used that way in slang. Progressive has a very specific meaning, which is that it was built through progressive enhancement.
Progressive enhancement, to me[1], is a very different principle from the app that is built as a javascript heavy front end, even if that technology gracefully degrades to plain html ("graceful degradation"). Progressive enhancement is just one strategy for achieving graceful degradation (which might not be the primary motivation, it can be a by-product). You work from content, start with the most basic presentation, and add technologies progressively, CSS, JavaScript, and so forth.
I think "progressive" is one of those great sounding words that has come to mean "an excellent and forward looking web experience". This is what happens when you use a great sounding word to describe a more narrow principle or technique (re, RIP, "Agile"). In this case, it was a reasonable use of the word - progressive can mean "in stages" rather than "forward thinking", but there is an ambiguity here, and I think this recent post is a result of that ambiguity.
[1] I say "to me" here not because this is necessarily my own personal opinion, but because I'm not 100% this is the intended meaning. I may follow those reference links in the wikipedia article and see what was meant. I think this is the case (built in stages, progressively), but I have to qualify it here because I'm not sure.