Před více než deseti lety se s Progressive Web Apps spojovala představa, že web přestane být chudším sourozencem nativních aplikací. Webová aplikace získá ikonu na ploše, bude fungovat i bez připojení, zobrazí notifikace a dostane se k dalším schopnostem zařízení. Vývojáři pak nebudou muset jednu službu udržovat ve třech samostatných verzích: pro web, Android a iOS.

Takto přímočará budoucnost nepřišla. Nativní aplikace nezmizely a tam, kde aplikace potřebuje garantovanou možnost pracovat mimo otevřené rozhraní nebo využít hlubokou integraci se zařízením, mají stále jasný důvod existovat. Přístup PWA se mezitím osvědčil jinde: webová aplikace se dál otevírá z běžného odkazu, funguje hned při první návštěvě a lidem, kteří se vracejí, může nabídnout ikonu na ploše.

Právě tady zkratka „PWA“ mate. Neoznačuje jeden hotový režim: instalace, práce bez připojení a systémové funkce jsou odlišné možnosti a jednotlivé platformy je nepodporují stejným způsobem. Při návrhu proto není důležité rozhodnout se pro nálepku PWA. Důležité je vybrat funkce, které skutečně usnadní práci uživatele.

PWA dnes znamená několik různých věcí

Na PWA se snadno dívá optikou několika známých aplikací: editoru obrázků, nástroje pro společnou práci na dokumentech nebo hudební služby, které se v prohlížeči chovají téměř jako desktopový klient. Takové příklady budí dojem, že PWA je jeden hotový typ aplikace. V běžných webech se ale jejich jednotlivé části používají samostatně.

Service worker může v prohlížeči obsloužit cache a síťové požadavky, takže se hodí pro rychlejší opětovné načtení. Manifest nese například jméno aplikace, ikony a způsob otevření v samostatném okně. Web Almanac našel service worker na 18,9 % sledovaných webů a manifest přibližně na devíti procentech; obojí současně mělo jen 3,3 % desktopových a 3,5 % mobilních webů.

Jeden web může využít service worker jen proto, aby se při další návštěvě načetl rychleji. Jinde manifest doplní framework nebo redakční systém. Ani jedna technologie sama o sobě neznamená, že web nabízí promyšlenou aplikaci pro pravidelné používání.

Ještě vzácnější jsou pokročilejší funkce. Mezi weby se service workerem našel Almanac registraci pro push zhruba v sedmi procentech případů a synchronizaci kolem dvou procent. Rychlejší načtení při návratu tak bývá podstatně běžnější než upozornění nebo dokončování úlohy poté, co uživatel stránku zavře.

Otázka „budeme dělat PWA?“ ale sama o sobě moc nepomůže. Je jednodušší se ptát: potřebuje si uživatel aplikaci nainstalovat? Musí se otevřít bez připojení? Má mu po dokončení objednávky přijít upozornění? Ke každé odpovědi patří jiná webová technologie i jiný plán pro zařízení, která ji nemají.

Instalovat dnes umí i obyčejný web

Instalace přestala být výsadou pečlivě postavené PWA. MDN uvádí, že Chrome na desktopu i Androidu, Edge na desktopu a Safari na desktopu dovolují uživateli nainstalovat jako aplikaci i běžný web bez manifestu a bez klasických kritérií instalovatelnosti. Safari od verze 17 nabízí na macOS funkci Add to Dock pro libovolnou webovou aplikaci.

Manifest tím neztrácí smysl. Určuje jméno aplikace, ikony, výchozí adresu i preferovaný režim zobrazení. S display: standalone prohlížeč aplikaci tam, kde tento režim podporuje, otevře ve vlastním okně; jinde může použít jiný podporovaný režim. Aby ale prohlížeč web aktivně nabízel jako instalovatelnou PWA, jsou potřeba manifest a HTTPS. Service worker podmínkou instalace není.

Technické podmínky instalace jsou tím vyřešené. Těžší je dát uživateli důvod, aby si ikonu vůbec přidal. U pracovního dashboardu, schvalování objednávek nebo formuláře, který lidé vyplňují v terénu, to může ušetřit krok několikrát týdně. U jednorázové kalkulačky je další krok mezi odkazem a výsledkem spíš zátěž. Důvodem k instalaci je hlavně frekvence a způsob používání.

Web se šíří odkazem, ne přes obchod s aplikacemi

Web má výhodu, kterou nativní klient nedožene jen lepší implementací. Produkt se dá otevřít ve výsledku vyhledávání, z e-mailu, z QR kódu u zařízení nebo z interního systému. Uživatel nemusí nejdřív určit správný obchod, stáhnout balíček a věřit mu dost na to, aby jej instaloval.

Pro B2B je tento model užitečný hlavně proto, že dodavatel nemusí předem přesvědčovat každého technika, skladníka nebo příležitostného schvalovatele. Nástroj může nasadit přes adresu, ověřit jeho užitek v reálné práci a instalaci nabídnout teprve lidem, kteří se vracejí. Stejný produkt pak zůstává dostupný z notebooku i telefonu, aniž by tým musel stavět samostatné klienty jen kvůli prvnímu kroku.

PWA navíc nemusí být rozsáhlá aplikace, která při přechodu mezi stránkami všechno mění bez nového načtení. MDN připomíná, že tento typ aplikace, označovaný jako SPA, není podmínkou PWA. To se hodí týmům se serverově renderovaným webem: ikona na ploše nebo základní offline vrstva nemusí být důvodem k přepisu navigace a zavedení rozsáhlého klientského kódu.

PWA tedy nejsou hlavně o napodobení nativního vzhledu. Web nemusí před prvním použitím volit mezi otevřeností a aplikací. Může uživateli nabídnout obojí ve chvíli, kdy to odpovídá jeho chování.

Instalace, cache a notifikace řeší různé věci

Instalace, odolnost vůči výpadku připojení a návrat uživatele do aplikace řeší různé vrstvy. Service worker funguje odděleně od stránky a může zachytávat síťové požadavky či pracovat s cache; MDN jej popisuje jako komponentu bez přístupu k DOMu. To dává prostor pro offline rozhraní nebo lokální frontu změn. Neznamená to ale, že každá aplikace s manifestem automaticky funguje bez připojení.

Notifikace jsou další samostatné rozhodnutí. Podpora na iPhonu se výrazně posunula: WebKit v iOS a iPadOS 16.4 přidal Web Push pro webové aplikace přidané na plochu. Oprávnění musí následovat po přímé akci uživatele. Zpráva pak může přijít do centra oznámení nebo na zamknutou obrazovku stejně jako u jiné aplikace.

To se hodí pro produkt, kde upozornění usnadní návrat uživatele. Pokud bez něj služba nemůže plnit hlavní úkol, je nutné ověřit jeho dostupnost na každé cílové platformě ještě před volbou architektury.

Na pozadí web nemá slíbit víc, než dokáže garantovat

Omezení webu se nejvíc projeví ve chvíli, kdy aplikace nemá zůstat otevřená. Tehdy záleží na tom, co se má stát poté, co uživatel aplikaci zavře, přepne se jinam nebo ztratí připojení.

Background Sync dokáže odložit krátký síťový úkol, například odeslání zprávy, dokud se zařízení znovu nepřipojí. MDN jej však označuje jako omezeně dostupnou funkci. Background Fetch, určený pro delší stahování, má také omezenou dostupnost a experimentální status; stejné omezení platí pro periodickou synchronizaci.

Katalog se může při otevření obnovit ze serveru. Aplikace, která musí spolehlivě stáhnout velký balík map, dokončit export videa nebo se v přesný čas spojit s firemním zařízením, potřebuje silnější garanci než podmíněné probuzení service workeru.

Podobná opatrnost platí pro hardware. Web Bluetooth umožňuje komunikaci s Bluetooth Low Energy periferiemi, ale MDN jej vede jako experimentální funkci s omezenou dostupností. Ve firmě s předem vybranými notebooky a prohlížečem může být velmi dobrým řešením. U spotřebitelského produktu pro neznámé telefony a tablety by se na něm nedalo bezpečně stavět.

Kde PWA dává smysl

PWA dává smysl pro aplikace, které si lidé otevírají z odkazu a vracejí se do nich. Nehodí se tam, kde musí spolehlivě dělat něco na pozadí nebo využívat hardware na každém zařízení.

Pro nový projekt stačí tři otázky. Otevře uživatel produkt nejdřív z odkazu? Vrací se k němu tak často, aby samostatné okno nebo ikona ušetřily krok? A potřebuje funkci, kterou musíme garantovat mimo aktivně otevřené rozhraní nebo na libovolném zařízení?

Když první dvě odpovědi znějí ano a třetí ne, PWA je často velmi dobrá volba. Jestli aplikace potřebuje spolehlivě běžet na pozadí nebo pracovat s hardwarem, je rozumnější zvolit nativní nebo hybridní řešení. Před začátkem vývoje je potřeba určit, co musí fungovat a na kterých zařízeních.