Angielskim terminem „frontend” określana jest warstwa prezentacji i interakcji z użytkownikiem aplikacji internetowej, postrzegana jest najczęściej jako wykorzystanie trzech języków: HTML, CSS i ECMAScript (JavaScript). Pojęcie to obejmuje oczywiście także inne technologie obecne po stronie klienta, ale te trzy wymienione są najistotniejsze i w tej notce skupię się właśnie na nich.

W dzisiejszych czasach frontend to niezmiernie czasochłonny element przy projektowaniu serwisów i aplikacji internetowych. Dzieje się tak dlatego, że użytkownicy oczekują bogatej oprawy graficznej, wysokiej interakcji czy też możliwości korzystania z usług z dowolnego miejsca w jakim się znajdą. Przekłada się to bezpośrednio na koszty projektowe – przykładowo w trakcie produkcji nowej odsłony serwisu sport.onet.pl 70% prac programistycznych to prace frontendowe.
Warstwa kliencka niesie z sobą nie lada wyzwanie – sprostać rosnącym wymaganiom użytkowników w coraz szerszej gamie środowisk klienckich. Poniższe grafiki prezentują zmiany przeglądarek na polskim rynku w przestrzeni trzech lat.

Zmiany przeglądarek desktop (źródło: Ranking.pl):

Zmiany przeglądarek mobilnych (źródło: Ranking.pl):

Jak widać na ilustracjach środowisko jest bardzo zmienne, natomiast cykl życia produktów w nim działających jest dłuższy.

Główne wyzwania

  • Zapewnienie podobnego wyglądu strony w różnych klientach desktop.
  • Jakość – używanie w pełni możliwości oferowanych przez używane języki.
  • Semantyczność kodu HTML – opisującego dane, a nie wygląd.
  • Obsłużyć klientów o innych możliwościach niż przeglądarka desktop.
  • Spełniać wymagania SEO.
  • Zapewnić gotowość produktu na dalszy rozwój.
  • Dbać o użyteczność i dostępność dla wszystkich.
  • Dostarczać rozwiązania przenoszalne i łatwe w integracji.
  • Wydajność.
  • Bezpieczeństwo.

Należy zaznaczyć, że przeglądarki internetowe nie były projektowane jako środowiska uruchomieniowe zaawansowanych aplikacji. Każda z nich rozwijana jest w odmienny sposób, każda różnorodnie implementuje „standardy”, działa w innym środowisku itd… Poziom skomplikowania warstwy frontowej to iloczyn składowych poniższych punktów:

  • wiedza (xhtml, css, javascript, dom, komunikacja z serwerem, specyfikacje, implementacje, błędy implementacji = x8)
  • różnorodność przeglądarek (poszczególne IE, FF, Opera, Chrome, Safari = x13)
  • różnorodność platform (Windows, MacOS, Linux, Unix = x4)
  • tryby renderowania (x2)
  • 8 x 13 x 4 x 2 = 832

Dodatkowym aspektem jest fakt, że programista frontendu nie może swojego oprogramowania

  • skompilować – nie ma kompilatora który wyłapie błędy,
  • ufać i przewidzieć, że program będzie mógł się uruchomić – nie wiadomo gdzie i kiedy zostanie uruchomiony,
  • przechować danych, po stronie klienta – nie ma gwarancji że klient będzie posiadał mechanizm składowania,
  • ukryć – kod zawsze jest dostępny dla uruchamiającego stronę.

W tak wymagającym środowisku nie trudno o problemy, aby minimalizować ryzyko ich występowania opracowano strategie rozwoju Graceful Degradation oraz Progressive Enhancement. Aby dobrze zrozumieć na czym polega PE, posłużę się opisem jak wygląda proces powstawania strony WWW bez zastosowania tej strategii.

Typowy przebieg projektu

Zazwyczaj punktem wyjścia do rozpoczęcia produkcji jest projekt funkcjonalny i projekt graficzny. W warstwie programowania interfejsu (frontend) szczególny nacisk położony jest na ten drugi. Programista otrzymuje przygotowane przez grafika projekty, patrzy jak przy pomocy HTML i CSS zrealizować jego wizję. Ustala z nim jak należy je pociąć, a gdy już ma gotowe pliki przystępuje do przekształcenia tego co otrzymał na formę przystosowaną do prezentowania w przeglądarce internetowej. Schemat pracy wygląda następująco – pisze trochę kodu HTML, następnie trochę CSS, podpatruje w przeglądarce jak prezentuje się wykonany fragment. Gdy skończy jeden element np. zakładkę, przechodzi do następnego elementu np. treść dla zakładki i powtarza cykl napisz-podpatrz. Gdy już uzyska pożądany wygląd, dodaje kilka zakładek. Dopisuje w JavaScript’cie przełączanie zakładek i zapełnia je treścią przy pomocy XHR. Po pewnym czasie otrzymuje w swojej ulubionej przeglądarce taki sam wynik wyświetlania jak na projekcie graficznym. Następnie rozpoczyna proces testowania pod innymi przeglądarkami – przechodzi przez kolejne wersje Firefoxa, IE, Opery, Safari, Chrome, niestety z różnymi rezultatami.

Graceful Degradation

Aby zaradzić pojawiającym się w różnych klientach problemom stosuje szereg technik „naprawiających” działanie produktu. Najczęściej spotykane rozwiązania to: dodawanie hacków CSS w arkuszach, stosowanie arkuszy/skryptów osadzanych warunkowo, opracowywanie specjalnych wersji dla różnych klientów.

Jest to strategia skupiająca cel produkcji na zaawansowanych klientach, marginalizując znaczenie przeglądarek o mniejszych możliwościach, uznając je w domyśle za przestarzałe.

Graceful Degradation to strategia służąca naprawianiu problemów, jednakże niesie ona ze sobą dwojakie ryzyko: po pierwsze nie ma gwarancji, że wszystkie scenariusze użycia zostaną przetestowane, a po drugie dokonując poprawek dla jednego przypadku użycia, można spowodować błędy w innym.

Progressive Enhancement – profilaktyka przede wszystkim

Powszechnie wiadomo, że znacznie lepiej jest zapobiegać, niż leczyć. Strategia Progressive Enhancement realizuje tą regułę poprzez zastosowanie dobrej kolejności w procesie produkcji.
PE polega na tworzeniu projektu w trzech następujących po sobie etapach:

  1. kodowania danych – HTML,
  2. opisu prezentacji – CSS,
  3. programowania interakcji interfejsu – JavaScript.

Dzięki zachowaniu takiej kolejności po zakończeniu każdego z etapów uzyskujemy po stronie klienta:

  1. Wersję serwisu obsługiwaną przez wszystkie czytniki dokumentów HTML w sposób dla nich domyślny. Zapewnia to, że niezależnie od możliwości czytnika użytkownik otrzyma treści, które będzie w stanie odczytać i zrozumieć.
  2. Wersję obsługiwaną przez przeglądarki wspierające CSS. Serwis zapewnia przekaz (wygląd) najbardziej optymalny do możliwości prezentacyjnych sprzętu i oprogramowania użytkownika.
  3. Wersję serwisu wykorzystującą w pełni możliwości przeglądarki, dostarczającą treści szybciej, z lepszą interakcją i najlepszym „user experience”.

Po stronie produkcyjnej i utrzymaniowej otrzymujemy:

  1. Podstawowy zakres funkcjonalny już po zakończeniu drugiego etapu – produkt jest gotowy do użycia – zapewniając czytelną treść, wygląd i podstawową interakcje.
  2. Produkt o przejrzystej trójwarstwowej architekturze.
  3. Stabilność. To czy serwis zadziała u użytkownika nie jest kwestią wiary. Wiary w to, że: przeglądarka załadowała CSS, przeglądarka obsługuje JavaScript, przeglądarka obsługuje CSS i model blokowy zgodny z rekomendacją W3C, użytkownik posiada monitor, użytkownik używa myszki etc.

Przykład z życia

Strona główna serwisu sport.onet.pl może posłużyć za przykład realizacji obu strategii projektowych. Przykładowo patrząc na bloczki z zakładkami na lewej kolumnie („Piłka nożna” i „Inne dyscypliny”) bez włączonego JavaScript’u nadal możemy po nich się poruszać dzięki wykorzystaniu zwykłych kotwic, a gdy klient nie będzie posiadał obsługi CSS’a bloczki będą nadal czytelne. Natomiast bez JavaScriptu na stronie głównej klient nie otrzyma sidebara, gdyż z założenia jest on obiektem dynamicznym.

Słowem podsumowania – dobrze stosowane strategie rozwoju porządkują proces produkcji, a w trakcie dalszego utrzymania redukują koszty i obniżają poziom adrenaliny u deweloperów.

Krzysztof Osetek
starszy programista