Getting started with Progressive Web Apps (part 1)

Getting started with Progressive Web Apps (part 1)

An evolution has taken place in browsers. It has happened without fanfare, but silent and gradually by the continual development of new browser technologies, culminating in an umbrella term called Progressive Web Apps. In this article series, you'll learn everything you need to know to create modern, offline-ready apps.

In this series of articles on Progressive Web Apps, we'll explore the following topics:

  • What are Progressive Web Apps
  • Browser support
  • The Progressive Web App life cycle
  • The Web App manifest
  • An introduction to Service Workers
  • Frontend Frameworks and Progressive Web apps
  • Building your first Progressive Web apps

What are Progressive Web Apps?

A Progressive Web App is a website by any other name. It is not a packaged app, or an app written to be downloaded from the various app stores. It is simply an enhanced web app with some native-like capabilities.

The term Progressive Web Apps was coined by Google in 2015, and Google is the main backer of both the term and the technologies used in making a Progressive Web App. However, it is not required that you use any particular framework or toolkit when creating progressive apps. You may code your app in plain JavaScript or build it on top of a React/Redux, Angular or Ember app, to name but a few of the many popular JavaScript frameworks.

You do not have to make any compromises when writing a Progressive Web App compared to making a regular website. A Progressive Web App works in all browsers, and the experience is simply enhanced on browsers that support the technology. One interesting aspect is that the enhancement does not kick in immediately, but gradually after a certain amount of user interaction. The apps earn the user’s trust so to speak before it enables all of the Progressive capabilities. If the user agrees, the app installs itself alongside the user’s native apps, be they on the mobile or the desktop. On mobile devices, users can tap on the icon on their home screen to open the app in full-screen mode. The user will not see the browser’s user interface, only the app’s user interface. On desktops, the user can start the app from their list of programs, or in the operating system’s task switcher.

The apps become progressively better and deliver a better user experience than traditional web apps, so even if your intent is not to make your website app-like, it is worth exploring and building apps with the Application Shell architecture. The Progressive Web App’s ability to cache content is an instant win for your app because it can have dramatic effects on the speed of which the user can start using your app. By caching the application shell, the network requests that your app needs to perform before it is usable is usually reduced to pure content, rather than spending time download the HTML, the CSS, and the entire JavaScript codebase before it can start fetching content.

There're a few differences between a native app that you can find in app stores such as in the Apple App Store, the Windows Store, Google Play store and so on, and in other closed environments such as Chrome Packaged Apps and Firefox Packaged Apps. These are all great environments for apps, but they all share a few drawbacks compared to regular web apps: 

  • They must be downloaded in full before use. On contrast, web apps only need to download the core shell before they can be used.
  • The app store becomes the facilitator for discovery. Searching for an app in an app store is usually hard, and you often have to know the name of the app before you can find it. It is a lot easier to be found on the web. Furthermore, the apps are not linkable in the native app stores.
  • They need to go through a formal verification procedure before an iteration is allowed to be put up.

In short, native apps trade off the fast iteration and linkability of the web for features such as access to native system APIs, install to the home screen, splash screens, push notifications and so on.

For an app to a part of the web, it must adhere to a couple of fundamental principles. First of all, it must be linkable. Second, it must be standards-based and free to implement, without requiring permission or payment to any mediator. Imagine if Google or Bing started demanding payment for listing your app in their search indexes. It could not happen on the web because websites are linkable, and a thousand competitors would pop up with free alternatives.

Progressive Web apps share all these qualities because they are websites at heart. Also, the more the user uses the app; it becomes more useful because it progressively builds a relationship with the user. App data, icons, scripts and so on, is stored on the user`s device for quicker subsequent loads. By the use of a service worker, the app can download and push content to the app, thus making it even more useful. The best part of it is that it is still a website that you can link to and link from, and which doesn`t require the user to download anything from an app store.

According to Google, a Progressive Web app has the following characteristics:

  • Progressive
    It works for every user regardless of browser choice because it has been built with progressive enhancement from the start, and can take advantage of any features available on the user’s device and browser.
  • Responsive
    It fits with the device form factor and screen size including desktop browsers.
  • Connectivity Independent
    It works with low-quality networks and even works offline.
  • App-like
    It gives off the appearance of a native app, with app-like navigations and interactions, and is built on the application shell method.
  • Safe
    A requirement of Progressive Web apps is that they are served via HTTPS to prevent snooping. This is important because all network requests can be intercepted through service workers.
  • Discoverable
    Identifies as applications thanks to W3C manifests, allowing search engines to locate them. This gives them a huge advantage over native apps.
  • Installable
    Allows the user to store apps they find useful on the home screen, with a first-rate home icon.
  • Linkable
    Does not require a complicated installation procedure or an account with an app store. It`s just a URL.
  • Re-engageable
    Has access to the re-engagement UIs of the device it`s running on, for instance, features such as push notifications.
  • Fresh
    Always up-to-date because it can push new content to the app when connected to the Internet.

It has always been important to use SSL, but it used to be quite expensive and difficult to purchase and maintain an SSL certificate for your domain. A very popular service called Let’s Encrypt has made the process easy and free. The service is backed by some powerful corporations, which is quite a boon given that if you want to publish a Progressive Web App, it is required to be served on a domain over HTTPS.

Browser support

At the time of writing, the Progressive Web App technology (chiefly, the support for service workers, but also Promises, Fetch, background sync, posting of messages to and from the worker) are limited to the Chrome and Firefox browser on the desktop, and Opera and Firefox for Android. Microsoft is working on support for the Edge browser, but there will be no support for Internet Explorer.

At this point, it is unknown whether Apple will support service workers. Support is still marked as Under consideration, so if they decide to go ahead, it will still take time for it to be implemented in the browser. For now, Safari users will have to make do with the website version of your progressive web apps. However, there is a reason to be cautiously optimistic that the feature will land within the next few years because the WebKit developers have at least talked about adding support for service workers in their unofficial five-year plan.

Fortunately, given the nature of how we develop Progressive Web Apps, it is possible to develop websites that look and work great on browsers that don’t support service workers, and at the same time works progressively better on browsers that do support service workers.

In the next part of this article series we'll take a look at the manifest and introduce the service worker.


Om bloggeren:
Frontendutvikler med sans for JavaScript. Glad i å snakke om programmering, og har utgitt boken ReactJS Blueprints på Packt forlag.

comments powered by Disqus