Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add 'What is a PWA' guide #26569

Merged
merged 22 commits into from
May 9, 2023
Merged
Show file tree
Hide file tree
Changes from 16 commits
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
e03308c
Add 'What is a PWA' guide
wbamberg May 3, 2023
543df05
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 4, 2023
1f2729a
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 4, 2023
44e593d
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 4, 2023
f29e56e
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 4, 2023
9a3e1fb
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 4, 2023
1fbfd44
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 4, 2023
11c6d1d
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 4, 2023
3c90851
Fix links
wbamberg May 5, 2023
273e79c
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 5, 2023
3c9521b
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 5, 2023
791a44c
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 5, 2023
dcf8c15
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 5, 2023
03dc0ac
Clarify the relationshi between PWAs and the browser
wbamberg May 5, 2023
70dca9c
Compress SVG
wbamberg May 5, 2023
e57351a
Remove SVG footer message
wbamberg May 5, 2023
aab0806
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 9, 2023
91eb79d
Update files/en-us/web/progressive_web_apps/guides/what_is_a_progress…
wbamberg May 9, 2023
455d731
Apply suggestions from code review
wbamberg May 9, 2023
eda2b4e
rm obvious
wbamberg May 9, 2023
d5a923b
typo fix
wbamberg May 9, 2023
d77ee1a
rm unwritten glosssary entry
wbamberg May 9, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
---
title: What is a progressive web app?
slug: Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app
---

{{PWASidebar}}

A progressive web app (PWA) is an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app.

## Platform-specific apps

_Platform-specific apps_ are developed for a specific operating system (OS) and/or class of device, like an iOS or Android device, generally using an {{Glossary("SDK")}} provided by the platform vendor. They are usually distributed using the vendor's app store, where the user can find and install them, and they subsequently seem to the user like a permanent extra feature of their device, expanding its capabilities in some way.

The benefits of platform-specific apps include:

- **Easy for users to access**: They get their own icon on the device, making it easy for users to find and open them.
- **Offline and background operation**: They are able to operate when the user is not interacting with them and when the device is offline. This, for example, enables a chat app to receive messages when it is not open, and display a notification to the user. It also enables a news app to update in the background so it can show fresh content even if the device is offline.
- **Dedicated UI**: They get to implement their own distinctive, immersive UI.
wbamberg marked this conversation as resolved.
Show resolved Hide resolved
- **OS integration**: They can be integrated into the host OS: for example, a messaging app can register as a share target, enabling users to select an image in the photo app and send it using the messaging app. They can also access device features such as the camera, GPS or accelerometer.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **OS integration**: They can be integrated into the host OS: for example, a messaging app can register as a share target, enabling users to select an image in the photo app and send it using the messaging app. They can also access device features such as the camera, GPS or accelerometer.
- **OS integration**: They can be integrated into the host OS: for example, a messaging app can register as a share target, enabling users to select an image in the photo app and send it using the messaging app. They can also access device features such as the camera, GPS, and accelerometer.

- **App store integration**: They are distributed using the app store, giving users a single place to find them and a consistent way to decide whether they want to install them.

## Traditional websites

Traditionally, websites are less like "something the user has" and more like "somewhere the user visits". Typically, a website: does not have a presence on the user's device when the user is not accessing it, can only be accessed by the user opening the browser and navigating to the site, and is highly dependent on network connectivity.
estelle marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Traditionally, websites are less like "something the user has" and more like "somewhere the user visits". Typically, a website: does not have a presence on the user's device when the user is not accessing it, can only be accessed by the user opening the browser and navigating to the site, and is highly dependent on network connectivity.
Traditionally, websites are less like "something the user has" and more like "somewhere the user visits". Typically, a website: does not have a presence on the user's device when the user is not accessing it, and can only be accessed by visiting the site online, which requires network connectivity.


However, websites have some benefits over platform-specific apps, including:

- **Single codebase**: Because the web is inherently cross-platform, a website can run on different operating systems and device classes from a single codebase.
- **Distribution via the web**: The web is a great distribution platform. Websites are indexed by search engines, and can be shared and accessed just using URLs. A website can be distributed with no need to sign up to any vendor's app store.

## Progressive web apps

Progressive web apps combine the best features of traditional websites and platform-specific apps.

PWAs have the benefits of websites, including:

- PWAs are developed using standard web platform technologies, so they can run on multiple operating systems and device classes from a single codebase.
- PWAs can be accessed directly from the web.

PWAs also have many of the benefits of platform-specific apps, including:

- [**PWAs can be installed on the device**](/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable). This means:

- The PWA can be installed from platform's app store or installed directly from the web.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- The PWA can be installed from platform's app store or installed directly from the web.
- The PWA can be installed from platform's app store or directly [from the web](/en-US/docs/Web/Progressive_web_apps/Installing).

might be too basic for other pages, but this is a very intro article so we likely want to let them know how to install a PWA

- The PWA can be installed like a platform-specific app, and can customize the install process.
- Once installed, the PWA gets an app icon on the device, alongside platform-specific apps.
- Once installed, the PWA can be launched as a standalone app, rather than a website in a browser.

- [**PWAs can operate in the background and offline**](/en-US/docs/Web/Progressive_web_apps/Guides/Offline_and_background_operation): a typical website is only active while the page is loaded in the browser. A PWA can:

- Work while the device does not have network connectivity.
- Update content in the background.
- Respond to push messages from the server.
wbamberg marked this conversation as resolved.
Show resolved Hide resolved
- Display notifications using the OS notificiations system.
wbamberg marked this conversation as resolved.
Show resolved Hide resolved

- PWAs can [use the whole screen](/en-US/docs/Web/Progressive_web_apps/How_to/Create_a_standalone_app), rather than running in the browser UI.
- PWAs can be integrated into the device, registering as share targets and sources, and accessing device features.
- PWAs can be distributed in app stores, as well as openly via the web.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be good to think of total beginners here and also explain how PWAs actually run. This section clearly explains the benefits of both worlds, but I think the missing piece is understanding that a PWA, even if it looks like a standalone app, still runs in the browser. It's the browser that installs it in the OS, and it's the browser that runs it eventually, even if it may not look like it to the end user.

I think this is important because we very often talk about the browser when talking about PWAs, without really saying why. And as a beginner, or someone coming from a native app background, that might feel weird since we focus so much on building "real" apps that are totally standalone. They might ask themselves: But why do they keep referring to the browser, I only see my app?

In fact, just below, on line 64, we say that the manifest is useful for the browser to install the PWA. So explaining the relationship between the browser and a PWA before that would help clarify this line.

### PWAs and the browser
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for adding this section. This is very helpful.


When you visit a website in the browser, it's obvious that the website is "running in the browser". The browser UI provides a visible frame around the website including UI features like back/forward buttons and a title for the page, and the Web APIs your website calls are implemented by the browser engine. So the browser provides a kind of virtual machine for executing the website's code.
wbamberg marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally remove "it's obvious" here. I know it's not what you meant, but it's the sort of phrase I associate with "basic", or "simple" which I tend to stay away from to avoid making assumptions about the reader's level of expertise/understanding of a concept.

Maybe something like:

"When you visit a website in the browser, that website is visible within the UI of the browser, which displays a frame around it with features like back/forward buttons and a title for the page. The source code of the website, and the Web APIs it uses all run in the browser engine."

I would also get rid of "The browser provides a kind of virtual machine for executing the website's code" which I don't think adds much value on top of what's already been said.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point about "obvious". But I like the idea that you can see it's "running in the browser". Would you be OK with something like:

When you visit a website in the browser, it's visually apparent that the website is "running in the browser".

?


PWAs typically look like platform-specific apps, so they usually don't have the browser UI around them, but they are, as a matter of technology, still websites. This means they need a browser engine, like Chrome or Firefox, to manage and run them. With a platform-specific app, it's the platform OS that manages the app, and provides an environment in which it runs. With a PWA, it's a browser engine that performs this background role, just like it does for normal websites.
wbamberg marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion to slightly rephrase "This means they need a browser engine, like Chrome or Firefox, to manage and run them"

"This means they need a browser engine, like the ones in Chrome, Firefox, or Safari, to manage and run them."

Just to make the distinction between browser, browser UI, and browser engine even clearer.


![Diagram comparing the runtime environment for traditional websites, PWAs, and platform-specific apps](pwa-environment.svg)

In our documentation for PWAs, we sometimes refer to the browser playing this background role. We might say, for example, "the browser starts a PWA's service worker when a push notification is received". Here, the browser's activity is entirely in the background. From the PWA's point of view, it might as well be the operating system which started it, and for some systems, such as Chromebooks, there may not even be a distinction between "the browser" and "the operating system".
wbamberg marked this conversation as resolved.
Show resolved Hide resolved

### Technical features of PWAs

The fundamental technical features of a PWA are:
wbamberg marked this conversation as resolved.
Show resolved Hide resolved

- It has a [web app manifest](/en-US/docs/Web/Manifest) file, which, at a minimum, provides information that the browser needs in order to install the PWA, such as the app name and icon.
- It has a [service worker](/en-US/docs/Web/API/Service_Worker_API), which, at a minimum, provides a basic offline experience.
wbamberg marked this conversation as resolved.
Show resolved Hide resolved

#### Web app manifest

A PWA must have a web app manifest, and the [manifest must include enough information for the browser to install the PWA](/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable#the_web_app_manifest).

The manifest can define many other aspects of the PWA's appearance, such as [theme color](/en-US/docs/Web/Manifest/theme_color) and [background color](/en-US/docs/Web/Manifest/background_color), and its behavior, including its ability to [act as a share target](/en-US/docs/Web/Manifest/share_target) for data from other apps or to [handle particular file types](/en-US/docs/Web/Manifest/file_handlers).

#### Service worker

A PWA must have a service worker, and the service worker must implement at least a minimal offline experience.

Service workers encourage an architecture in which the app's pages - that is, the traditional part of a website - implement the user interface, and the service worker implements a backend which can support [offline and background operation](/en-US/docs/Web/Progressive_web_apps/Guides/Offline_and_background_operation), making the PWA behave more like an app than a website. This is because service workers can be started by the browser in the background when they are needed (for example, to handle a push notification).

### Progressive enhancement

While {{Glossary("Progressive Enhancement", "progressive enhancement")}} is a desirable attribute for most websites, it is especially important for PWAs, which expect to run on a wide range of devices and often use advanced Web APIs which may not be supported by all browsers.

One basic component of progressive enhancement is that, if the user visits your PWA on the web by entering its URL in a browser, the user can interact with the app like a normal website. But if the browser can install it, the user will be prompted to install it and the app will appear as a new feature on their device.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
One basic component of progressive enhancement is that, if the user visits your PWA on the web by entering its URL in a browser, the user can interact with the app like a normal website. But if the browser can install it, the user will be prompted to install it and the app will appear as a new feature on their device.
One basic component of progressive enhancement is that the application works for all users. When the user visits your PWA on the web by navigating to it, the user should be able to interact with the app as a fully functioning website. If the browser can install it, the progressive enhancement includes the prompt to install the app.


PWAs should perform feature detection for advanced APIs and provide acceptable fallback experiences.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
PWAs should perform feature detection for advanced APIs and provide acceptable fallback experiences.
The default experience is a fully functioning website, with the PWAs performing feature detection for the advanced APIs that progressively enhance the experience, including the ability to install the app as a PWA.

Or we can change the heading to "Progressive enhancement and graceful degradation."


For example, the [Background Sync API](/en-US/docs/Web/API/Background_Synchronization_API) enables a PWA to ask a service worker to make a network request as soon as the device has connectivity. A classic use case for this is messaging. Suppose the user composes a message, but when the user tries to send the message, the device is offline. The Background Sync API enables the device to send the message in the background once the device is connected. On a device that does not support Background Sync, the app should let the user know the message could not be sent, giving them the chance to try again later.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For example, the [Background Sync API](/en-US/docs/Web/API/Background_Synchronization_API) enables a PWA to ask a service worker to make a network request as soon as the device has connectivity. A classic use case for this is messaging. Suppose the user composes a message, but when the user tries to send the message, the device is offline. The Background Sync API enables the device to send the message in the background once the device is connected. On a device that does not support Background Sync, the app should let the user know the message could not be sent, giving them the chance to try again later.
For example, the [Background Sync API](/en-US/docs/Web/API/Background_Synchronization_API) enables a PWA to ask a service worker to make a network request as soon as the device has connectivity. A classic use case for this is messaging. Suppose the user composes a message, but the device is offline when the user tries to send the message. The Background Sync API enables the device to send the message in the background once the device is connected. On a device that does not support Background Sync, the app should gracefully degrade the user experience, letting the user know the message could not be sent and giving them the chance to try again later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great diagram. This helps a lot.

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.