Sebastian Rosik, „HTML5 Komponenty”

Dawno nie było żadnej recenzji książki na WebKrytyku, więc wypada to nadrobić! Zwłaszcza, że w moje ręce trafiła dość ciekawa pozycja — HTML5 Komponenty Sebastiana Rosika. Z racji tego, że książka traktuje o technologi Web Components, która – co tu dużo mówić – fascynuje mnie od niemal początków prac nad nią, nie mogłem przejść obok niej obojętnie. Czy opłacało się wydać te kilkadziesiąt złotych?

Niniejsza „recenzja naukowa” powstała na podstawie wydania elektronicznego książki, stąd przy cytatach nie podaję numerów stron (bo ich nie mam…).

Tytuł, wstęp i informacje techniczne

• Tak, wiem, czepiam się i jestem skurczysynem jakich mało, ale… czy tytuł nie powinien być zapisywany jako HTML5. Komponenty? Prawdę mówiąc brakuje mi tej kropki.

• We wstępie w oczy rzucił mi się zbytni optymizm w stosunku do standaryzacji w Sieci:

  Po powstaniu czy aktualizacji standardu twórcy przeglądarek implementują zmiany, po czym developerzy, tacy jak my, zapoznają się z daną technologią i puszczają ją w obieg, wykorzystując ją w swoich projektach.

  Owszem, tak sytuacja wyglądałaby, gdybyśmy żyli w idealnym świecie. A niestety nie żyjemy. W samej specyfikacji HTML5 jest bardzo dużo martwych zapisów. Chyba najsłynniejszym jest algorytm obliczania hierarchii nagłówków, od lat oznaczony ostrzeżeniem o braku implementacji, w maju przeznaczony do usunięcia, w HTML 5.1 oznaczony już jako nienormatywny. Inny przykład – tym razem może z żywej wersji standardu od WHATWG, która ma zawierać wyłącznie realne implementacje – definicja menu[type=toolbar]. Bardziej realne przykłady to elementy details czy (może jeszcze bardziej) dialog. Chyba jedynie usunięcie elementu keygen było faktycznym pogodzeniem stanu faktycznego (czyli braku jakiejkolwiek implementacji) ze standardem.

  Jak zatem widać, standard swoje, przeglądarki swoje.

• Jeszcze jeden fragment we wstępie mnie ciut niepokoi:

  Wrocław, marzec 2016 r.

  Dlaczego? To prawdopodobnie okaże się w dalszej części recenzji.

• W sekcji poświęconej informacjom technicznym podane są informacje o oprogramowaniu, w którym były odpalane przykłady w książce. Widzimy tutaj Chrome 45, Firefoksa 41 czy Node.js 4.0. Obecnie (tj. 4 sierpnia 2016) mamy Chrome 52, Firefoksa 48 i Node.js 4.4 (lub 6.3, jeśli mówimy o najnowszej wersji a nie LTS!). To w połączeniu z informacją ze wstępu (marzec 2016 r.) pozwala zacząć się zastanawiać, na ile opis Web Components w książce jest aktualny. Zwłaszcza, że około czerwca 2016 roku przyklepano nową wersję tego standardu (a raczej: grupy standardów)!
• Na szczęście znajduje się tutaj także informacja, że na oficjalnej witrynie książki będą się pojawiać aktualizacje. Duży plus.

Rozdział 1. Przydatne narzędzia

• Narzędzia deweloperskie przeglądarki Google Chrome oferują wiele funkcjonalności

  Widzę tutaj dwa problemy:

  • Słowo funkcjonalność nie posiada liczby mnogiej. Tutaj powinno być użyte słowo funkcje.
  • W książce występuje pisownia developer. Tym samym powinniśmy mieć raczej narzędzia developerskie, nie zaś – deweloperskie.

• Część zdań w książce jest napisana w sposób albo całkowicie niezrozumiały, albo wieloznaczny, np. (pogrubione zdanie):

  W platformie Node.js wykorzystano silnik JavaScript V8[3], który został stworzony na potrzeby przeglądarki Google Chrome. Pozwala ona na pisanie aplikacji JavaScript poza przeglądarką internetową. Node.js jest często wykorzystywany do pisania aplikacji sieciowych, ponieważ udostępnia wygodne API do jego obsługi.

  Z kontekstu wynika, że Node.js jest dobre do tworzenia aplikacji sieciowych, bo ma wygodne API do obsługi silnika V8… Ale to bez sensu. Chyba chodziło raczej o wygodne API do tworzenia aplikacji sieciowych?

• Nazwanie repozytorium npm repozytorium modułów Node.js jest całkowicie nietrafione. npm nie jest menedżerem pakietów dedykowanym Node.js, ale menedżerem pakietów JS ogólnego zastosowania. Bardzo łatwo to udowodnić, wskazując na pakiet jQuery, służący do instalacji tej popularnej biblioteki, przeznaczonej wyłącznie dla przeglądarek.

• Node Package Manager (NPM)

  To sformułowanie jest bardzo poważnym błędem merytorycznym! npm (nie NPM!) nie jest akronimem!

• Przy wyjaśnianiu obietnic warto zalinkować do standardu Promises/A+ – zwłaszcza, że obietnice z ECMAScript 6 są na nim oparte. Sam ten standard natomiast doczekał się także implementacji poza JS.
• Po dojściu do podrozdziału Domieszki, dotyczącego LESS-a, długą chwilę zajęło mi zorientowanie się, o czym tak naprawdę jest. Mowa o mixinach. I tutaj moja uwaga, która tyczy się chyba każdej książki o tematyce IT w Polsce: polskie nazwy nie funkcjonują w obiegu publicznym – są sztucznymi tworami występującymi wyłącznie w literaturze. Tym samym powinno się stosować albo terminy angielskie (co najwyżej z podanym polskim tłumaczeniem), albo termin polski wraz z angielskim odpowiednikiem.

Rozdział 2. CSS3 i tworzenie komponentów

• Prawdę mówiąc nie do końca jestem pewien, czy ten rozdział w ogóle do tej książki pasuje. Animacje, przejścia i flexbox nie są konieczne przy tworzeniu komponentów przy wykorzystaniu Web Components.
• Jako przykład animacji podano zmianę opacity elementu z 1 do 0, w celu ukrycia elementu, i przedstawiono to jako alternatywę dla animacji własności display. Nie jest to jednak prawda. Zmiana display elementu sprawia, że staje się on niewidoczny dla czytników ekranowych, opacity z kolei po prostu sprawia, że element jest przezroczysty, ale wciąż widoczny dla czytników ekranowych. Tym samym obydwie animacje działają całkowicie inaczej – mimo że efekt wizualny jest identyczny.

• Obecnie najczęściej spotyka się następujące prefiksy:

  • -webkit-* dla przeglądarek Google Chrome oraz najnowszych wersji Opery;

  […]

  Tak po prawdzie Chrome (a tym samym Opera) były jednymi z pierwszych (jeśli nie pierwszymi) przeglądarkami, które odeszły od prefiksów na rzecz flag w ustawieniach. Przeglądarką, która zrobiła to jako ostatnia, było Safari, którego ewidentnie brakuje wśród przeglądarek korzystających z prefiksu -webkit-.

• Natomiast plus za polecenie Autoprefixera.

• […] przez aktywowanie styli […]

  Stylów! Forma styli nie istnieje w języku polskim!

• <div id="myElem">Lorem ipsum</div>
  <script>
  	setTimeout(function(){
  		myElem.classList.add('myClass');
  	}, 1000);
  </script>

  Tak, zgodnie ze specyfikacją HTML5, elementy posiadające atrybut [id] wyciekają do przestrzeni globalnej. Nie trzeba chyba zaznaczać, że tego typu zachowanie jest wynikiem wysokiej kompatybilności wstecznej nowej wersji HTML-a i nie powinno być wykorzystywane w nowych skryptach. Zwłaszcza, że mamy wiele lepszych metod (document.getElementById, document.querySelector itd.).

• Wielu czytelników na pewno miało styczność z modelami w CSS3 czy już w CSS2.1, natomiast może nie umieć ich wszystkich wymienić albo nie wie, czym one są.

  Faktycznie, nie wiem. Nigdy nie spotkałem się z określeniem „model” w kontekście CSS (a przynajmniej nie bez jakiegoś dookreślenia). Niemniej po przeczytaniu dalszej części podrozdziału, doszedłem do wniosku, że chodzi nie o „model” a „tryb układu” (ang. layout mode).

  Co więcej, w samym opisie znajdują się nieścisłości (np. model względny raczej powinien nazywać się liniowy, a w pozycyjnym brakuje wartości sticky) oraz brakuje wspomnienia o nowym Grid Layout.

• Różnica między wartościami flex a inline-flex jest żadna, jeżeli spojrzeć z perspektywy potomków elementu, który dla właściwości display ma taką wartość ustawioną.

  Brzmi to bardzo niezrozumiale – być może z powodu niefortunnej składni zdania.

• Wartość flex działa w odniesieniu do rodzeństwa tak samo jako wartość block, natomiast inline-flex – tak jak inline.

  Rzekłbym raczej, że inline-flex zachowuje się jak inline-block – ustawia się jako element liniowy, ale przy zachowaniu nadanych rozmiarów.

• W przykładowym layoucie stworzonym przy wykorzystaniu flexboksa pojawiają się elementy HTML o nazwach typu name, count. Są to nazwy niezgodne z oficjalnymi wymaganiami co do nazw niestandardowych elementów HTML (nazwa musi zawierać myślnik, więc poprawne były nazwy typu name-, -name, co-unt itd.). Warto na to zwrócić uwagę już teraz.

Rozdział 3. Wprowadzenie do ECMAScript 6

• Powstało już kilka wersji standardu i ECMAScript 6 jest jego najnowszą wersją […]

  No niestety już nie. W czerwcu 2016 roku została opublikowana wersja ECMAScript 2016 (aka 7). To jeszcze jeden dowód potwierdzający moje nieustanne biadolenie o szybkiej deaktualizacji literatury webdevowej.

• Bardzo duży plus za polecenie pozycji Axela Rauschmayera, Exploring ES6. To faktycznie jedna z najlepszych (jeśli nie najlepsza!) książek o ES6.
• Rozkład struktury obiektów to bardzo dziwne tłumaczenie terminu destructuring. Chociaż tutaj po części winny jest nieelastyczny język polski. Mimo wszystko dekonstrukcja brzmi jakoś lepiej, ale… Derrida w webdevie?
• Tak samo dziwnym tłumaczeniem jest termin funkcje strzałki w odniesieniu do arrow functions. Funkcje strzałkowe wydają się lepiej oddawać sens tej JS-owej konstrukcji.
• I tu pojawia się pewna niekonsekwencja, bo kolejny podrozdział traktuje o operatorze spread. Skoro tłumaczymy, to tłumaczmy wszystko!

• […] nowy operator „…” […]

  Akurat to jedno z tych bardzo nielicznych miejsc, gdzie wielokropek to błąd.

• Co więcej w tym podrozdziale pomylono z tym operatorem rest parameters, które są całkowicie osobną konstrukcją języka JS.

Rozdział 4. Web Components

• Przy opisie polifilla i różnicy między dynamicznym wczytywaniem potrzebnych plików a wczytaniem całej paczki naraz pada takie stwierdzenie:

  Najczęstszym wyborem będzie jednak wersja z jednym plikiem, gdyż pobranie wielu małych plików będzie wolniejsze od pobrania jednego dużego, stanowiącego połączenie wszystkich mniejszych.

  Otóż niekoniecznie. W przypadku wykorzystania protokołu HTTP/1.x to zdanie jest prawdziwe, natomiast przy wykorzystaniu HTTP/2 – nie bardzo. Można bowiem zastosować technikę server push i posłać wszystkie potrzebne polyfille równolegle do żądania samej strony. Tym sposobem w chwili wykonywania kodu JS, odpowiednie zasoby będą już dostępne. Co więcej, rozbicie tego na mniejsze pliki umożliwi lepsze zarządzanie cache’em.

• Są także wspomniane środowiska do tworzenia aplikacji desktopowych przy wykorzystaniu technologii sieciowych. Jak można przeczytać:

  Szkielety tego typu opierają się na określonym silniku HTML5 (najczęściej jest to WebKit).

  Niemniej później wymienione są Electron oraz NW.js, które są oparte na silniku Blink. Co prawda WebKit i Blink są oparte na tym samym kodzie, ale Blink jest obecnie rozwijany całkowicie niezależnie! Można to bardzo łatwo udowodnić, spoglądając na Can I Use? i porównując obsługiwane przez Safari (WebKit) i Chrome (Blink) technologie webowe.

  Tak po prawdzie niemal wszystkie tego typu projekty oparte są na Blinku, nie zaś WebKicie.

• Zainstaluje ona jako moduł Node.js wypełnienie webcomponents.js […]

  To, że coś znajdzie się w katalogu node_modules, nie czyni to z niego automatycznie modułu Node.js! Moduł Node.js musi przestrzegać składni modułów CJS – inaczej jest po prostu plikiem z kodem JS.

• Na dobry początek zapoznajmy się z przykładem, który prezentuje, w jaki sposób utworzyć najprostszy możliwy element Web Components:

  var XTest = document.registerElement("x-test"); // <1>
  var element = new XTest(); // <2>
  document.body.appendChild(element); // <3>

  I tu pojawia się podstawowy problem tej książki: opisuje starą wersję standardów wchodzących w skład Web Components. Obecnie definiowanie nowych niestandardowych elementów odbywa się poprzez customElements.define – niemniej wciąż nie jest to dostępne w przeglądarkach. Stary sposób przy wykorzystaniu document.registerElement jest dostępny na dobrą sprawę wyłącznie w Chrome, w którym wsparcie dla nowego sposobu wejdzie w najbliższym czasie. Tutaj warto od razu spojrzeć na datę zgłoszenia tego buga (marzec 2016!).

• Nie tylko sposób definiowania elementu został zmieniony, ale także tzw. zdarzenia cyklu życia, które nie dość, że zmieniły swoje nazwy, to także nazywają się obecnie „reakcjami niestandardowych elementów”.
• Przy HTML Imports wypada zaznaczyć, że nie uzyskano konsensusu i prawdopodobnie zostaną one całkowicie usunięte lub zaczną wykorzystywać moduły ES (które nie mają implementacji na chwilę obecną…).
• Cały opis Shadow DOM dotyczy starej wersji standardu, która została zaimplementowana wyłącznie w Chrome. Co więcej, nowa wersja standardu też jest już zaimplementowana w Chrome i będzie wkrótce zaimplementowana w innych przeglądarkach. Stara wersja Shadow DOM natomiast zostanie usunięta w Chrome w przyszłym roku. Żeby było śmieszniej, obydwie wersje standardu są niekompatybilne, np. nowa wersja standardu zabrania dodawania Shadow DOM do przycisków (co od wieków było sztandardowym przykładem – nawet i w tej książce!). Warto także zauważyć, że nowa wersja Shadow DOM została zatwierdzona do implementacji w Chrome w listopadzie 2015 roku.
• Opis sposobów stylowania Shadow DOM jest przestarzały. Co prawda jest informacja o możliwości usunięcia kombinatora /deep/ (co nastąpiło na rzecz kombinatora >>>), ale jest tu także opis nieistniejącego już pseudoelementu ::shadow.
• Cały opis elementu content jest w pełni przestarzały. Element ten, wraz z algorytmem dystrybucji węzłów, został usunięty i zastąpiony nowym algorytmem dystrybucji węzłów, opartym na elemencie slot.
• Powyższe uwagi sprawiają, że ocena kodu przykładowego komponentu traci sens.

Rozdział 5. MediaPlayer – przykładowa aplikacja

• Plus za opis procesu developmentu tego typu aplikacji.
• Kodu nie będę oceniał z powodu uwag powyżej. Niemniej zaprezentowany kod ma jeden bardzo poważny mankament: nie jest w żaden sposób przystosowany do potrzeb osób z niepełnosprawnością! Nie ma tutaj żadnych tekstowych treści alternatywnych lub odpowiednich atrybutów ze standardu ARIA. Pełna dostępność to jeden z elementów złotego standardu Web Components.

• Przez te kilka lat wiele może jeszcze się zmienić w przypadku obu standardów, część ich elementów składowych może nie przetrwać próby czasu, w standardzie może pojawić się coś zupełnie nowego. Mimo to ogólne koncepcje nadal będą obowiązywać.

  Zgodziłbym się, gdyby nowe wersje Shadow DOM i Custom Elements nie były de facto przepisaniem tych standardów. Ale takie jest ryzyko pisania książki o technologii, która dopiero w tym roku staje się stabilna.

Odpowiedź na moje pytanie postawione we wstępie brzmi – po raz kolejny – nie. Niestety, książka w chwili wydania była przestarzała i opisywała stare wersje standardów wchodzących w skład Web Components. To sprawia, że praktyczna wiedza w niej zawarta w dużej mierze nie przystaje do dzisiejszej rzeczywistości.

Za dużo opisu konkretnych technologii i narzędzi, za mało – ogólnych zasad wytwarzania komponentów i ogólnie modularyzacji. I właśnie ten fakt spowodował, że książka tak mocno się zdeaktualizowała. Czy gdyby była opublikowana jako artykuł/living e-book na GitHubie, to miałbym do niej te same zarzuty? Nie. Ale jest wydana w formie papierowej i tego typu zarzuty dotyczą niemal każdej książki o webdevie. I dobrze, bo to doskonale pokazuje jak szybko się on rozwija!