JavaScript

JavaScript to, obok HTML-a i CSS-a, podstawowa technologia tworzenia aplikacji sieciowych. Obecne możliwości tego języka pozwalają tworzyć naprawdę niesamowite rzeczy, jak choćby radar lotniczy. W wielu przypadkach może też poprawiać dostępność – zwłaszcza w bardziej skomplikowanych elementach UI. Nie można więc powiedzieć, że JS jest czymś złym. Wręcz przeciwnie, współczesna Sieć nie miałaby okazji powstać, gdyby nie ten język programowania. Ale skoro w JS-ie można dzisiaj śledzić trasy przelotów samolotów, to wypada przypomnieć słowa pewnego słynnego wujka:

Z wielką mocą wiąże się wielka odpowiedzialność.

JS wyróżnia się od HTML-a i CSS-a jedną zasadniczą cechą: nie jest odporny na błędy. W specyfikacji HTML sporo miejsca poświęcono temu, jak przeglądarki mają radzić sobie z błędami, takimi jak źle zagnieżdżone elementy. Dzięki temu nawet największa HTML-owa zupa ma szansę wyświetlić się (w miarę) poprawnie. CSS z kolei po prostu ignoruje niepoprawny kod, co oznacza, że co najwyżej jakiś bombastyczny przycisk będzie nieco mniej bombastyczny. JS za to wybucha. Najczęściej osobie użytkowniczej prosto w twarz. A żeby tego było mało, niezwykle trudno przewidzieć, kiedy to się stanie. Bo JS może zawieść z wielu powodów. Ot, komuś przerwało połączenie na sekundę i nie doczytał się jakiś plik JS. Albo ktoś używa starej wersji przeglądarki. Może nasz CI był źle skonfigurowany i przepuścił na produkcję nieprawidłowy kod. Gówno się zdarza, a naszym zadaniem jest zadbanie o to, by obsłużyć takie kałowe incydenty w sposób jak najmniej dotkliwy dla osoby użytkowniczej.

Niemniej przez kilka lat najpopularniejszym podejściem były Single Page Applications (SPA). Choć u swojej podstawy pomysł jest całkiem logiczny (całość aplikacji powinna być jedną stroną WWW, dzięki czemu ograniczymy konieczność renderowania i wczytywania nowych stron z serwera), to rzeczywistość szybko go zweryfikowała. Tradycyjne SPA opierały się w dużej mierze na renderowaniu wszystkiego po stronie przeglądarki. To sprawiało, że działały wolniej od stron, które renderowały się na serwerze. SPA nie lubiły się też z niestabilnymi i wolnymi łączami, bo wymagały ściągnięcia całego kodu JS, zanim zaczną cokolwiek renderować. Na szczęście obecnie się to zmienia. SPA coraz częściej używają zarówno renderowania po stronie serwera, jak i przeglądarki. Dzięki temu strona renderuje się nawet bez potrzeby ściągania JS-a. Co więcej, upowszechnienie się PWA sprawiło, że SPA zdecydowanie lepiej radzą sobie z kiepskiej jakości połączeniem internetowym. Do tego stopnia, że mogą działać offline. Niemniej SPA wciąż stawiają przed osobami webdeveloperskimi sporo wyzwań, w tym odpowiednie zarządzanie nawigacją między poszczególnymi podstronami aplikacji. Przeglądarki ten problem rozwiązują w przypadku tradycyjnych stron WWW, a współczesne rozwiązania pozwalają nawet animować przejścia między podstronami. To sprawia, że SPA są coraz mniej atrakcyjne w przypadku sporej części aplikacji sieciowych, które składają się z kilku podstron (widoków). Świetnie natomiast sprawdzą się w aplikacjach, gdzie nie ma podstron, a serwer służy głównie do wysłania plików strony, np. edytory grafiki pokroju Photopei. A jak już tworzymy SPA (i inne aplikacje internetowe w sumie też), to warto pamiętać o kilku zasadach:

  1. Prerenderowanie stron nie jest opcjonalne.
  2. Reaguj natychmiast na interakcję ze strony osoby użytkowniczej.
  3. Reaguj na zmianę danych.
  4. Kontroluj wymianę danych z serwerem.
  5. Nie psuj historii (nawigacji), ulepszaj ją
  6. Aktualizuj regularnie kod.
  7. Przewiduj zachowania.

W idealnym świecie większość stron powinna działać bez JS-a. Metodyki, takie jak Progressive Enhancement, przez lata wypracowały odpowiednie metody, by to umożliwiać. Ale nie żyjemy w idealnym świecie, więc drugą najlepszą możliwością jest pisanie JS-a w sposób odpowiedzialny. Bo nigdy nie wiadomo, kiedy może wybuchnąć.

Źródła

Dodatkowe materiały