Some people wonder why Apple/Safari/WebKit folks often refer to “Web Apps”, “Home Screen Web Apps”, “Installed Web Apps” or similar terms, instead of “Progressive Web Apps” or PWAs. There’s a couple of reasons:
1. We like to reflect language that appears in the UI when possible.
3. PWA in reference to a suite of technologies is amorphous and has no clear referent. Some technologies are almost always considered part of the core PWA set: Service Workers, Web Manifest, Notifications API, Push API (and related protocols). But other things may be considered PWA, Fugu, or just normal web technologies, depending on the day of the week. We don’t find such an amorphous grouping to be a useful way to think about web technologies.
We’re not mad at other people using the term and will use it when helpful, but this is why we usually use different terminology depending on context.
Contrast Web Components: this really is a clear and well defined cluster. There’s no debate or fuzziness as to whether specific specs are part of Web Components or not.
@othermaciej @phae, who came up with the name, doesn't disagree https://fberriman.com/2017/06/26/naming-progressive-web-apps/
@othermaciej thanks for putting this into words. I always felt that the term ‘PWA’ is nebulous, since it can mean so many things.
@othermaciej I'm a developer with long past experience with web dev and good knowledge of JavaScript, and I don't know what the hell PWA is ¯\_(ツ)_/¯ because I haven't dealt with these specific APIs… so I don't think it's a stretch to assume that most non-technical users wouldn't either
@mackuba Yeah, it's confusing to users and even to many devs. Some people get mad if we don't use exactly this term, but if that's the cost of clarity, so be it.
@othermaciej good to know that Apple terminology. Sometimes I wonder how terms like that get popular with others. Must be Mac users.
@othermaciej Mystery solved! In Chrome DevRel, we differentiate between PWAs and installed PWAs (e.g. https://developer.chrome.com/articles/url-protocol-handler/). Project Fugu 🐡 is about APIs, more specifically, it’s an effort to close gaps in the web's capabilities, enabling new classes of applications to run on the web (https://developer.chrome.com/capabilities/). In the end, it’s all umbrella terms, not exact definitions; just like what happened with AJAX (later Ajax) or HTML5.
@othermaciej
I see PWA as more of a technology strategy term than a term that describes a particular application or set of APIs. Kind of like "web technologies".
As a tech strategy it is ever evolving and will always be a bit ambiguous.
IMO there needs to be *a* term that means "choosing the installable web-application route with all kinds of app-like APIs", when people consider this vs. Flutter / ReactNative / Swift+Kotlin. I don't really mind if it's PWA or a different term...
It's important because when we talk about e.g. PWA support in a particular browser, we talk about whether the browser supports PWAs *as a technology choice for building apps*, and this includes a set of solutions that evolves over time, based on user and developer needs.
@nomster I recognize the term has value for some people. The creator apparently intended it to be a marketing buzzword (along the lines of “Web 2.0” perhaps). Which seems similar to your notion of a term for a technology strategy. Still, I think our reasons for choosing to rarely use it hold up. We are mostly talking to users and developers, not CTOs or CIOs.
@othermaciej I was recently talking to an indie dev who was considering whether to use Flutter or to go the PWA route, and I found the term helpful. Indie developers are often their own CTOs (and CIOs), and choosing a "tech strategy" can make or break their future.
I wouldn't dismiss conversations with them as being a hype thing. Separating "developer" from "CTO" is missing something - a coherent story around helping devs succeed with a web-based approach to apps (call them what you will).
@othermaciej I do agree though with your point that calling a particular app "A PWA" can be ambiguous.
@nomster Maybe this points to a difference in emphasis. We’re not specifically looking to persuade devs to build apps with web stuff over any other technology or framework. We want to make sure that, if they do choose to build something web-based, they have the tools to deliver a great user experience, and it’s not too hard to do so. We’d like the same to be true of UIKit, SwiftUI, Flutter, React Native, Xamarin, etc.
@othermaciej Sounds good!
If the sentiment ("make sure that, if they do choose to build something web-based, they have the tools to deliver a great user experience") is there, the terminology is less important IMO.
@jayphen Seems like a bug to me! We support a related concept of how screen bookmarks (for sites that don’t support running as a standalone web app) but Twitter installs as a real web app.
@othermaciej Maybe! I am using the latest beta. I will try to figure out how to report this.
2. When we intend to refer to installed web apps, the term “PWA” is ambiguous. Sometimes it refers to web apps that _can_ be installed, other times web apps that _have_ been installed. When we’re talking about different capabilities or extra behavior, we generally only mean web apps that have actually been installed, so we try to be more specific.