The post has been translated automatically. Original language: Russian
We are used to separating websites and applications quite clearly. The website opens via a link in the browser. You need to download the app from the store, install it, and then launch it from the icon on your phone screen.
The PWA blurs this boundary.
A Progressive Web App, or progressive web application, is a web application that the browser and operating system can provide with some of the features of a regular application. It still runs on web technologies and is available by URL, but under certain conditions it can be installed on a device, run in a separate window, and used even with an unstable Internet connection.
At the same time, PWA is not a separate framework or a special programming language. The existing site may well gradually gain PWA capabilities without a complete rewrite of the project.
What does PWA consist of?
An ordinary modern website can already be adaptive, fast, and interactive. By itself, this does not make it a PWA.
One of the important technologies here is service worker. This is JavaScript code that the browser runs separately from the page. It can intercept network requests and decide where to get the desired resource from: request it from the server or, for example, take a previously saved copy from the cache.
That is why the PWA can continue to show part of the interface when the Internet is poor or without a connection at all. Of course, offline does not occur automatically: the developer must determine which data to save and how the application should behave when the server is unavailable.
The second important part is the web app manifest. This is a small file with information about the application: the name, icons, interface colors, and launch options. Thanks to it, an installed web application can look much closer to a regular application on the device than to an open browser tab.
Finally, PWA requires a secure context. In normal operation, this means HTTPS. Service worker gets pretty serious network request management capabilities, so browsers don't provide them to pages loaded over an unsecured connection.
Why install a website at all
At first glance, the idea seems a bit strange. If the site can be opened in a browser anyway, why add it to your device?
The main difference is not in the icon itself.
PWA allows you to make a web product a more permanent part of the user's device. It can be launched from the home screen or from the list of applications, opened without the usual browser interface, and some features can be used even in case of network problems.
For certain products, this significantly changes the user experience. An online store, a delivery service, a personal account, a work tool, or a regularly used information service no longer has to be searched in a browser every time.
At the same time, developers do not necessarily have to create separate applications for each platform. The web remains the basis of the product.
Does this mean that PWA can replace a mobile app?
Sometimes— yes. But there was no universal replacement for native PWA development.
The web platform has gained access to many features that were previously associated almost exclusively with applications. However, the amount of API available still depends on the browser and the operating system. PWA features on Android, iOS, and desktop systems are different.
There is another issue: distribution. The user usually searches for the native app in the App Store or Google Play. PWA naturally spreads through the web: a link, a search result, an advertisement, or an existing website. This is an advantage for some products, but a serious limitation for others.
"Therefore, "the question is usually not "PWA or a real app," but "what capabilities does this product really need?"
If the user mainly needs an interface, server data, local storage, unstable network operation, and fast access from the device, PWA can close a significant part of the task.
If the product is highly dependent on the capabilities of a particular operating system, background operation, device hardware, or specific native APIs, the web's capabilities may not be enough.
Why have they been talking about PWAs for many years, but they haven't supplanted apps?
The idea of an installable web application has been around for a long time. The term Progressive Web Apps appeared back in the mid-2010s, and browsers gradually added the necessary technologies.
But the development was uneven.
The difference between Android and iOS has been particularly noticeable for a long time. Support for PWA features depends not only on web standards, but also on browser and operating system manufacturers' solutions. Therefore, a function that works fine in one environment might be missing or have limitations in another.
The situation is gradually changing, but this leaves an important legacy: a PWA cannot be designed based on the assumption that it will behave exactly the same on each device.
This is the word Progressive in the title.
The base product should remain available as a website. If the browser supports additional features, the user gets more: installation, offline scripts, and other features. If an API is unavailable, the site should not stop working because of this.
PWA is more of an approach than an application type.
This is perhaps the most important thing to understand before becoming more familiar with the technology.
There is no moment when a developer connects one library and the site suddenly turns into a PWA. You can add a manifest, but not do normal work if the network is lost. You can register a service worker, but use it only for a few static files. You can create an installable interface, which after installation is completely dependent on the server anyway.
Therefore, two products called PWA can differ greatly in their capabilities.
It is more useful to consider PWA as a set of web technologies and architectural solutions that allow you to gradually bring the user experience of the site closer to the application where it really makes sense.
And after that, you can sort out the most interesting things.: how does service worker work, what caching strategies exist, what exactly can be saved offline, how the browser solves the installation issue, and where the real boundaries of PWA capabilities are today.
Мы привыкли довольно чётко разделять сайты и приложения. Сайт открывается по ссылке в браузере. Приложение нужно скачать из магазина, установить, а потом запускать с иконки на экране телефона.
PWA размывает эту границу.
Progressive Web App, или прогрессивное веб-приложение, — это веб-приложение, которому браузер и операционная система могут дать часть возможностей обычного приложения. Оно по-прежнему работает на веб-технологиях и доступно по URL, но при определённых условиях его можно установить на устройство, запускать в отдельном окне и использовать даже при нестабильном соединении с интернетом.
При этом PWA — не отдельный фреймворк и не особый язык программирования. Существующий сайт вполне может постепенно получить возможности PWA без полной переписки проекта.
Из чего складывается PWA
Обычный современный сайт уже может быть адаптивным, быстрым и интерактивным. Само по себе это ещё не делает его PWA.
Одна из важных технологий здесь — service worker. Это JavaScript-код, который браузер запускает отдельно от страницы. Он может перехватывать сетевые запросы и решать, откуда получить нужный ресурс: запросить его с сервера или, например, взять ранее сохранённую копию из кэша.
Именно поэтому PWA может продолжать показывать часть интерфейса при плохом интернете или вообще без соединения. Разумеется, офлайн не возникает автоматически: разработчик должен определить, какие данные сохранять и как приложение должно вести себя, когда сервер недоступен.
Вторая важная часть — web app manifest. Это небольшой файл с информацией о приложении: названием, иконками, цветами интерфейса и параметрами запуска. Благодаря ему установленное веб-приложение может выглядеть на устройстве гораздо ближе к обычному приложению, чем к открытой вкладке браузера.
Наконец, PWA требует безопасного контекста. В обычной эксплуатации это означает HTTPS. Service worker получает довольно серьёзные возможности управления сетевыми запросами, поэтому браузеры не предоставляют их страницам, загруженным по незащищённому соединению.
Зачем вообще устанавливать сайт
На первый взгляд идея кажется немного странной. Если сайт и так можно открыть в браузере, зачем добавлять его на устройство?
Главное отличие не в самой иконке.
PWA позволяет сделать веб-продукт более постоянной частью устройства пользователя. Его можно запускать с домашнего экрана или из списка приложений, открывать без привычного интерфейса браузера, а некоторые возможности использовать даже при проблемах с сетью.
Для определённых продуктов это существенно меняет пользовательский опыт. Интернет-магазин, сервис доставки, личный кабинет, рабочий инструмент или регулярно используемый информационный сервис уже не обязательно каждый раз искать в браузере.
При этом разработчикам не приходится обязательно создавать отдельные приложения для каждой платформы. Основой продукта остаётся веб.
Значит ли это, что PWA может заменить мобильное приложение
Иногда — да. Но универсальной заменой нативной разработке PWA не стало.
Веб-платформа получила доступ ко многим возможностям, которые раньше ассоциировались почти исключительно с приложениями. Однако объём доступных API по-прежнему зависит от браузера и операционной системы. Возможности PWA на Android, iOS и настольных системах отличаются.
Есть и другой вопрос: распространение. Нативное приложение пользователь обычно ищет в App Store или Google Play. PWA естественным образом распространяется через веб: ссылку, поисковую выдачу, рекламу или существующий сайт. Для одних продуктов это преимущество, для других — серьёзное ограничение.
Поэтому вопрос обычно стоит не как «PWA или настоящее приложение», а как «какие возможности действительно нужны этому продукту».
Если пользователю в основном нужен интерфейс, данные с сервера, локальное хранение, работа при нестабильной сети и быстрый доступ с устройства, PWA может закрыть значительную часть задачи.
Если продукт сильно зависит от возможностей конкретной операционной системы, фоновой работы, оборудования устройства или специфических нативных API, возможностей веба может оказаться недостаточно.
Почему о PWA говорят уже много лет, но они не вытеснили приложения
Идея устанавливаемого веб-приложения существует давно. Термин Progressive Web Apps появился ещё в середине 2010-х, а браузеры постепенно добавляли необходимые технологии.
Но развитие происходило неравномерно.
Особенно заметной долгое время была разница между Android и iOS. Поддержка возможностей PWA зависит не только от веб-стандартов, но и от решений производителей браузеров и операционных систем. Поэтому функция, прекрасно работающая в одном окружении, могла отсутствовать или иметь ограничения в другом.
Ситуация постепенно меняется, но это оставляет важное наследие: PWA нельзя проектировать исходя из предположения, что на каждом устройстве оно будет вести себя совершенно одинаково.
В этом и заключается слово Progressive в названии.
Базовый продукт должен оставаться доступным как веб-сайт. Если браузер поддерживает дополнительные возможности, пользователь получает больше: установку, офлайн-сценарии и другие функции. Если какой-то API недоступен, сайт не должен из-за этого переставать работать.
PWA — это скорее подход, чем тип приложения
Это, пожалуй, главное, что стоит понимать перед более глубоким знакомством с технологией.
Нет момента, когда разработчик подключает одну библиотеку и сайт внезапно превращается в PWA. Можно добавить manifest, но не сделать нормальную работу при потере сети. Можно зарегистрировать service worker, но использовать его только для нескольких статических файлов. Можно сделать устанавливаемый интерфейс, который после установки всё равно полностью зависит от сервера.
Поэтому два продукта, которые называются PWA, могут очень сильно отличаться по своим возможностям.
Полезнее рассматривать PWA как набор веб-технологий и архитектурных решений, позволяющих постепенно приблизить пользовательский опыт сайта к приложению там, где это действительно имеет смысл.
А уже после этого можно разбирать самое интересное: как работает service worker, какие стратегии кэширования существуют, что именно можно сохранить для офлайна, как браузер решает вопрос установки и где сегодня проходят реальные границы возможностей PWA.
Share
