Book Image

Progressive Web Application Development by Example

By : Chris Love
Book Image

Progressive Web Application Development by Example

By: Chris Love

Overview of this book

Are you a developer that wants to create truly cross-platform user experiences with a minimal footprint, free of store restrictions and features customers want? Then you need to get to grips with Progressive Web Applications (PWAs), a perfect amalgamation of web and mobile applications with a blazing-fast response time. Progressive Web Application Development by Example helps you explore concepts of the PWA development by enabling you to develop three projects, starting with a 2048 game. In this game, you will review parts of a web manifest file and understand how a browser uses properties to define the home screen experience. You will then move on to learning how to develop and use a podcast client and be introduced to service workers. The application will demonstrate how service workers are registered and updated. In addition to this, you will review a caching API so that you have a firm understanding of how to use the cache within a service worker, and you'll discover core caching strategies and how to code them within a service worker. Finally, you will study how to build a tickets application, wherein you’ll apply advanced service worker techniques, such as cache invalidation. Also, you'll learn about tools you can use to validate your applications and scaffold them for quality and consistency. By the end of the book, you will have walked through browser developer tools, node modules, and online tools for creating high-quality PWAs.
Table of Contents (12 chapters)

The service worker thread

Service workers run within their own context or thread outside the UI. Because the service worker thread is separate from the UI, it does not have access to the DOM.

The service worker scope is event driven, meaning the platform (browser or operating system, depending on your point of view) initiates the service worker. When the service worker initiates, it does so with the intent of responding to an event, such as a web page opening, a push notification, or another event.

The process stays alive long enough to service the need. This time is determined by the browser and varies by platform. There is no fixed time defined in the service worker specification.

Running in a separate context from the normal JavaScript offers many advantages to service workers. The first is that a service worker script does not block the UI from rendering. You can use this...