The other day, Frances Berriman—who coined the term “Progressive Web App”—wrote a bit about how she came up with that name. In it she clearly points out that the name has become a little problematic in dev circles:

I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer. It’s a way for you to keep making things on the open web, even those things that look really “app-y” and your company wants to actually make as a native app, 3 times over. They don’t want you to make websites anymore, but you still can if you’re sneaky, if you tell them it’s what they think they want.

As someone who is at once a practitioner, an educator, and a consultant on web projects, this can be tough to wrestle with. But like DHTML, Ajax, and HTML5 before, when viewed as a catch-all term for an approach to building stuff for the web it really shouldn’t matter that the word “app” is in there. Sure, it could have been “site” or “thang”, but when we—and I’m talking to the practitioners here—hear someone talking about PWAs, we need to take the broad view.

Jeremy Keith made a really solid case for the broad usefulness of PWAs:

Literally any website can be a progressive web app:

• switch over to HTTPS,
• add [a JSON manifest file](https://www.w3.org/TR/appmanifest/) with your [metacrap](https://www.well.com/~doctorow/metacrap.htm), and
• add a service worker.

PWAs don’t require you use a particular JavaScript framework or any JavaScript framework at all. You don’t need to be building a Single Page App either. In fact, it will probably be easier if you’re not.

If you work on a website, there’s a really good chance your site could benefit from the technologies and approaches aggregated under the PWA umbrella:

• Works on any device (a.k.a. progressive enhancement and responsive design)? Check.
• Secure by default? Check.
• Links to any core functionality or content? Check.
• Easily shared and discovered? Check and check.
• Better network resilience and faster page loads? Check and mate.

Depending on what you’re building, your site might even benefit from features like

• push notifications,
• syncing data in the background (when your site’s not open), and
• install-ability.

Every project is different, but there’s a good chance yours should be a PWA or at least have some of the features of one. To quote Christian Heilmann:

Nothing necessary to turn your current web product into a PWA is a waste. All steps are beneficial to the health and quality of your product.

What are you waiting for?