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.
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 is a web application created using certain technologies to achieve specified targets.
Targets are decrypted as follows:
Reliability (Reliable) - the application is loaded 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, prompting him to want to experience it again, and again, and again ...
From Google’s point of view, this is what separates the web now by look and feel sites from native applications.
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 the main resources of the application 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.
Google attacks iOS
Есть мобильные приложения, которым нужно быть нативными (необходима производительность, доступ к системным ресурсам и др.), однако есть приложения, которые в своем функционале вполне реализуемы как PWA. Для них теперь:
— Не нужно писать различные версии для Android и iOS (и Windows)
— Не нужно регистрировать в Google Play и App Store и платить за это
— Открыт прямой выход на десктоп
До нынешнего времени рынок мобильных приложений был закрыт для энтузиастов, которые могут написать полезную программу, но не могут/не хотят платить за ее размещение. И не хотят связываться с бюрократией Google и Apple по проверке приложения, после которой монопольные времена Microsoft вспоминаешь с тоской.
Сейчас эти барьеры сломлены. И сломала их Google. Учитывая то, что именно она является флагманом интернет-технологий, подобный заход на территорию iOS, скорей всего, вполне продуман и просчитан. Остается ждать бума PWA.
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.
APK vs PWA
Из личного опыта можно вспомнить, как после перевода одного новостного сайта на работу с Service Worker, было решено отказаться от Андроид приложения, сделанного по функционалу сайта. И не столько потому, что его поддержка занимала человеческие ресурсы, а потому, что PWA версия, как ни удивительно, была быстрее, красивее и удобнее в работе, чем java приложение.
A brief look at the main drivers of PWA.
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 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.
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 - loading 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 completely uncomplicated.
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.
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.
Google pwa checklist
Push notifications must be timely, precise and relevant
Enable push notifications from the site and ensure the use cases they're using the push notifications for are:
Timely — A timely notification is one that appears when users want it and when it matters to them.
Precise — A precise notification is one that has specific information that can be acted on immediately.
Relevant — A relevant message is one about people or subjects that the user cares about.
See our guide on creating great push notifications for advice. If your content is not timely and relevant to this user, consider using email instead.