Skrypty NPMNr. 1 Nauka JavaScript obecnie jest trudna. Zwłaszcza, jeśli nie analizowałeś tego, co się działo przez ostatnie 3 lata. Ekosystem, liczba narzędzi ciągle rośnie. Ekosystem i narzędzia ciągle się zmieniają. Powoduje to brak zrozumienia, co właściwie ten ekosystem robi? Jakie problemy narzędzia rozwiązują, skoro ktoś stwierdził, że muszą one powstać.

Javascript już dawno nie jest językiem służącym do prostej obsługi elementów strony jak slidery.

Rok temu napisałem ten wpis, w którym nabijałem się trochę z tego, że Javascript i jego narzędzia stały się absurdalnie trudne i skomplikowane do tego stopnia, że same początki i pierwsze kroki wydają się wyprawami na księżyc.

Dla kogoś, kto zacząć pracę z Javascript albo nauczył się budować strony internetowe od podstaw, to wszystko to wydaje się żywym koszmarem. Sam, mimo iż mam już 6 lat doświadczenia skaczę po tutorialach i uczę się z nich fragmentów współczesnego Javascript. Problem polega na tym jednak, że te tutoriale często wymagają jakiejś wiedzy bazowej.

Dlatego zaczynając swoją przygodę z JavaScript czułem, że krążę w kółko tak długo, aż wszystko będzie miało sens jako całość.

Postanowiłem więc stworzyć ten wpis czytelniku byś ty nie miał takich problemów. Zacznijmy więc od podstaw i rozwiążmy problemy inkrementalnie tak, aby zrozumieć co my właściwie robimy.

WebpackNr. 2 Większość języków programowania posiada swój sposób na importowanie kodu z jednego pliku do drugiego. JavaScript oryginalnie nie posiadał takiej funkcjonalności i nie został stworzony z myślą, aby taka funkcjonalność była. JavaScript z założenia powinna być uruchamiana tylko z poziomu przeglądarki bez dostępu do plików z komputera użytkownika przeglądarki.

Dlatego jak do tej pory kod JavaScript był organizowany w wielu plikach. Każda funkcjonalność była współdzielona dzięki zmiennym globalnym.

BabelNr. 3 Transpiling to jest fachowe określenie procesu konwersji z jednego kodu na drugi. Oba kody jednak posługują się podobnym językiem. Jest to ważna część pracy współczesnego webdevelopera.

Po co istnieją narzędzia tłumaczące JavaScript na inny kod JavaScript? Problem leży w przeglądarkach oraz w różnych wersjach JavaScript.

Przeglądarki nie są w stanie gonić najnowszych wersji języka JavaScript i być zawsze na czasie. Z drugiej strony pewne nowe funkcjonalności w samym JavaScript, ale w wyższej wersji bardzo ułatwiają kodowanie.

Nie jest to nic nowego. Dla styli CSS mamy takie rozszerzenia jak LESS i Sass, które potrafią generować lepsze i bardziej złożone style CSS.

Dla JavaScript kiedyś najbardziej popularnym transpilatorem był CoffeScript. Dziś ludzie używają albo transpilatora Babel lub TypeScript. Istnieją też różnice pomiędzy nimi.

CoffeScript starał się ulepszyć JavaScript swoją własną składnią. Opcjonalne nawiasy, białe znaki i tak dalej.

Babel nie tworzy nowej składni dla JavaScript. Kompiluje najnowszy kod JavaScript do starszej wersji, która jest rozumiana przez wszystkie przeglądarki.

NPM TaskNr. 4 Teraz gdy transkompilujemy kod JavaScript przy użyciu Babel  oraz wprowadziliśmy modułowość do naszej aplikacji JavaScript przy użyciu Webpack rodzi się to, co nam jeszcze zostało?

Mam jeszcze mały problem z usystematyzowaniem tego wszystkiego do jednego polecenia. Osoba, która pobierze naszą aplikację przykładowo może nie wiedzieć, że musi uruchomić polecenie webpack.

Dlatego w środowiskach pracy JavaScript powstała idea by uruchamiać to wszystko jako zadania.

W naszej aplikacji mamy proces budujący naszą aplikację. Chcielibyśmy by ten proces budujący wykonywał nasze polecenie webpack oraz inne polecenia, które by zminimalizowały kod, zoptymalizowały zdjęcia, przetłumaczyły pliki SASS na CSS i inne.

To, że obecnie w naszej aplikacji ich nie ma wcale nie znaczy, że one nie wystąpią.