PWA is just

The concept of Progressive Web Applications (PWA) has been around for a long time, since spring 2018, applications of this class are supported by all major browsers, but the prevalence of PWA technologies, despite their obvious advantages, is still very low.



Google experts (including on Habré) write very informatively and competently about PWA, but their recommendations are more useful to those who are already familiar with the subject. This article is intended to show that Progressive Web Apps is not difficult, and the developers of any sites can and should use these technologies right now.

PWA philosophy

For a start it is worth noting that there is no exact definition of the PWA application. It’s not clear whether this site is PWA or not. This is a long scale on which the homepage of Petr's sophomore can be placed, which added a web app manifesto that creates a site icon on the mobile home screen; and outwardly indistinguishable from the usual news site, only users of which can say that it is surprisingly fast and convenient, and all because somewhere inside it is the hot heart of a service worker (beating).

')

Relativity PWA is inherent in the title itself - “progressive”. Progressive compared to what and to what extent? But this relativity is, in fact, very good, because it is possible to study PWA technologies and apply them in your current projects gradually, without global remodeling and refactoring.



On the other hand, PWA has an idea, and the idea is quite clear and powerful. And how slowly it unfolds may well indicate the magnitude of the consequences.

PWA architecture

PWA is a web application created using certain technologies to achieve specified targets.







Targets are interpreted as follows:



Reliability - the application is downloaded and displayed immediately, regardless of the status and quality of the network connection.

Fast (Fast) - the interchange of data across the network is fast, the UI is smooth and responsive.

Attractiveness (Engaging) - makes the user experience with the application comfortable and enjoyable, encouraging him to want to experience it again, and again, and again ...



From the point of view of Google, this is what separates web sites from native apps by their appearance and feelings (look and feel).



In other words, the developer is offered tools (Service Worker, Push Notifications, etc.) and specifies the goals (the site / application must be fast to download, work on a weak connection, not “lag”, work offline if necessary). How far along this path the developer will depend only on him.

PWA and native applications

The fact that PWA looks like native applications is, rather, a cosmetic solution (although it is important for the user from a psychological point of view). But the fact that they are similar internally (all main application resources can be stored on the client, only changing content will be transmitted over the network) is a great achievement.



You can even call it a hidden revolution. In fact, the browser is used as a kind of virtual machine that stores and runs the PWA application. Just like Android is a virtual machine for Android applications, so the browser becomes a virtual machine for PWA. As a native application accesses its resources through the file system, PWA also accesses its resources — albeit via HTTP, but stored locally.



And for once, it all works equally on all major browsers and on all major platforms.





Of course, there are differences between PWA and native applications - basically, access rights to system resources, but work in this direction goes even to the field of pure HTML5, and for PWA additional privileges will not be a problem.

Technology

A brief look at the main drivers of PWA.

Service Worker

The heart of PWA is the Service Worker. This is the proxy layer between the front end and the back end located in the browser. All browser requests go through it. This division into two independent layers made it possible to make the transition to a regular web site to PWA as easy as possible.



From the repositories, the Service Worker has access to Cache Storage for web resources, and IndexDB for data. But, most importantly, complete freedom to implement business logic.



You can, for example, accept a request from the browser, check the network status, take data from the storage, perform operations with them and return some result back to the browser - which will think that the answer came from the server. Or will not be - as the developer wants, so will he. Two browser layers (client frontend and Service Worker) allow writing full-fledged applications.



At the same time, for most sites, Service Worker's caching functionality will be enough to turn into PWA.



PWA does not depend on any frameworks, it is pure javascript, although even Google experts at Habré for some reason advise using library code generators. Service Worker is perfectly written by hands, and it is necessary to understand and control the logic of your application.



From a programmer's point of view, the Service Worker is a javascript file that is included in the html code of the page. In it, the developer defines the logic of working with requests coming from the frontend and other functionality.

Https

PWA requires that all site resources be transmitted over the HTTPS protocol. SSL certificate can be obtained for free, some hosters do it for you. But it is critical that the site does not have links to unprotected resources — some browsers simply will not display the site in this case.



The main problem encountered in such cases is pictures. Often, editors or commentators put links to images from the Internet into the material, sometimes they are automatically there (into the material). It is necessary to re-save pictures either to yourself or to a service with access via HTTPS.

Application shell

App shell is just a skeleton of a graphical interface, a template. For example, let's take the middle site with a hider, two columns and so on. Roughly speaking, we will cut out from it the content of the current page and all the dynamic information, the remaining static - the app shell.



The bottom line is that the app shell is stored on the client and is loaded when the application is started, and then dynamic information is loaded into it from the network. And while it loads, the app shell should look beautiful (“loaders” in the field, etc.)



This site architecture - downloading content and other dynamic information through ajax calls - can be thought out and implemented on the site in advance, then the transition to PWA will be quite simple.



App shell is like a native program shell. See your PWA as a native program, and much will become easier.

Web App manifest

JSON file, declaratively defining for the browser the name of the application, the icon, what the PWA (fullscreen, standalone, etc.) and some other parameters will look like. Allows you to "install" PWA as a separate application on the smartphone home screen.

Push notifications

If you browse the Internet with Chrome DevTools, open on the Application tab, you can see how few sites use PWA technology. And 90% of those that use, do it only for the sake of Push Notifications.



So far, this is the most popular and most abused PWA technology - over the past few months, the number of sites that you’re trying to find with the “mouse” button on the “Block” button on the offer to receive the latest news has increased, this feeling has repeatedly, and the very desire to impose your Push is like Spam.



But you can also offer a subscription to the second or third user access to the site, when it is already clear that he is not here by chance.