Progressive Enhancement

Progressive Enhancement (PE) – Stopniowe Ulepszanie to jedno z najstarszych podejść do tworzenia stron internetowych. Termin został ukuty przez Stevena Champeona i Nicka Fincka 11 marca 2003 roku na konferencji SXSW Interactive w Austin. Innymi słowy: PE ma już 21 lat. A skoro wciąż się trzyma, to prawdopodobnie coś robi dobrze.

Można zaryzykować twierdzenie, że PE jest podejściem, które niejako wywodzi się z samej natury Sieci. Sieć jest całkowicie nieprzewidywalna i w każdej chwili coś może wybuchnąć. Naszym zadaniem, jako osoby webdeveloperskiej, jest przygotowanie się na jak największą liczbę nieprzewidzianych katastrof. Nie wiemy bowiem nic o tym, czy połączenie osoby użytkowniczej jest stabilne, czy jej przeglądarka jest aktualna, czy z jakiegoś powodu nie wyłączyła JS-a w przeglądarce (ot, choćby, żeby wyeliminować śledzące ciasteczka)… Nad żadną z tych rzeczy nie mamy jakiejkolwiek kontroli. To, co kontrolujemy, to nasza strona WWW. Więc zostaje nam przygotować ją w taki sposób, żeby była odporna na różne przeciwności losu. Ostatecznie naszym zadaniem jest zaserwowanie osobie użytkowniczej strony, która jest użyteczna i pozwala spełnić jakąś jej potrzebę.

I tutaj na scenę wkracza PE, które właśnie ma stanowić niejako kamizelkę kuloodporną dla naszej strony WWW.

Warstwy

PE jest jak ogry – ma warstwy. W najprostszym, tradycyjnym ujęciu PE ma tylko trzy warstwy:

Aaron Gustafson w swoim artykule z 2008 roku przyrównał je do cukierka M&M’s. Treść to orzeszek, prezentacja to warstwa czekolady, a JS – to twarda zewnętrzna skorupka. Osobiście bardziej przekonuje mnie nieco inna metafora. Treść to szkic – zawiera wszystkie niezbędne elementy, żeby osoba oglądająca go rozumiała na co patrzy, ale niekoniecznie była zachwycona. Warstwa prezentacji to z kolei dodanie kolorów do tego szkicu – tak, aby powstał pełnoprawny obraz, piękny i zachwycający. Z kolei warstwa zachowania to pozłacana rama, dzięki której można ten obraz zawiesić na ścianie.

Jak widać, każda kolejna warstwa ulepsza to, co już istnieje. A równocześnie – wyższe warstwy nie mają sensu, jeśli nie istnieją te niżej. Nie ma sensu wsadzać niepokolorowanego szkicu do pozłacanej ramy, bo jedynie marnuje się ramę. Tak samo nie ma sensu nakładać kolorów na płótno, jeśli nie ma tam jeszcze szkicu, bo uzyskamy jedynie kilka barwnych plam.

I tak w dużym skrócie wygląda PE: dzielimy strony na warstwy, z których każda ulepsza poprzednią. Dziękuję za przybycie na mojego Ted Ta… Chociaż warto wspomnieć o tym, że podział na trzy warstwy niekoniecznie jest jedynym możliwym. Tak naprawdę liczba i rodzaj warstw bardzo mocno zależy od projektu. I tak, na samym spodzie będzie to podział na HTML, CSS i JS. Ale na tym najbardziej podstawowym podziale mogą istnieć inne, bardziej szczegółowe. I nie jest to pomysł bynajmniej nowy, bo mówił o nim już Nicholas Zakas w 2011 roku. Zaproponował on podejście, które nazwał PE 2.0. Zgodnie z nim zarówno CSS, jak i JS, można było podzielić na kolejne warstwy. Wszystko ze względu na możliwości przeglądarek osób użytkowniczych. Najstarsze przeglądarki dostawałyby najbardziej podstawowy CSS i JS, podczas gdy te nowsze – nowoczesny CSS i JS. W tamtych czasach technikę tę można było streścić jako “Internet Explorer dostaje podstawowe style i skrypty, cała reszta – normalne”. Wydawać by się mogło, że obecnie ten problem praktycznie nie występuje – wszak wszystkie przeglądarki przestrzegają standardów, prawda? Rzeczywistość jest jednak bardziej skomplikowana. Strony typu Can I Use? dobrze pokazują, że pomiędzy przeglądarkami wciąż występują spore różnice pomiędzy wspieranymi ficzerami. Niektóre przeglądarki implementują także API, które niekoniecznie są standardami. Dlatego ich wykorzystanie pociąga za sobą stworzenie kolejnej warstwy. Dobrym przykładem może być API do obsługi lokalnych plików. Aplikacja internetowa może domyślnie pozwalać zapisać plik poprzez ściągnięcie go na dysk. Jednak w momencie, gdy dostępne jest API pozwalające na bezpośredni zapis na dysk (co można wykryć przez tzw. feature detection), wówczas aplikacja może się ulepszyć, aby wykorzystywać je zamiast domyślnego podejścia. Bardzo podobnie sprawa się ma z CSS-em, w którym można np. ulepszać layout w zależności od możliwości przeglądarki.

No dobrze, ale jak dzielić aplikację na warstwy? Proces myślenia w PE można rozpisać na kilka kroków:

  1. Zidentyfikuj podstawową funkcjonalność strony.
  2. Pomyśl, jaka jest najprostsza technologia, w jakiej można ją zaimplementować.
  3. Pomyśl o możliwych ulepszeniach.

Weźmy za przykład formularz kontaktowy na stronie WWW:

  1. Podstawowa funkcjonalność: możliwość wysłania wiadomości osobie, która stworzyła tę stronę.
  2. Najprostsza technologia do osiągnięcia tego celu: HTML. Wystarczy nam tak po prawdzie element form.
  3. Możliwe ulepszenia:
    1. ostylowanie formularza przy pomocy CSS-a,
    2. wysyłanie formularza Ajaksem.

Tak wygląda najprostszy przykład myślenia w PE. Oczywiście z ulepszeniami można pójść zdecydowanie dalej i np. wdrożyć cały mechanizm, który wysyłałby formularz w tle, gdyby nagle zerwało połączenie z internetem. Jednak sam trzon podejścia zawsze pozostaje taki sam: identyfikujemy podstawową funkcjonalność i implementujemy ją w najprostszy możliwy sposób. A następnie dokładamy kolejne ulepszenia jako nowe warstwy. W końcu skądś się wzięła nazwa “Stopniowe Ulepszanie”!

To oczywiście oznacza, że różne osoby użytkownicze – w zależności od wielu czynników, np. aktualności ich przeglądarki, stabilności łącza, itd. – otrzymają inną wersję strony. Ale hej, mamy 2024 i dyskusja o tym, czy strony muszą wszędzie wyglądać tak samo, już dawno za nami. W tym względzie PE robi dokładnie to samo, co responsywność. Obydwa podejścia dostosowują się do możliwości urządzenia osoby użytkowniczej. Różnica polega na typie tych możliwości. Responsywność dotyczy możliwości interakcji z osobą użytkowniczą (np. wielkość viewportu i tym samym treści, sposób wprowadzania danych przez osobę użytkowniczą – przez klawiaturę, myszkę, dotyk, itp.). Z kolei PE - możliwości typowo technicznych, które dla osoby użytkowniczej są całkowicie transparentne.

JavaScript

Bardzo często można spotkać się z argumentem, że PE wymaga, żeby wszystkie strony działały bez JS-a. To nie jest prawda. Owszem, istnieją inicjatywy takie jak jsfree.org, ale są raczej ekstremum, nie zaś normą w “środowisku starej gwardii”.

Nikt nie neguje faktu, że JS jest potrzebny. W obecnych czasach jest w stanie zdecydowanie poprawić doświadczenia osoby użytkowniczej czy wręcz podnieść dostępność całego produktu. PE nie ma kosy z JS-em. Zachęca jedynie do nieustannego zadawania sobie pytania “co jeśli…?”. Co jeśli JS nie zadziała? A może nie zadziałać z zaskakująco dużej liczby powodów. I to dość trywialnych, jak korzystanie z internetu w komórce w pociągu, który właśnie wjeżdża do tunelu i połączenie jest na chwilę zerwane. Jeśli strona wymagała ściągnięcia dużego frameworka JS tylko po to, żeby wyświetlić treść, to właśnie straciła jedną osobę użytkowniczą. I nigdy nie wiadomo, kiedy taka sytuacja może się przytrafić. I z jakiego powodu. Bo ktoś może choćby nie zaktualizować przeglądarki. W przypadku HTML-a stara wersja przeglądarki najprawdopodobniej nie spowoduje większych problemów. Ot, nowy typ pola formularza wyświetli się jako pole tekstowe zamiast np. pole do wpisania e-maila. W przypadku CSS-a rownież nie będzie zbyt wielkiej katastrofy – jak przeglądarka nie będzie wspierać grida, to treść wyświetli się w jednej kolumnie, ale wciąż powinna być czytelna. Za to w przypadku JS-a – poważnego języka programowania – wszystko wybuchnie.

PE nie jest anty-JS. To byłoby głupie, bo odcinałoby osoby webdveloperskie od najpotężniejszej technologii webowej. PE jest pro-JS, ale z małą, acz niezwykle istotną gwiazdką: ten JS musi być wdrożony odpowiedzialnie. Jak już było wcześniej wspomniane, podstawą PE jest stopniowe ulepszanie kolejnych warstw strony internetowej. Z kolei same warstwy wyznaczyć można przy pomocy odpowiedzi na dwa proste pytania: co jest podstawową funkcjonalnością strony i jak ją wdrożyć w najprostszy możliwy sposób? Odpowiedź na drugie zaskakująco często brzmi “HTML”. No bo weźmy za przykład stronę z newsami. Podstawowa funkcjonalność: wyświetlenie newsów. A to można zrobić przy pomocy samego HTML-a. W końcu news to głównie treść tekstowa z obrazkami. JS na tego typu stronie służy głównie poprawie doświadczenia użytkownika, np. eliminując potrzebę przeładowania całej strony przy przechodzeniu do innego newsa, zamiast tego podmieniając samą treść. Ale nawet dla bardziej skomplikowanych przypadków odpowiedź będzie brzmieć “HTML”. Nawet takie forum dyskusyjne. Podstawowa funkcjonalność to możliwość wzięcia udziału w dyskusji. A do tego wystarczy wyświetlenie samej dyskusji (co nie różni się zbytnio od wyświetlania newsa) oraz formularza pozwalającego dodać odpowiedź. I znów: JS posłuży tutaj głównie do poprawy doświadczenia użytkownika. Jasne, istnieją wyjątki, takie jak Google Docs czy Figma – ale nawet wówczas da się dostarczyć ograniczone doświadczenie działające bez JS.

Bardzo często argumentuje się, że PE nie nadaje się do aplikacji internetowych. Problem w tym, że niekoniecznie wiadomo, czym jest aplikacja internetowa. Definicja jest mocno płynna. Często można odnieść wrażenie, że używa się jej głównie w celu poprawy doświadczenia osoby webdeveloperskiej. Dzięki stwierdzeniu “ok, ale to apka” często spycha się na margines dyskusję na temat podejścia do tworzenia strony i po prostu bierze akurat popularny framework JS. A przecież sporo aplikacji zyskałoby na użyciu mniej JS-owych rozwiązań. Z kolei czysto JS-owe rozwiązania niosą ze sobą wiele wad, w tym zdecydowanie utrudnione archiwizowanie tego typu stron dla przyszłych pokoleń. Na szczęście obecnie powoli się to zmienia i z jednej strony rozwiązania pokroju Astro mocno promują rozwiązania pozostające w zgodzie z duchem PE, z drugiej – frameworki JS-owe dojrzewają, oferując bardziej całościowe rozwiązania, które potrafią renderować stronę zarówno po stronie przeglądarki, jak i po stronie serwera.

JS powinien robić tylko to, do czego jest niezbędny. To jedyne ograniczenie, jakie PE nakłada na JS.

Inkluzywność

Jeśli przyjrzeć się PE z nieco innej perspektywy, to jego trzonem jest zasada najmniejszej mocy (the rule of least power). Głosi ona, że do wykonania danego zadania należy użyć technologii, która jest najmniej potężna, ale spełnia dobrze zadanie. Wyobraźmy sobie, że chcemy wytwarzać energię elektryczną dla małego domku. Zasada najmniejszej – nomen omen – mocy sugeruje użycie panelu słonecznego na dachu. Zaprzeczeniem tej zasady byłoby postawienie gigantycznej elektrowni jądrowej, która mogłaby zasilić pół kraju, podczas gdy zasilałaby tylko ten jeden mały domek. Niemniej w webdevie często stawia się taką elektrownię jądrową, podczas gdy starczy zwykły panel na dachu. Wygrzebując się z tej nie do końca zręcznej metafory: w wielu sytuacjach, zamiast całego frameworka JS, można by użyć po prostu statycznego HTML-a z CSS-em.

W wielu sytuacjach tego typu rozwiązanie podniesie przy okazji diametralnie poziom inkluzywności strony. To ważne zwłaszcza przy usługach krytycznych, które powinny działać dla jak największej grupy osób. Jak jednak PE podnosi inkluzywność? Otóż dba o to, by podstawowa funkcjonalność była dostępna dla jak największej grupy osób. Robi to przy pomocy omówionych wyżej warstw i doboru jak najprostszej metody dostarczenia konkretnego doświadczenia. Tym samym niejako dostosowuje się do możliwości urządzenia, na którym właśnie przeglądana jest strona WWW. To umożliwia oglądanie strony zarówno na nowoczesnym sprzęcie (który dostanie najpełniejsze doświadczenie), jak i na zdecydowanie słabszym.

Josh Fremer poszedł o krok dalej i stwierdził, że PE jest niejako tożsame z dostępnością. Choć na pierwszy rzut oka brzmi to dość absurdalnie, to jego wyjaśnienie brzmi całkiem przekonująco:

I think of [progressive enhancement and accessibility] as the same process, but with different foci. Accessibility aims to optimize an experience across a spectrum of user capabilities. Progressive enhancement aims to optimize an experience across a spectrum of user agent capabilities.

Indeed, if you broaden the definition of “user agent” to include a user’s physiology, I think the concepts become nearly identical.

[Myślę o PE i dostępności jako o tym samym procesie, ale z innych perspektyw. Dostępność ma na celu optymalizację doświadczenia dla jak najszerszej grupy osób z różnymi możliwościami. PE ma na celu optymalizację doświadczenia dla jak najszerszej grupy programów działających w imieniu osoby użytkowniczej [przeglądarek] z różnymi możliwościami.

Zatem jeśli poszerzy się definicję przeglądarki tak, aby zawierała również fizjologię osoby użytkowniczej, myślę, że obydwa pojęcia stają się niemal identyczne.]

Zgadzam się z Joshem. Gdybym miał to ująć własnymi słowami, stwierdziłbym, że inkluzywność (i wężej – dostępność) to pewna idea, do której się dąży (strona internetowa powinna być dostępna dla jak najszerszej grupy osób), podczas gdy PE – to techniczny sposób realizowania tej idei (podział strony internetowej na warstwy i ulepszanie ich sprawia, że strona jest dostępna dla większej grupy osób).

Wydajność

Okazuje się też, że PE lubi się także z wydajnością. Przy założeniu, że funkcjonalność implementuje się przy pomocy najbardziej podstawowej technologii, bardzo szybko można zauważyć, że dużo da się ugrać samym HTML-em. No bo taki formularz logowania: swoją funkcję będzie pełnił dobrze w momencie, gdy przeglądarka dostanie kod HTML formularza. Jasne, nie będzie ładnej walidacji po stronie klienta, a samo logowanie będzie wymagało przeładowania strony. Ale jest to jak najbardziej robialne. A jak już mamy formularz, to być może wystarczy dodać do niego prostą funkcję wysyłającą go Ajaksem, zamiast robić całe renderowanie po stronie klienta. Co za tym idzie: oszczędzamy transfer i przyśpieszamy renderowanie, jeśli wyślemy z serwera gotowy HTML, zamiast renderować wszystko po stronie przeglądarki. I to fakt znany od co najmniej 10 lat.

Co prawda problem ten nie jest dzisiaj aż tak dotkliwy jak jeszcze kilka lat temu, bo praktycznie wszystkie duże frameworki JS-owe dodały jakąś formę obsługi renderowania po stronie serwera. Ale wciąż można natknąć się na aplikacje, które wszystko robią po stronie przeglądarki. Zatem można dodać kolejny argument przeciwko takiemu rozwiązaniu: jest po prostu wolniejsze. Lepiej jest wysłać gotowy HTML z serwera i go jedynie ulepszyć w przeglądarce, niż kazać przeglądarce ściągnąć kod JS, który dopiero potem zacznie renderować stronę.

Krytyka

PE przez lata doczekało się też licznej krytyki. Jak było już wyżej wspomniane, bardzo często twierdzi się, że PE jest techniką przestarzałą i nieprzystającą do współczesnych czasów. Ale wyżej wspominałem także, czemu niekoniecznie jest to prawda. Tak, PE nie ma sensu w momencie, gdy sprowadza się je do frazy “to ma działać bez JS”, ale to podejście wcale na tym nie polega. Warstwy, mój drogi Watsonie!

Niemniej czasami zdarza się krytyka uderzająca w PE od zupełnie innej strony. Chyba najgłośniejszą w ostatnich latach była ta zawarta w artykule Josha Korra. Twierdził on, że Stopniowe Ulepszanie nie jest w żadnym razie praktycznym podejściem do tworzenia stron WWW, a jedynie – argumentem moralnym: “każda osoba powinna mieć możliwość dostępu do każdej strony WWW”. Żeby udowodnić tę tezę, stwierdził, że… należy interpretować to, czego zwolennicy PE nigdy nie powiedzieli:

To uncover the real argument, you have to analyze what PEers aren’t saying.

[Żeby odkryć prawdziwy argument, musisz analizować to, czego PE-owcy nie mówią.]

Dość odważne podejście, ale też niekoniecznie przekonujące. Tym bardziej, że bardzo szybko skręca to w stronę reductio ad absurdum. Korr w pewnym momencie wręcz stwierdza, że według proponentów PE każda treść w Internecie, w tym objęta specyficznymi prawami autorskimi, powinna być dostępna dla wszystkich za darmo. Co nie ma nic wspólnego ze Stopniowym Ulepszaniem, które dotyczy sfery technicznej stron WWW.

Na odpowiedź ze strony środowiska nie trzeba było długo czekać. Aaron Gustafson skrzętnie wypunktował słabe punkty argumentacji Korra, podając przykłady pokazujące, że PE jak najbardziej jest praktycznym sposobem tworzenia stron WWW. Wspomniał m.in. o bliskim związku podejścia PE z dostępnością (o czym wspominałem już wyżej). Wskazał też, że dostarczanie jakiegokolwiek doświadczenia zamiast żadnego w ekstremalnych przypadkach może być dobre z biznesowego punktu widzenia, ponieważ nie wykluczamy żadnej osoby klienckiej. Tutaj warto dorzucić realny przykład takiego podejścia: Amazon działa bardzo dobrze bez włączonego JavaScriptu. Dzięki temu maksymalizuje liczbę potencjalnych osób klienckich, włączając w nią nawet te osoby, które używają m.in. starszych przeglądarek. I raczej nikt nie podejrzewałby Amazona o robienie czegoś na podstawie moralnego argumentu zamiast z powodów biznesowych…

Zresztą: czy fakt, że coś jest moralnym argumentem, sprawia, że jest to złe? Osobiście uważam, że tak, PE do pewnego stopnia wypływa z etycznego podejścia do webdevelopmentu, ale równocześnie – jest pomyślane w taki sposób, żeby przynosić jak największe korzyści. I to obopólne. Na PE zyskują zarówno osoby użytkownicze (bo dostają stronę, która jest w stanie działać nawet w trudnych warunkach), jak i biznes stojący za stroną (bo dociera do jak najszerszej grupy potencjalnych osób klienckich). A można by to rozszerzyć także i na trzecią stronę – osobę webdeveloperską. PE często pozwala zrobić pewne rzeczy prościej. Jeśli ficzer naszej aplikacji musi wysłać dane do serwera, to przecież HTML od praktycznie zawsze to umożliwiał przy pomocy formularzy. Wystarczy zatem zrobić tradycyjny formularz, a następnie go ulepszyć. Chciałbym, żeby wszystkie moralne argumenty były równocześnie tak praktyczne!

Zdecydowanie ciekawszą krytyką jest ta stworzona przez Kyle’a Simpsona. Argumentuje on, że PE w swojej warstwie technicznej popełnia fundamentalny błąd, broniąc tradycyjnego podziału odpowiedzialności. Jako argument za swoją tezą przytacza tzw. FUBC – Flash of Unbehaviored Content (Mignięcie Nieoskryptowanej Treści). To zjawisko, w którym strona renderuje się przy użyciu samego HTML-a i CSS-a, a następnie zmienia swój wygląd po doczytaniu się JS-a. Jednak tego typu problemy są dość łatwo rozwiązywalne i można im przeciwdziałać. Znów: strona główna Amazona wygląda niemal identycznie niezależnie od tego, czy JS jest wczytany. Simpson zastanawia się też, czy PE wciąż ma sens, skoro coraz mniej jest stron i aplikacji, które są w stanie działać bez JS-a. Tym samym sprowadza trzon swojej krytyki do argumentu, że PE oznacza działanie bez JS-a, co – jak zostało już wspomniane wyżej – nie jest prawdą.

Krytyka Simpsona nie byłaby tak interesująca, gdyby nie druga część jego prezentacji, w której proponuje alternatywę dla PE, która dzieliłaby z nim ten sam skrót: People Empathy (Ludzka Empatia). Głównym założeniem nowego podejścia byłoby pytanie osoby użytkowniczej o to, jaki rodzaj doświadczenia chce: czy pełne, ale też wymagające więcej mocy obliczeniowej i transferu, czy prostsze, ale zdecydowanie mniej zasobożerne? Przeglądarka miałaby być tym miejscem, w którym osoba użytkownicza mogłaby wybrać rodzaj doświadczenia dla konkretnej strony. Ale Simpson zaznacza przy tym, że nie ma co czekać, aż przeglądarki podłapią jego propozycję, i takie opcje osobom użytkowniczym można udostępniać już teraz, przy pomocy elementów UI na samych stronach WWW. I pod tą drugą częścią prezentacji mogę się podpisać obydwoma rękami: dawajmy osobom użytkowniczym wybór!

Ale z pierwszą częścią prezentacji nie do końca się zgadzam. Wciąż uważam, że na ten moment PE jest najlepszym sposobem dostarczania doświadczenia osobom użytkowniczym w większości przypadków. Pozwala na przeciwdziałanie różnym problemom związanych czy to z możliwościami urządzenia osoby użytkowniczej, czy słabym łączem internetowym. Tak, jak wszystkie podejścia do tworzenia stron, ma swoje wyzwania (jak choćby wspomniany FUBC), ale jest też jedną z najdłużej istniejących metodyk tworzenia stron WWW i na wiele z tych wyzwań mamy sprawdzone w boju rozwiązania. Dlatego ja widziałbym przyszłość, w której Stopniowe Ulepszanie i Ludzka Empatia razem działają na rzecz większej inkluzywności.

Źródła

Dodatkowe materiały