Progresywne portfolio - wprowadzenie do Progressive Web Apps

Progresywne portfolio - wprowadzenie do Progressive Web Apps

Progressive Web Apps to kolejny etap w rozwoju współczesnych stron internetowych i aplikacji webowych. Dzięki najnowszym funkcjonalnościom przeglądarek internetowych możemy przenieść wrażenia do tej pory zarezerwowane tylko dla mobilnych aplikacji natywnych w świat projektów które miały być dostępne jedynie za pośrednictwem przeglądarki internetowej. Czym są PWA i jak dostosować istniejący projekt do tego standardu? O tym wszystkim dzisiaj – zapraszamy!

Progressive Web Apps – kolejny buzzword?

Na początku trochę twardych danych dla rozwiania wątpliwości:

  • sklep internetowy AliExpress zwiększył konwersję celów dla nowych użytkowników o 104% w momencie przejścia na PWA
  • Twitter po wprowadzeniu wersji Lite swojej strony (PWA) zyskał wzrost o 65% jeśli chodzi o liczbę otwieranych stron na każdą sesję użytkownika
  • indyjski startup Housing.com odnotował wzrost o 10% jeśli chodzi o czas trwania sesji na stronie i obniżył o 40% wskaźnik odrzuceń

Nie, nie zajmuję się marketingiem PWA ani nie pracuję dla Google’a. Statystyki które tutaj przytoczyłem pochodzą z raportów firm które dostarczają case study związane z projektami w których standard Progressive Web Apps miał odgrywać kluczową rolę. W jaki sposób technologia ta przyczyniła się do wzrostów jeśli chodzi o twarde biznesowe wskaźniki? Zacznijmy od początku.

PWA opierają się na trzech głównych założeniach:

  • mają być niezawodne – niezależnie od tego, czy korzystasz z sieci światłowodowej, czy jedziesz pociągiem mając nadzieję na brak przerw w dostępie do internetu mobilnego, PWA ma dostarczać content dla użytkownika w sposób niezawodny
  • mają być szybkie – tutaj nacisk kładzie się na maksymalną redukcję czasu oczekiwania na odpowiedź z serwera – jak pokazują badania, aż 53% użytkowników rezygnuje z przeglądania strony jeśli czas oczekiwania przekracza 3 sekundy
  • mają być angażujące – PWA ma dostarczać wrażenia przypominające mobilne aplikacje natywne, z wszystkimi najpopularniejszymi funkcjonalnościami takimi jak powiadomienia push czy dostęp z ekranu twojego smartfona

Kto z nas chciałby robić strony internetowe które są zawodne, wolne i mało angażujące? W teorii nikt, jednak praktyka i twarde dane pokazują, że przed twórcami współczesnych projektów internetowych jeszcze dużo pracy. Funkcjonalności takie jak wsparcie dla wolnych połączeń internetowych, layout dostosowujący się do urządzenia czy dostępność to wciąż ciekawostki traktowane przez wielu jako zło konieczne. Standard PWA ma odwrócić ten trend i przywrócić nadzieję na to, że strona internetowa może konkurować z natywnymi aplikacjami mobilnymi.

Realizacja trzech głównych założeń PWA opiera się na spełnieniu przez daną stronę listy wymagań, takich jak:

  • serwowanie danych za pomocą bezpiecznego protokołu HTTPS (bezpieczeństwo)
  • responsywny, dostosowujący się do urządzenia layout (wrażenia użytkownika)
  • wsparcie dla trybu offline (niezawodność)
  • możliwość dodania aplikacji do ekranu głównego (wrażenia użytkownika)
  • mniej niż 10 sek. do bycia interaktywną na sieci 3G (niezawodność, szybkość)
  • działanie na różnych platformach (uniwersalność)
  • zminimalizowanie poczucia “co się dzieje” w trakcie oczekiwania na załadowanie (wrażenia użytkownika)
  • każdy zasób na stronie dostępny poprzez URL (łatwe udostępnianie treści)

Lista wymagań zawiera jeszcze kilkanaście innych “dobrych praktyk” które mają na celu optymalizację wrażeń z korzystania z danej strony, jednak na dobry początek należy zadbać na zrealizowanie tych podanych wyżej.

Po poznaniu teorii czas na praktykę – zobaczymy teraz ile wysiłku należy włożyć w realizację tych założeń i co właściwie dzięki nim zyskamy.

Jak sprawdzić czy spełniamy założenia PWA

Może się na początku wydawać, że lista kryteriów które musimy spełnić aby uzyskać status PWA jest dość problematyczna i uciążliwa. Na szczęście Google poszło na rękę wszystkim zainteresowanym i jakiś czas temu opublikowało znakomite narzędzie do audytowania stron i aplikacji internetowych, które nakieruje nas na właściwą drogę. Narzędziem tym jest Lighthouse.

Lighthouse to open-source’owe narzędzie pomagające poprawiać jakość projektów webowych które tworzymy. Audyt który otrzymujemy uruchamiając je na naszej stronie dotyczy kwestii wydajności, dostępności, dobrych praktyk i PWA. 

W naszym poradniku zaczynamy od zainstalowania Lighthouse’a jako wtyczki do Chrome, ponieważ jest to chyba najprostszy sposób do rozpoczęcia pracy z jego pomocą:

Przerabiamy portfolio na PWA

W dzisiejszym poście skupimy się na przerobieniu jednego z naszych istniejących projektów na Progressive Web App. Projektem tym będzie portfolio dwójki osób tworzących PoznajProgramowanie.pl, które możecie zobaczyć pod adresem: https://psmyrdek.github.io/Resume/

Będąc na tej właśnie stronie zaczynamy od kliknięcia w przycisk wtyczki Lighthouse, następnie na przycisk Generate Report i oczekujemy na podsumowanie naszej strony.

W naszym przypadku wynik początkowy wygląda tak:

Najlepiej wypada kwestia dostępności i wydajności – strona z którą pracujemy nie zawiera wielu dołączonych skryptów ani styli a obrazki są optymalizowane pod kątem internetu, więc można było się spodziewać przyzwoitego wyniku. Jeśli chodzi o dobre praktyki jest nieco gorzej, ale do szczegółów przejdziemy w dalszych punktach tego posta.

Jeśli chodzi o PWA to jesteśmy tak naprawdę na początku naszej drogi – nie spełniamy wymagań związanych z bezpieczeństwem (HTTP zamiast HTTPS), nie wspieramy trybu offline ani nie dajemy użytkownikowi możliwości dodania skrótu do naszej aplikacji na pulpit.

Nie ma co płakać – czas zabierać się do pracy!

Zacznijmy od HTTPS

Bezpieczeństwo od zawsze było bardzo ważną kwestią jeśli chodzi o usługi dostarczane przez internet. Nic więc dziwnego, że w PWA położono na nie jeszcze większy nacisk – aplikacje PWA obowiązkowo musza być serwowane poprzez bezpieczny protokół HTTPS.

Aby nasza strona była serwowana przez HTTPS, na naszym serwerze musi być m.in. zainstalowany zaufany certyfikat bezpieczeństwa. Możemy go zakupić od naszego dostawcy hostingu, bądź skorzystać z darmowych rozwiązań takich jak https://letsencrypt.org/ – w obu przypadkach całość należy poprawnie skonfigurować w ustawieniach serwera. W naszym przypadku jest znacznie łatwiej – portfolio hostujemy na GitHub Pages, a tam włączenie HTTPS odbywa się za pomocą jednego przełącznika w ustawieniach strony:Klikamy w przycisk Enforce HTTPS, odświeżamy stronę bądź przechodzimy pod adres https://… i gotowe! Od teraz nasza strona serwowana jest przy użyciu protokołu szyfrowanego. Przy ponownym uruchomieniu audytu narzędzia Lighthouse za tę zmianę zyskamy kilka punktów przybliżających nas do PWA, jednak warto pamiętać, że cyferki i znaczki to nie cel sam w sobie. Przechodząc na HTTPS najważniejsze jest to, że zwiększamy w znaczący sposób bezpieczeństwo połączeń pomiędzy naszym serwerem i klientami które się z nim komunikują.

Co dalej?

Manifest

Kolejnym krokiem jaki musimy wykonać jest opisane naszej strony za pomocą metadanych w taki sposób, żeby wybrane urządzenia takie jak smartfony mogły ją traktować jak pełnoprawną, natywną aplikację.

Służy do tego manifest, który jest niczym innym jak zwykłym plikiem w formacie JSON – za jego pomocą definiujemy pełną i skróconą nazwę naszej “aplikacji”, wybieramy kolory motywów czy przypisujemy obrazki które będą pełnić role ikon dających dostęp do naszej aplikacji np. z poziomu pulpitu smartfona.

W naszym przypadku prezentuje się on w sposób następujący:

Poszczególne właściwości w naszym przypadku to nazwa, orientacja ekranu w przypadku uruchamiania z pulpitu (portrait), kolory oraz ikony. Na samym końcu podany jest jeszcze start_url który określa z jakiego adresu dana aplikacja ma wystartować (u nas będzie to https://psmyrdek.github.io/Resume?utm_source=homescreen).

Przygotowany manifest umieszczamy w katalogu z naszą stroną, a rejestrujemy go w sekcji head naszego index.html:

Sprawdzenie tego, czy operacja przebiegła poprawnie, możemy wykonać w narzędziach programistycznych – u mnie to Chrome i zakładka Application / Manifest:

Przy okazji – parametr utm_source który dodaliśmy do start_url może służyć do analizowania (np. przez Google Analytics) ruchu na naszej stronie, a w tym przypadku ilości wejść z ekranu głównego na nasze portfolio. To dla nas bardzo przydatna rzecz w momencie kiedy stwierdzimy, że chcielibyśmy się dowiedzieć czegoś więcej o tym jak użytkownicy korzystają z tego co im przygotowaliśmy.

Po przejściu na HTTPS i dodaniu manifestu wyniku audytu wyglądają teraz tak jak poniżej:

Nasz wynik to 64/100 – jest całkiem nieźle.

W tym poście chciałbym się skupić jedynie na kryteriach dotyczących PWA, dlatego teraz tylko nadmienię, że w międzyczasie optymalizowałem proces bundlowania skryptów i styli, dlatego możecie zauważysz mały skok wartości Performance i Best Practices. W waszych projektach poprawicie je stosując się do wskazówek które w audycie poda wam na dłoni Lighthouse – zdecydowanie polecam przyjrzeć się każdej sekcji.

Po krótkiej dygresji wróćmy na drogę do PWA. W kolejnym kroku chcielibyśmy, żeby nasi użytkownicy mogli dodać naszą aplikację na pulpit, aby wrażenia z jej używania nie różniły się niczym od używania aplikacji mobilnych. Aby zobaczyć czy jesteśmy na to gotowi wracamy do podsumowania naszego manifestu w narzędziach developerskich i klikamy Add to homescreen:

Na stronie nie odnaleziono Service Workera, a przez to strona nie może zostać zainstalowana na urządzeniu. O co tutaj chodzi?

Service Worker – co, gdzie, kiedy?

Najpierw kilka słów o tym, czemu brak Service Workera stoi na przeszkodzie do zainstalowania naszej aplikacji.

Wspomniałem na początku, że PWA mają dostarczać wrażenia maksymalnie zbliżone do aplikacji natywnych. Czym zatem powinny się charakteryzować?

  • dostępem z poziomu pulpitu
  • możliwością uruchomienia bez konieczności połączenia z internetem
  • szybkim dostarczeniem najważniejszych elementów interfejsu użytkownika
  • przyjaznym ekranem powitalnym

Powyższe punkty pomoże nam spełnić właśnie Service Worker.

Service Worker (SW) to nic innego jak skrypt który uruchamia się w tle i pracuje niezależnie od skryptów które normalnie zamieszczone są na danej stronie internetowej. Możemy za jego pomocą przechwytywać zapytania wysyłane z danej strony do serwera, cache’ować wybrane elementy strony, czy też okresowo synchronizować stan strony i wysyłać do użytkowników powiadomienia push.

Najważniejszą funkcjonalnością SW w naszym przypadku jest przechwytywanie i przekierowywanie zapytań sieciowych – dzięki temu będziemy w stanie (po uprzednim ich zcache’owaniu) serwować pliki związane z naszą stroną internetową bez dostępu do serwera na którym dana strona jest hostowana. Zapisany lokalnie szkielet aplikacji (app shell) będzie dostępny niezależnie od jakości połączenia z internetem i dostępny natychmiast po uruchomieniu aplikacji. W naszym przypadku zapiszemy do cache’a wszystkie najważniejsze elementy strony.

Całość będzie działać następująco:

Aby rozpocząć korzystanie z SW najpierw musimy go zainstalować na naszej stronie internetowej. Do tego celu posłuży nam prosty skrypt js’owy który dodamy do naszej strony:

Pierwsza linijka tego skryptu jest bardzo ważna – Service Workera zainstalujemy tylko wtedy, kiedy przeglądarka użytkownika wchodzącego na naszą stronę obsługuje takie API. Użytkownicy korzystający ze starszych przeglądarek będą mogli korzystać z naszej strony tak jak do tej pory – w żadnym wypadku nie wyprosimy ich z grona użytkowników których wspieramy. Na tym polega cała istota tzw. “progressive enhancement” w którą wpisują się Progressive Web Apps – zaczynamy od zwykłej strony internetowej i stopniowo dodajemy kolejne funkcjonalności nie burząc kompatybilności wstecznej.

Idąc dalej – jeśli użytkownicy będą mieć dostępne API Service Workerów, to rejestrujemy naszego pierwszego workera którego będziemy implementować w pliku sw.js. Jeśli rejestracja się powiedzie, to dodatkowo wypisujemy do konsoli jaki “scope” jest dostępny dla zarejestrowanego workera – o scope’ach więcej przeczytacie tutaj.

Status zainstalowanego workera będziemy mogli podejrzeć w DevToolsach:

W konsoli natomiast powinna się pojawić informacja, że instalacja przebiegła pomyślnie a scope dostępny dla workera to root naszej strony internetowej – dzięki temu w workerze będziemy mogli przechwytywać dowolne zapytania w obrębie domeny na której znajduje się nasza strona.

Bazowa implementacja SW (plik sw.js) wygląda w ten sposób:

Od czegoś trzeba zacząć – mamy już jeden bardzo ważny element naszego workera, czyli event listener który wykona się w momencie instalowania SW na stronie.

W jaki sposób możemy teraz użyć Service Workera do zaimplementowania wsparcia dla trybu offline? Możemy użyć w tym celu Cache API i zapisać po stronie klienta interesujące nas dokumenty których potrzebujemy do korzystania z danej strony. W naszym przypadku będą to:

  • index.html
  • pliki ze skryptami i stylami które dołączamy do index.html
  • plik projects.json który w naszym portfolio służy do przechowywania wszystkich zrealizowanych projektów

Rozbudujmy nasz listener tak, aby cache’ować dokumenty podane powyżej:

Na początku definiujemy klucz dla naszego cache’a, definiujemy tablicę adresów z których odpowiedzi będziemy cache’ować, a następnie za pomocą Cache API zapisujemy je wszystkie po stronie klienta.

Poprawny zapis w cache’u możemy sprawdzić w DevToolsach w zakładce Application / Cache Storage, a w Network możemy podejrzeć które pliki zostały pobrane z powodu requestu Service Workera (koło zębate obok nazwy):

Nasz cache…:

…i podsumowanie pobranych dokumentów:

Do wspierania trybu offline brakuje nam ostatniej części układanki – zwracania tych dokumentów z lokalnego cache’a. Zaktualizujmy więc nasz plik sw.js o fragment w którym przechwycimy request klienta i zwrócimy zawartość zapisaną lokalnie:

Właśnie w tym celu dodajemy event listener na zdarzenie fetch – w momencie kiedy klient wyśle zapytanie po dowolny zasób możemy je przechwycić i ustawić odpowiedź w dowolny sposób. W naszym przypadku sprawdzimy, czy wynik zapytania które w danym momencie jest wysyłane do serwera nie znajduje się być może w naszym cache’u – jeśli tak jest, to zwrócimy zapisaną odpowiedź. W przeciwnym przypadku zapytanie podąży standardową ścieżką.

Jest to jeden z najprostszych do omówienia przypadków, w którym określamy na sztywno jakie zasoby chcemy cache’ować. Mechanizm ten można też modyfikować w ten sposób, że zdarzenie fetch będzie naszym punktem startowym do cache’owania wyniku zapytania które się wykonuje. Jest to przypadek nieco bardziej skomplikowany i poświęcimy mu, jak i całemu tematowi pracy z Service Workerami, osobny post.

A co z wynikami audytu? Zobaczmy, co Lighthouse mówi teraz o naszym portfolio:

Wygląda to naprawdę dobrze! Ale co właściwie zyskaliśmy dzięki dodaniu Service Workera i cache’owaniu requestów?

Nasza aplikacja zaczyna przypominać aplikację natywną

Po pierwsze, po wejściu na stronę z przeglądarki Chrome zostajemy zapytani czy chcemy utworzyć skrót na pulpicie:

Po drugie, po dodaniu aplikacji na pulpit użytkownik ma wrażenie, że zaczyna korzystać z aplikacji natywnej:

Po trzecie, nie potrzebujemy połączenia z internetem żeby użytkownicy mieli dostęp do naszych treści:

Robi wrażenie!

Oczywiście layout naszego portfolio wciąż przypomina typową stronę internetową, jednak w kontekście wrażeń dla użytkownika zyskaliśmy i tak bardzo dużo. Dowodem na to są pytania o to, od kiedy mamy naszą własną aplikację mobilną 😉 W przypadku kiedy tworzylibyśmy projekt gdzie PWA miałoby być jednym z głównych założeń, to wrażenia które dostarczalibyśmy użytkownikom byłyby jeszcze bliższe aplikacjom natywnym – wtedy decyzja o wsparciu PWA przyniosłaby zapewne jeszcze więcej korzyści.

W tym momencie optymalizacja strony jeszcze się nie kończy – dzięki wtyczce Lighthouse mogę się teraz skupić na kolejnych krokach takich jak dostępność, optymalizacja skryptów i wszystkich zasobów które użytkownik musi pobrać, a także sprawdzeniu jak do mojej strony mają się dobre praktyki polecane przez takie firmy jak chociażby Google. W dzisiejszym poście chciałem jednak pokazać główne założenia PWA, dlatego dociągnięcie do “4×100” pozostawiam dla chętnych 😉

No i na koniec bonus, który może przekonać niezdecydowanych…

Aplikacje natywne mogę pobrać ze sklepu!

Tak jak PWA 🙂 Dokładnie tak samo.

Przeglądarki Google i Bing poczyniły już spore kroki w kierunku tego, żeby aplikacje i strony internetowe spełniające kryteria PWA były indeksowane w sklepach z aplikacjami firm które za nimi stoją na równi z aplikacjami natywnymi.

Ten krok to być może prawdziwa rewolucja na rynku usług internetowych i aplikacji mobilnych – zamiast żmudnego procesu rejestracji aplikacji mobilnej, Google i Bing będą automatycznie wybierać najlepsze PWA dostępne w internecie i weryfikować je po swojej stronie – po pozytywnej weryfikacji twoja PWA będzie niebawem dostępna w Google Play i Windows Store.

Jeśli nic nie zepsuje planów największych firm z branży IT to niebawem może okazać się, że jedną z najlepszych realizacji powiedzenia “write once, run everywhere” będą właśnie PWA.

A jeśli macie wątpliwości czy aplikacje webowe dorównają kiedyś aplikacjom natywnym, to zobaczcie co już dzisiaj mają do zaoferowania przeglądarki internetowe – https://whatwebcando.today/.

PWA od strony praktycznej

Wszystkich, którzy zastanawiają się, czy PWA to kolejny front-endowy buzzword o którym za kilka miesięcy nie będzie nikt pamiętał chciałbym przekonać, że tak naprawdę w całej idei stojącej za Progressive Web Apps nie chodzi wcale o tymczasową modę, wtyczki i narzędzia.

Powiem więcej – możesz być nawet zagorzałym ich przeciwnikiem. Najważniejsze, że…:

  • zadbasz o wydajność
  • zadbasz o dostępność
  • zadbasz o wrażenia użytkownika

…i twoja strona w naturalny sposób zacznie funkcjonować jak PWA. Musisz przyznać, że punkty które tutaj wymieniłem warto wprowadzać w życie niezależnie od poglądów. Zwiększając grono odbiorców dla których strona internetowa zadziała szybciej, będzie odporna na wahania sieci i dostosuje swój wygląd do urządzenia zwiększysz automatycznie grono klientów danej usługi którą chciałbyś oferować.

Dla mnie osobiście największym plusem całej tej idei jest jej fundament, czyli progressive enhancement. Wspierania PWA nie zaczynamy od wtyczki, nowego serwera czy innej zabawki która burzy wsteczną kompatybilność. Zamiast tego zaczynamy od istniejącego projektu i stopniowo rozwijamy jego możliwości. Jest to o wiele bezpieczniejsze podejście które możemy adaptować stopniowo, bez przymusu wywracania do góry nogami wszystkiego co stworzyliśmy do tej pory. U nas wyglądało to dokładnie w ten sposób – portfolio powstało kilka miesięcy temu, a teraz przy okazji posta o PWA dodałem do niego nowe funkcjonalności. Użytkownicy korzystający ze starszych przeglądarek nie zauważą różnicy, a nowi mogą tylko zyskać.

Mnie to przekonuje, a was?

  • Fajne wprowadzenie do tematu PWA, już nie mogę się doczekać kolejnych wpisów 🙂

    • Przemek Smyrdek

      Dzięki za komentarz! To na pewno nie ostatni post w tym temacie.

  • Paweł Chyła

    Jeden z lepszych, jak nie najlepszy z polskich wpisów na temat PWA. Wpis dość dobrze wyczerpuje ten temat i pozwala osobie, która kiedyś, gdzieś tam słyszała ten buzzword, zrozumieć na czym to poleg

    • Przemek Smyrdek

      Dzięki! Robimy co się da, żeby przy okazji prezentowania danego tematu forma była jak najbardziej przystępna dla naszych czytelników. Jeśli dało się zrozumieć główne założenia to bardzo mnie to cieszy 🙂

  • Guy Diamond

    Super artykuł! Chciałem tylko dodać, że możemy użyć generatora pliku manifest.json: https://app-manifest.firebaseapp.com. Nie musimy się bawić się w tworzenie ikonek i wklepywać ustawień.

    • Przemek Smyrdek

      Ja tam lubię przy tak drobnych rzeczach doglądnąć wszystkiego samemu 😉

  • good job! czekam na wpis o service workerach D:

    • Przemek Smyrdek

      Kolejny post ode mnie będzie prawdopodobnie w tym temacie – zachęcam do sprawdzania 😉

  • Jacek

    Szkoda tylko, że Apple nawet w planach nie ma tego rozwiązania i tak przygotowanej strony/aplikacji nie przypniemy na iOS do ekranu głównego.

    • Przemek Smyrdek

      Na pewno PWA nie należy traktować jak czegoś, co na dobre ma zastąpić aplikacje mobilne, dlatego brak wsparcia Apple nie boli aż tak bardzo. Dla nich to logiczne – przy PWA omijałbyś App Store, które dla Apple’a jest jedną z kluczowych elementów ekosystemu. Najważniejsze, że brak “dodaj do pulpitu” nie blokuje cię przed optymalizacją innych kwestii takich jak dostępność czy wydajność. Tak jak pisałem na końcu – nawet jak cała idea komuś się nie podoba, to jej składowe tak czy tak pomogą podnieść jakość twojej strony / aplikacji. A to jest najważniejsze.

  • @przemeksmyrdek:disqus Jaki sens jest pisać o czym pisałem 3 miesiące temu? 😉 https://piecioshka.pl/blog/2017/05/07/jak-przerobic-strone-na-pwa.html

    • MZOG

      Dokładnie, na innej stronie posłużyłem się ServiceWorkerem z powyższego poradnika i nie zadziałał.
      Powróciłem do wersji Piotrka Kowalskiego i dziwne jest to, że na lokalnym środowisku normalnie mi zarejestrowało ServiceWorker’a jednak po wrzuceniu plików na serwer nie działa. Nie działa na github’ie i na ‘normalnym’ hostingu również :<

      • Przemek Smyrdek

        @mzog:disqus może na serwerze zdalnym masz stronę w podfolderze, a Service Worker zarejestrowany w “roocie” czyli “/” ? U mnie musiałem przejść na ścieżki relatywne, bo na GitHub Pages mamy stronę na /Resume a lokalnie na /, więc nie mogę używać ścieżek absolutnych tylko relatywnych. Po drugie – czy to, że nie zadziałał u ciebie oznacza, że wina jest na pewno po stronie autora posta? Możesz wejść na nasze portfolio, zobaczyć w DevToolsach czy to o czym pisałem jest prawdą i ocenić samemu 🙂 To nie jest uniwersalny poradnik dot. Service Workerów, tylko opis integrowania istniejącego projektu ze standardem PWA. To wszystko 🙂

        @piecioshka:disqus Nie traktujemy tego bloga jak wyścigu na gorące tematy – mamy ochotę pisać o danym temacie, to po prostu piszemy. Tutaj postanowiłem, że sprawdzę na własnej skórze czym są PWA i jak się je integruje z istniejącym projektem, więc wziąłem nasze portfolio i po prostu opisałem najważniejsze punkty z tego co udało mi się osiągnąć. W sieci jest dość miejsca dla każdego, spokojnie 😉

  • Kinga Kużel

    Bardzo dobrze czytało mi się artykuł. Przystępnie napisane – super, teraz wiem co o jak ☺

    • Przemek Smyrdek

      Dzięki!

  • Radosław Maziarka
  • Akairis

    Dziękuję, za fajny artykuł 🙂