Książki

Recenzja: Tajemnice JavaScriptu. Podręcznik ninja

Okładka książki

JavaScript to język programowania, który wymaga od programisty szerokiej wiedzy i dokładności. Chwila nieuwagi może spowodować poważne problemy, trudne do wykrycia. Jak sobie radzić w tym wymagającym środowisku? Jak zwinnie poruszać się pomiędzy zastawionymi pułapkami?

Źródło: Helion.pl

Tytuł + nazwiska nadają tej książce status pożądanej przez każdego kodera JS. Kto bowiem nie chciałby stać się wojownikiem ninja, pod okiem takiego mistrza, jak John Resig?

Tłumaczenie

Zacznę nietypowo, bo to główna rzecz, jaka rzuca się w oczy: tłumaczenie jest po prostu tragiczne. Część zdań jest napisana całkowicie niezrozumiale. Nie to jest jednak głównym mankamentem. Prawdziwym problemem są strasznie dziwne polskie tłumaczenia niektórych ogólnie przyjętych pojęć. Nie wiem kiedy w Helionie zrodziła się myśl, żeby każdy termin angielski tłumaczyć na polski odpowiednik. Niemniej efekty takich działań są czasami komiczne. Mamy zatem „funkcje bezpośrednie” zamiast IIFE (który to skrót występuje wszędzie), mamy „pakiety testów” zamiast… frameworków testowych czy też… „procesy robocze standardu HTML5” (oczywiście chodzi o standard Web Workers, który nawet nie jest częścią specyfikacji HTML5). Ale już prawdziwym mistrzostwem jest „niepozorny kod JS” (który nagle w innym miejscu książki staje się „dyskretnym kodem JS”). O czym mowa? O technice unobtrusive JS.

Oczywiście nigdzie przy polskich terminach nie ma podanego ich odpowiednika angielskiego, więc jeśli ktoś nie zna pojęć związanych z programowaniem w JS, to po przeczytaniu tej książki… dalej ich nie będzie znał. Za to będzie rozróżniał dziwne polskie odpowiedniki, których nikt po prostu nie używa. Moim zdaniem w książce powinna zostać użyta konwencja odwrotna: termin angielski (tłumaczenie na polski). I to winno być jedyne miejsce wystąpienia polskiego terminu. Raczej powinno się zapoznawać ludzi z używanymi zwrotami a nie sztucznie wykreowanymi na potrzeby książki. Byłem w stanie rozpoznać o co chodzi tylko i wyłącznie dlatego, że te pojęcia znam i kod na nie wskazywał… Niemniej i tak miałem problem z rozdziałem „Analizowanie kodu w środowisku wykonawczym”, który traktował o eval. I nie uwierzę, że w oryginale było analizowanie a nie interpretacja. I mam rację – w oryginale jest: „evaluation”, co nie ma prawa zostać przetłumaczone jako analizowanie…

I ostatni kwiatek, którego po prostu nie można pominąć: Java ma się do JS jak… szynka do hamburgera. Cóż, w angielskim ma to sens (ham ↔ hamburger), ale w polskim – absolutnie nie. Jest tyle innych takich par w naszym języku (kot ↔ kotara, koń ↔ koniak, blacha ↔ blachara…) – całkowicie nie rozumiem decyzji z pozostawieniem tłumaczenia dosłownego.

Tłumaczenie po prostu zabiło tę książkę. A szkoda.

Zawartość

Mimo wszystko tłumaczenie nie jest głównym grzechem tej książki. Pod względem merytorycznym również mocno odstaje od poziomu, jaki deklarują nazwiska autorów.

Książka podzielona jest na 4 części:

  • Przygotowania do treningu
  • Trening ucznia
  • Trening wojownika
  • Trening mistrza

W przygotowaniach de facto jedyne, czym się zajmujemy, to tworzeniem własnego „pakietu testów” (czyli – jak już wspominałem – frameworka testowego). Tworzone jest m.in. grupowanie testów. Niestety, w całej reszcie książki jedyną rzeczą, którą z tego wyniesiemy, jest funkcja assert, która będzie równocześnie służyła za… funkcję logującą (cóż, to się nazywa reużywalność, prawda?). W tej części książki dowiadujemy się także, że co prawda JS nie działa już jedynie w przeglądarkach (jedyne miejsce, gdzie wspomniana jest nazwa node.js), jednak ta książka i tak jest JS browserowemu poświęcona. Tym samym można skreślić na starcie „JavaScriptu” z tytułu, bo to książka o dostosowywaniu kodu do IE (niestety).

Część druga książki to jedyna w miarę sensowna rzecz, jaka tutaj jest. Ale i tak nie do końca. Po zapoznaniu się z nią można dojść do błędnego wniosku, że JS jest językiem funkcyjnym, z na chamca dodaną wybrakowaną obiektowością (lol, nie ma klas) a głównym terminem w JS jest pojęcie „funkcja to obiekt pierwszej klasy”. Funkcjom poświęcono aż 3 rozdziały, lecz i tak zabrakło miejsca na to, żeby dokładnie wyjaśnić hoisting czy magiczne słówko this. O Function.prototype.bind można w ogóle zapomnieć a dlaczego – to o tym później. Obiektom poświęcono natomiast tylko jeden rozdział, gdzie nie do końca wyjaśniono całą rzecz z prototypami i nawet nie pokuszono się o wytłumaczenie innego patternu konstruktorów niźli jedynie przez słówko new. Jedyna fajna rzecz z obiektówki, którą pokazano, to metoda tworzenia subklas z odwołaniem do rodzica. Ponadto przy literałach liczbowych i wywoływaniu ich metod podano nie do końca prawidłowe informacje (np nie podano w ogóle 5..metoda). Ewidentnie widać, że autorzy traktują po macoszemu obiektowe możliwości JS, skupiając się w pełni na jego funkcyjnej stronie.

Co jeszcze w tej części? Pean na cześć wyrażeń regularnych. Owszem, są bardzo potrzebne, niemniej w rozdziale im poświęconym nie pokazano zbyt wiele przykładów wskazujących na ich nieodzowność w arsenale każdego JS ninja (i nie, trim nie jest dobrym przykładem). Na sam koniec zapoznajemy się z licznikami czasu, gdzie równocześnie bliżej wytłumaczone jest pojęcie event loop. Szkoda, że o Web Workers jest jedynie króciutka wzmianka i nic więcej (a o setImmediate nawet tego nie ma).

Trzecia część to już niestety zbiór quirków w przeglądarkach oraz przestarzałych praktyk. Zaczynamy od rozdziału o „analizowaniu” kodu i poznajemy eval, którego później używamy do… parsowania JSON. Tak, autorzy zdają sobie sprawę z istnienia JSON, ale przecież on nie działa wszędzie i należy znać eval. Aż spojrzałem z niedowierzaniem na datę powstania książki – 2013. Naprawdę? JSON w JS jest od co najmniej 2012 a jedyne przeglądarki, które tego nie mają to naprawdę prehistoryczne IE (IE 8 już wspiera!). W kolejnym rozdziale jest jeszcze gorzej: prezentowana jest instrukcja with. Naprawdę ta instrukcja potrzebuje aż osobnego rozdziału i traktowania na tym samym poziomie, co programowanie obiektowe? Najlepsze jest, że przez cały rozdział nieustannie jest powtarzane, że tego mechanizmu nie powinno się używać… więc po co marnuje się czas – mój na czytanie, autorów na pisanie? Natomiast później po prostu dowiadujemy się czym jest feature detection oraz uczymy się używać element.style. A to już niestety nie jest JS.

Ostatnią część – czyli trening mistrza – autorzy mogli sobie po prostu darować. Nie ma nic wspólnego z JS a z pisaniem owijaczy DOM-owych dla naprawdę starych IE (naprawdę w 2013 roku należy napisać a w roku 2014 wydać książkę traktującą o błędach w IE9-?). Nie dość, że nie ma to nic wspólnego z JS, to jeszcze jest po prostu przepisywaniem jQuery. A jeśli ktoś jest mistrzem JS (lub do tego miana pretenduje), to kod jQuery czyta sobie na deser.

Tak, ¾ książki o tajemnicach JS traktuje o błędach w implementacji modelu DOM. I nie w nowoczesnych przeglądarkach, ale IE w wersjach 6, 7 i 8. Tak, to książka z 2013 roku. Zamiast mieć fantastyczny rozdział o własnej implementacji systemu eventowego, z podglądaniem takich rozwiązań, jak EventEmitter w node.js, skupiamy się na patchowaniu modelu zdarzeń DOM, żeby zapobiec wyciekom pamięci i innym dziwnym rzeczom w przeglądarce MS. To nie jest trening ninja – to nauka jazdy czołgiem. A co w tym wszystkim jest najśmieszniejsze? Że na samym początku autorzy sami stwierdzają, że DOM to zupełnie inna bestia niż JS i nie należy winić języka za niedoskonałość tego (jednego z najgorzej zaprojektowanych w historii) API. Gdzieś koło 11. rozdziału jakby o tym stwierdzeniu całkowicie zapominali i DOM staje się integralną częścią JS w przeglądarce.

I w sumie jedyne, co autorów interesuje, to obsługa IE i całej reszty. Standard ES5 jakby w ogóle dla nich nie istniał. Można spotkać niestandardowe implementacje String.prototype.trim czy metody forEach (dziwnym trafem jest de facto przekopiowana z jQuery). Kiedy natomiast już pojawiają się informacje o nowych możliwościach, to zamiast odnośnika do standardu ES, jesteśmy raczeni informacjami o wersjach JS, typu JS 1.6, 1.85… To wyłącznie numeracja Mozilli, nie mająca nic wspólnego z prawdziwym, standardowym JS. Co więcej – każdej nowości jest poświęcona raptem krótka notatka (no bo przecież nie można ich używać – ninja tak nie robią!). Zamiast uczyć prawdziwego, czystego JSa, ta książka zachęca do tworzenia obejść, hacków i wszelkiej maści polyfillów w celu wspierania starych przeglądarek (Safari 3, Opera 10, Firefox 3, IE9-…). Ba, większość przykładów z książki nie ma prawa zadziałać w strict mode (mimo że autorzy go znają i to bardzo dobrze!) z powodu niewłaściwego używania this (w strict mode jeśli this jest poza kontekstem obiektu, to jest undefined a nie window) czy też arguments.callee.

Praktycznie w ogóle nie jest poruszony temat asynchroniczności JS. Jedynie liczniki czasu coś do tego tematu wnoszą. Niestety o requestAnimationFrame czy setImmediate nie ma ani słowa. Nie wspominając już o promises czy generatorach. A obecnie wszystkie API w JS są na obiecankach lub eventowe. Co więcej – zdarzenia niestandardowe w książce są… obsługiwane niestandardowo. Wypadałoby chociaż wspomnieć o Custom Event z DOM. Całkowicie zignorowano także temat modułów, co dzisiaj jest całkowitą podstawą. No i JS ninja kojarzy mi się z wykorzystaniem takich technik, jak object pooling i unikanie garbage collectora (i wszystkie inne rzeczy dotyczące zarządzania pamięcią). Tutaj tego nie ma…

Ocena

Jestem bardzo, ale to bardzo zawiedziony. Po tytule spodziewałem się, że wreszcie powstała porządna książka o prawdziwym JS. Okazała się jednak kolejną książką o dziwactwach IE. Z całej tej książki wyniosłem jedną, jedyną rzecz – \f jest znakiem nowej strony… Trochę mało, jak na książkę o tajemnicach JS (no i to nawet JS nie jest!).

We wstępie jest napisane, że to książka nie dla początkujących. To fakt – za mało tłumaczenia pewnych rzeczy. Jednak dla bardziej zaznajomionych z JS również nie – oni to po prostu wiedzą i robią to intuicyjnie. Ta książka po prostu nie ma targetu: dla uczących się JS jest za trudna (a tłumaczenie tylko ją dobija) a dla znających JS nie jest niczym nowym. Dodatkowo bardzo dużo w niej braków merytorycznych i zbyt dużo DOM (to „Tajemnice DOM” a nie JS…). Dlatego nie jestem w stanie dać tej książce więcej niźli 3/10.

Tagi:helionJavaScriptnie tak dobrarecenzja

komentarzy 7

  • Awatar
    Piotr Nalepa

    14 września 2014 22:02

    Tego można się było spodziewać po polskim tłumaczeniu. Mam angielską wersję i zdecydowanie więcej można z niej wynieść niż z jej polskiej wersji. Nie wiem czy zwróciłeś uwagę, ale oryginał pochodzi z 2012 roku, chyba z początku (nie dam głowy). Wtedy promises, a tym bardziej ES6 były dopiero mrzonką, być może eksperymentalnie stosowaną w demach.
    Wracając do tłumaczenia książki, to chyba po raz kolejny można się przekonać, że Helion nie daje książek do tłumaczenia znawcom tematu, tylko tłumaczom angielskiego, którzy z programowaniem są na bakier i stąd takie „kwiatki” tłumaczeniowe, o których wspomniałeś wcześniej.

    Odpowiedz
    • Awatar
      Comandeer

      14 września 2014 22:17

      >Nie wiem czy zwróciłeś uwagę, ale oryginał pochodzi z 2012 roku, chyba z początku (nie dam głowy).
      Hm, patrzyłem na dane w polskiej książce i tam przy oryginalnym tytule był rok 2013. Jeśli faktycznie książka jest z 2012 i to z początku, to można jedynie pogratulować Helionowi niekompetencji ;) Mówiłem to już przy recenzji książki o node.js, powtórzę więc i tutaj: 2 lata w świecie JS to jak 20 lat w „normalnym” świecie. To tłumaczyłoby też fakt czemu wciąż jest to książka głównie o browserowym JS. Niemniej – książka z 2012 w obecnym momencie jest już mało przydatna, niestety.

      Odpowiedz
      • Awatar
        Piotr Nalepa

        14 września 2014 22:39

        Powiem tak, do angielskiej wersji sobie co jakiś czas wracam. Przyjemnie się czyta i czasem się przydaje na mały reset toku myślenia. Książka jest też dobra pod tym kątem, że już wskazuje pierwsze kroki jakie trzeba podejmować przy pisaniu testów jednostkowych (a że jest to tylko assert, to w zasadzie nic nie szkodzi – do mocków się dojdzie z czasem). Dobrze jest mieć jakikolwiek punkt zaczepienia.

        Odpowiedz
      • Awatar
        Comandeer

        14 września 2014 22:44

        Nie powiem – niektóre części są dobre. Podobało mi się zwłaszcza pokazanie JS jako języka funkcyjnego… inna rzecz, że trochę za daleko w to poszli ;)

        Co do testów jednostkowych – fakt, mało kto o nich mówi. Ale jak już mówią, to niestety zwykle w tak ograniczony sposób. A szkoda.

        Odpowiedz
  • Awatar
    Michał Załęcki

    14 września 2014 22:17

    JavaScript i obiektowość, a PHP5/Java i obiektowość. Jeżeli autor przyjął określenie „poziomu obiektowości” na podstawie odniesienia do innych języków programowania wykorzystywanych w szeroko pojętej sieci to nie ma się co dziwić, JS wypada przy w/w dość ubogo.

    > setImmediate nawet tego nie ma
    Z MDN: This method is not expected to become standard, and is only implemented
    by recent builds of Internet Explorer and Node.js 0.10+. It meets
    resistance both from Geco (Firefox) and Webkit (Google/Apple).

    Biorąc to pod uwagę + to co we wstępie książki to nie ma się co dziwić.

    > Aż spojrzałem z niedowierzaniem na datę powstania książki – 2013
    > Tak, to książka z 2013 roku.
    Czytałeś wstęp? O eval też jest tam co nieco.

    Znając kontekst w jakim książka jest napisana (kontekst we wstępie) inaczej się ją odbiera, na pewno ja ją inaczej odebrałem. Nie od dziś wiadomo, że jak książka powstaje kilka lat (z czym się nikt nie kryje, tylko trzeba doczytać) to nie ma co w niej szukać jakichś „killer featurów”.

    Znając dorobek zawodowy autora można się domyśleć, że to nad czym pracował musiało być bardziej kompatybilne wstecz niż nowoczesne. Jest to pewna interpretacja autora „bycia ninja”, przeczytałem książkę i nie dałbym mniej niż 6/10 ze względu na tłumaczenie i wątpliwe praktyczne zastosowanie niemałej części poruszonych tematów.

    Odpowiedz
    • Awatar
      Comandeer

      14 września 2014 22:35

      >Jeżeli autor przyjął określenie „poziomu obiektowości” na podstawie odniesienia do innych języków programowania wykorzystywanych szeroko pojętej sieci to nie ma się co dziwić, JS wypada przy w/w dość ubogo.
      Cóż, JS traci przy porównaniu tylko dlatego, że porównujemy klasy z prototypami. Jeśliby wejść w to głębiej, to to nie jest aż tak widoczne. Większość elementów obiektówki z Javy można z powodzeniem przełożyć na JS. Niemniej sam pomysł porównywania JS do innych języków obiektowych (a zwłaszcza do Javy) jest IMO śmieszny.

      >Z MDN: This method is not expected to become standard, and is only implemented by recent builds of Internet Explorer and Node.js 0.10+. It meets resistance both from Geco (Firefox) and Webkit (Google/Apple).
      A co mają napisać? ;) Bawi mnie taka przepychanka: MS pokazuje niezłą speckę a oni odrzucają, bo… łatwo spolyfillować. To czemu tego nie powiedzieli przy element.classList? Problem polega na tym, że to zgłosiło MS i tylko na tym. To, co ostatnio uprawia Mozilla, to czysta PR-owa hipokryzja. A szkoda. No a o stosunkach między MS i Google czy MS i Apple to można kilka opasłych tomów napisać ;)
      Całe szczęście, że o tym, jakie technologie są używane, ostatecznie decydują developerzy a nie śmieszne firemki, kradnące se zabawki w piaskownicy. A polyfille dla liska i chrome działają i tak szybciej niźli natywny mechanizm w IE ;)
      setImmediate jest de facto jedynym rozsądnym rozwiązaniem dla wymuszania działań przy każdym „ticku” i mam nadzieję, że nie uwalą tego tylko ze względu na to, że mogą.

      >Znając kontekst w jakim książka jest napisana (kontekst we wstępie) inaczej się ją odbiera, na pewno ja ją inaczej odebrałem.
      Ja chyba za głęboko tkwię w JS i od dawna nie traktuję go jako język browserowy. Dlatego ten kontekst mnie drażni. Nie przystoi do dzisiejszej rzeczywistości, gdzie JS ma coraz mniej styczności z DOM.

      >Nie od dziś wiadomo, że jak książka powstaje kilka lat (z czym się nikt nie kryje, tylko trzeba doczytać) to nie ma co w niej szukać jakichś „killer featurów”.
      Problem tej książki polega na tym, że pisana kilka lat, wyszła w przełomowym momencie dla środowiska JS. Teraz większość zawartych w niej tez jest przestarzała. Nie pomaga temu także fakt, że Helion wydał ją jakieś 2 lata po premierze.

      >Znając dorobek zawodowy autora można się domyśleć, że to nad czym pracował musiało być bardziej kompatybilne wstecz niż nowoczesne.
      Ale powiedzmy sobie wprost: Resig dba głównie o kompatybilność DOM a nie JS jako JS. I tutaj jest zgrzyt między tytułem i deklarowaniem opisu fundamentalnych zasad rządzących JS a tym, co dostajemy w rzeczywistości. DOM to nie JS, czego doskonałym dowodem jest implementacja DOM w PHP (inna rzecz, że pamięta ona czasy prehistoryczne i dodatkowo jest oparta na parsowaniu XML-a ;)).

      Odpowiedz

Zostaw odpowiedź