Web app shortfalls include limited access to a device’s features (i.e. camera, GPS and accelerometer), performance issues inflicted by the browser, and UI limitations due to HTML/CSS/JavaScript. Not to mention they have one of the biggest requirements: a reliable network connection. With these limitations in mind, a new approach was introduced: the progressive Web app (PWA).

Progressive Web apps
PWAs seek to produce the same user experience as that of a native app, but rather than downloading an application, a PWA employs your browser. PWAs attempt to tap into the best of both worlds. They intend to leverage the benefits of Web apps, such as their HTML base and cross-platform availability, while still addressing their shortcomings, including their UI and touch, personalization, access in low to no bandwidth situations and deployment to the home screen.

You can think of a PWA as a Web page or set of Web pages, utilized by a person via their device’s browser, originally loaded via a standard Website URL. A PWA Web page set utilizes HTML/HTML5, CSS3, media queries, and JavaScript/jQuery. It also uses a Web Manifest (a JSON-based manifest that describes a Web app), a service worker and an application shell architecture to provide a native app-like experience that is feature-rich, fast loading, responsive, secure, and has the ability to acclimate to each particular user.

Additionally, the application shell framework and the service worker make all of this possible.

Service workers: One of a Web app’s biggest issues in the past was the ability to access information or content both online as well as in a low- or no-bandwidth situation. The requirement for always-available, high-quality bandwidth greatly limited Web apps’ acceptance. Services workers look to solve this limitation by effectively acting as a JavaScript-based proxy between the Web page and the back-end server that is handling the request.

Using the Web manifest, a Web page may register the service worker with the browser. The Web page then begins talking to the service worker, not the Web server. The Web page stops worrying about the Web server in question; it simply makes a request to the service worker, and the service worker provides a response dependent on the PWA developers’ requirements.

Service workers have a state unlike the general Web. They are able to respond to push notifications from the back-end Web server, sync background data, receive updates, maintain cached data, and provide an experience for the front-end PWA so that the app may work even with no bandwidth.

App shell: The app shell provides the key component that allows for fast load times of a general PWA, as well as for the ability for the service worker to do much of its job. The App Shell is used to store the general interface and design (or shell) of the PWA. The app shell itself is primarily the HTML/CSS/JavaScript required to provide the general wrapper of the PWA. It is stored in the browser’s cache and utilized by the service worker to provide an always-available application interface, even while additional content or data is being retrieved from the Web server.

The app shell and the service worker come together to increase both speed and functionality. While the app shell provides a native-like interface in terms of UI and design, the service worker provides the glue that allows the overall PWA to be responsive and quick.