Wideokursy #1: Kurs JS (i CSS) Mirosława Zelenta

Obecnie coraz większą popularnością cieszą się wszelkiej maści wideokursy, dlatego też postanowiłem się bliżej przyjrzeć jednemu z nich. Mój wybór padł na kurs JS Mirosława Zelenta.

Odcinek 1., Skrypty po stronie klienta – pierwszy projekt

• Tutaj moje zastrzeżenie pojawia się już w przypadku tytułu. Obecnie JS nie jest językiem browserowym. To język ogólnego użytku, który coraz większą popularność zyskuje po stronie serwera (node.js/io.js).
• Z tego też powodu kontrastowanie PHP i JS z początku odcinka nie ma obecnie racji bytu.
• Jeśli natomiast chodzi o to, że kod JS jest interpretowany przez przeglądarkę, to tutaj też można by polemizować – praktycznie każdy nowoczesny silnik JS to kompilator JIT.
• Nie zgodzę się, że JS jest dedykowany tworzeniu animacji i tego typu efektów. Do tego jest dedykowane DOM API, którego najpopularniejszą – ale niejedyną – implementacją jest ta w JS. JS jest językiem ogólnego użytku.
• Natomiast zgadzam się, że JS to so much fun.
• Nie wiem czy wykorzystywanie logo stylizowanego na logo HTML5 jest dobre. Osobiście pokazałbym (nie)oficjalne logo.
• Nie, skrypty nie powinny być w head.
• Atrybut [type] dla script jest niepotrzebny… od wieków. Rozumie to „nawet IE”, które nota bene ma obecnie najlepsze wsparcie dla ES6.
• Czy ja wiem czy pisanie JS po polsku jest dobre? Pisałbym po angielsku. Natomiast polskie ogonki w nazwach zmiennych są dozwolone (identyfikatory w UTF-8 są obsługiwane od dawna).
• Przed ES6 mówienie o klasach w JS to jednak pewne nadużycie semantyczne i warto to zaznaczyć.
• Natomiast wytłumaczenie działania obiektów jest niesamowicie intuicyjne. Niemniej metody nazywałbym metodami, nie funkcjami.
• Informacje o końcu linii i średnikach w JS są niestety nieprawdziwe. Te rzeczy są zawiadywane przez tzw. Automatic Semicolon Insertion (automatyczne wstawianie średników). Owszem, nowa linia jest jednym z wyznaczników dla ASI, ale nie jedynym.
• Nie pokazywałbym dokumentacji W3Schools, a Mozilla Developer Network (wersja angielska, bo polskiej trochę brakuje). To wciąż najlepsza dokumentacja JS.
• Nie podoba mi się także tworzenie zmiennych globalnych. Od razu wprowadziłbym IIFE i pojęcie scope’u. To obecnie podstawy pisania dobrego kodu JS.
• Co do określania typów zmiennych w JS – już niedługo… Patrz: 'use stricter'.
• Nie widzę sensu dzielenia kodu JS na dwie części: jedną w head,a drugą w body.
• Szkoda, że tworzony zegarek nie jest PE. Z powodzeniem mógłby być generowany z aktualnym czasem pobranym z serwera, a jedynie uaktualniany przez JS.
• Fajna data po polsku… Szkoda, że od pewnego czasu ES dochrapało się internacjonalizacji.
• Bardzo fajne wyjaśnienie pojęcia funkcji. Chociaż przy istnieniu tzw. Web Workers czasami może być ciut mylące.
• Nie podaje się stringów jako 1. parametru dla setTimeout! Podaje się uchwyt do funkcji – nie wywołujmy sobie niepotrzebnie eval.
• Matematyczna dygresja o przedrostkach to ciekawy dodatek.
• Nie, nie ma zdarzenia onclick – jest zdarzenie click.
• Atrybut [onload] to zło. Nie mieszajmy warstw aplikacji! JS to JS, HTML to HTML.
• Zewnętrzne pliki JS nie powinny być praktycznie nigdy załączane w head (pomijając całkowicie asynchroniczne skrypty statystyk).

Odcinek 2., Mechanika działania skrypów: uchwyty, funkcje, zdarzenia

• Nie, nazwy zdarzeń w DOM nie mają w nazwach on…, a document.write już się nie używa.
• Dobrze, że strona HTML dostała określenie języka.
• input[type=submit] bez formularza jest całkowicie bezsensowne. Jak już robimy taki mechanizm, zróbmy to w formularzu, z fallbackiem z super prostym skryptem w PHP (albo z dokładnie takim samym kodem, jeśli korzystamy z node.js/io.js). A jak nie chcemy formularza – input[type=button] albo po prostu button.
• Jeśli robimy formularz obsługujący liczby, to zróbmy sobie pole [type=number]
• Co do łapania elementów, niekoniecznie musimy posługiwać się [id]. Wszak silink CSS jest już dostępny w JS przez document.querySelector/document.querySelectorAll.
• Jest pewna różnica między funkcjami wbudowanymi (metodami globalnego obiektu), a metodami document.
• Książkowy antyprzykład obsługi formularza.
• Przykład użycia document.write doskonale pokazuje czemu się go nie używa.
• if raczej jest instrukcją, nie funkcją sensu stricto.
• Podoba mi się zwrócenie uwagi, że metoda innerHTML to metoda „na chłopski rozum”, a nie jako pojęcie z OOP.
• Przed działaniami matematycznymi na wartościach pobranych z pól formularza, warto przepuścić je przez parseInt. I to rozwiązuje większość problemów z tym kodem (chyba podałem rozwiązanie na zadania zadane widzom, ups…).
• Zmienne wykorzystywane w pętli muszą być deklarowane przez słowo kluczowe var – w innym wypadku tworzymy tzw. implied global (zmienna wypływa do globalnego scope), co jest zabronione w ES5 strict mode. Jeśli natomiast piszemy pod nowsze przeglądarki, tutaj lepiej jest wykorzystać nowe słowo kluczowe let.
• Zamiast napis = napis + cos lepiej skorzystać z operatora +=.
• Nie, aktualny numer slajdu nie powinien być zmienną globalną! Slider powinien być definiowany wewnątrz własnego scope (wytworzonego np. przez moduł UMD czy IIFE).
• Szkoda, że slider nie jest PE. Z powodzeniem slajdy można włożyć w listę (bo slider to przecież lista obrazków), a jedynie ich zmienianie zakodować w JS. Nie ma sensu generować w JS kodu HTML, jeśli kod ten niesie treść dla wszystkich.
• Atrybuty w HTML bynajmniej nie muszą być otaczane cudzysłowami. Jedynie w niewielu przypadkach istnieje taki wymóg.
• Czemu obrazki nie mają [alt]? To podstawowy błąd dostępności!
• Czemu do animacji przejścia jest wykorzystywane jQuery? Klasyczna armata na muchę. Tutaj można praktycznie w całości sprawę przerzucić na CSS, przy pomocy transition w JS pozostawiając jedynie kwestię podmiany klasy elementu w odpowiedniej chwili.
• Zamiast bezsensownego setTimeout dla $.fn.fadeOut, wystarczy wykorzystać callback (tradycyjną metodę obsługi asynchronicznego kodu!).
• Nawigacja dla slidera to lista linków/przycisków, nie span! Jeśli zrobimy to na linkach, można slider wykonać bez JS, operując na :target z CSS3.
• Zamiast ręcznie operować na zmiennej numer, funkcja zmienslajd powinna brać odpowiedni parametr.

Oprócz kursu JS, Mirosław Zelent tworzy także kurs HTML czy CSS (pomijam tutaj kursy C++ i innych tego typu języków). Jako bonus przyjrzę się drugiemu odcinkowi kursu CSS.

Bonus: Stylizacja szablonu strony. Właściwości CSS w akcji

• Klasy w CSS elementami zaawansowanymi elementami programowania? To raczej nie te klasy… Niemniej koncept OOCSS nie jest głupi.
• W kodzie HTML nie powinno być meta[http-equiv="X-UA-Compatible"], bo to nagłówek HTTP i tym być powinien.
• Akurat w przypadku HTML5 struktury strony wręcz nie powinno się tworzyć na divach, bo obecnie mamy dostępne różne elementy strukturalne.
• Czemu floatowanie rzeczy jest omówione w… 2. odcinku kursu HTML? Nie mieszajmy warstw!
• #container w 95% przypadków jest całkowicie niepotrzebny (tak, jak tutaj) – mamy bowiem html, body.
• Do stylowania nie powinno używać się [id], a klasy.
• #logo to główny nagłówek strony.
• Menu winno być na liście, nie wstawione od tak do div#menu.
• Cytat z Linusa to… cytat, zatem powinien być otoczony q lub blockquote.
• #topbar doskonale nadaje się na sekcję z nagłówkiem.
• Menu boczne na br? Nawet jeśli to kurs CSS, to stylować należy jedynie poprawną strukturę strony. Prezentacja jest jedynie sposobem jej wyświetlania – nie służy do definiowania znaczenia treści.
• Czemu nigdzie nie ma akapitów, które są symulowane przez podwójne br? Dbajmy o semantyczność HTML-a!
• Akurat na stronach napisanych w Unicode, encje można zamienić po prostu na odpowiednie znaki (zwłaszcza, że na klawiaturze linuksowej one są!).
• Tło dla body niekoniecznie jest tłem dla całego dokumentu. Można to obalić dodając tło dla html.
• Jeśli możemy czegoś nie pisać, to tego nie piszmy vs. opcjonalne link[type]. Jeśli możemy czegoś nie pisać, to tego nie piszmy!
• W CSS-ie różnica między [id] a [class] jest związana ze specyficznością selektorów – tylko i wyłącznie! Unikatowość [id] jest wymagana na poziomie DOM – nie CSS. Dlatego w CSS lepiej używać jedynie klas do stylowania (tak, jak robi to np. BEM, dodatkowo spłaszczając zależności między elementami do całkowicie niezbędnego minimum).
• Jakoś na moim Ubuntu Times New Roman nie był domyślnie instalowany…
• Google Fonts robią takie same spadki w tzw. perceived performance, jak normalne ładowanie swoich czcionek, dlatego kod CSS od Google lekko mówiąc ssie i należy go zoptymalizować. Warto także zwrócić uwagę, że kod HTML z Google Fonts jest niepoprawny składniowo („nieucięknięta” encja).
• Nie, background nie jest dziedziczone. Po prostu domyślnie elementy HTML nie mają żadnego tła… więc po prostu są przezroczyste.
• Nie, nazwa rodzajowa czcionki w font-family nie określa rodzaju poprzedzającej ją czcionki. To po prostu fallback – jeśli nie ma czcionki Lato, system wykorzysta pierwszą lepszą czcionką nieszeryfową.
• padding raczej bym wyjaśniał jako margines wewnętrzny, nie wypełnienie.
• Przyciski w menu jako div, któremu w CSS dorabiamy łapki? Nie piszmy kodu HTML pod CSS, bo to bez sensu – nawet jeśli to tylko przykład stylowania.
• Nie do końca zgodzę się z twierdzeniem, że kolejność regułek w pliku CSS nie ma znaczenia. Owszem, w tym wypadku nie ma, ale nie zawsze tak to działa.
• Pusty div ze stylem inline, żeby sclearować? Istnieją o wiele lepsze metody.
• Rameczkę z prawej dla opcji w menu lepiej dać dla .option + .option – wówczas będzie tylko między opcjami, bez rameczki na samym końcu.
• Gdyby te linki w menu były linkami, to style dla :hover najlepiej także przypisać dla :focus.
• [id] stricte prezentacyjnie raczej winny być unikane. [id] oznaczają funkcję danego elementu, jego miejsce w strukturze semantycznej strony (nie prezentacyjnej).
• Czemu Tux nie ma [alt]? Akurat w tym wypadku powinien być on pusty (bo to tylko ładny ornament).
• IMO operowanie obecnie na content box jest przeżytkiem. Zwłaszcza, że border box działa de facto wszędzie.
• Czemu .title miałby się komuś pomylić z title? No i czemu nagłówki nie są nagłówkami?
• Mały odstęp przy pomocy starej sztuczki w postaci div ze stylem inline? W jednym się muszę zgodzić – to naprawdę stara sztuczka, którą lepiej zastąpić marginesami.
• .dottedline zamiast pustym div może być ładnym i zgrabnym boder-bottom dla nagłówków, ich ::after lub lekko zapomnianym hr.
• Bardzo mi się podoba końcowy fragment o podświadomym odbieraniu layouta – fajna wartość dodana. A wytłumaczenie terminu interfejs – po prostu bezcenne!
• Trzeba przyznać: strona wygląda bardzo przyjemnie. Niemniej moje serce krwawi, gdy patrzę na kod HTML. Nie zapominajmy, że prezentacja jest tylko nakładką na semantykę HTML-a – w innym wypadku traci swój sens!

Mam dylemat. Z jednej strony mam spore zastrzeżenia co do strony merytorycznej kursu (ale równocześnie i tak muszę zauważyć, że jak dotąd to najlepszy wideokurs o webdevie jaki widziałem) i wprowadziłbym tutaj poprawki. Z drugiej strony – tego się niesamowicie dobrze słucha. Brak wszechobecnego Eeeee… i innych niepotrzebnych przerywników, doskonałe zgranie głosu z elementami wizualnymi i widoczny solidny plan każdego odcinka kursu. Gdy będę się w końcu brał porządniej za naukę C++ (mam to w planach), to na pewno rozważę kurs C++ tego autora – choćby dlatego, że wiem, że wysłucham go do końca bez znudzenia. Dlatego ostateczną oceną w tym wypadku będzie „fifty-fifty”: niedociągnięcia merytoryczne zawsze można naprawić, za to sam styl prowadzenia jest naprawdę świetny.

PS A rozpoczęcie wiosny będziemy świętować premierą Auditra 3.0! Ale nie oczekujcie czegoś wielkiego… To będzie raczej skromny projekt, przy którym już kilka razy osiwiałem i spaliłem kod (stąd wersja 3.0).