Co to jest SystemJS?

Dawno nic nie było z serii Co to Jest? pora więc sekcję ciutkę ożywić :) Więc porozmawiamy sobie o SystemJS który będzie wstępem do kolejnego Co to Jest.

W skrócie SystmJS to dynamiczne uniwersalne narzędzie do wczytywania modułów z możliwością rozszerzenia go o nową funkcjonalność – po polsku fatalnie to brzmi, universal dynamic module loader (lepiej!). Dużo to nie mówi? Mnie prawie nic nie mówiło :) Ok rozumiem, module loader ale kolejny po co?

A no właśnie diabeł tkwi w szczegółach. Rozbijmy to nasze piękne zdanie na czynniki pierwsze.

Uniwersalny

To znaczy taki module loader którego nie interesuje rodzaj modułu który ładujemy. Pamiętacie RequireJS? To właśnie jest typ modułu. Odpowiednia specyfikacja, która mówi jak moduł ma zostać zbudowany, by potem móc zostać załadowany. W SystemJS możemy wykorzystać jeden dostępnych rodzajów modułów:

• esm – najnowszy standard jeszcze nie doprecyzowany, aktualnie w draft dotyczący ES6 a teraz zwący się ECMAScript Module.
• cjs – Nic innego jak CommonJS (to o czym wspomniałem przy RequireJS i ten który jest wykorzystywany przez node.js).
• AMD – to samo co CommonJS, prawie (to prawie robi wielką róźnicę). Po prostu Asynchronous module definition bazuje na CommonJS (nie prawda, nie bazuje, nie wiem czemu to tak napisałem).
• global – system modułów, który ładuje moduł tak jakby był on załadowany za pomocą <script> tag. Z tą różnicą iż kilka fajnych bajerów (dostępnych w opcjach konfiguracyjnych) jest dostępnych: ładowanie zależności, nazywanie exportu i ustawianie różnych globalnych zmiennych. (sam mam kłopot ze zrozumieniem co napisałem a więc jakoś to rozszerzę niżej).
• register – wewnętrzny system modułów SystemJS.

Czyli w jednej aplikacji możemy łączyć i mieszać każdy z tych systemów. Jest to dość poręczne. Głównie dlatego, że nie zawsze od nas jest uzależnione to w jakim systemie jest napisana dana biblioteka.

Dynamiczny

Czyli taki, który umożliwia ładowanie modułów w locie tak jak są one potrzebne. Dzieje się tak dzięki analizie kodu przez SystemJS. Na początku SystemJS wykrywa jaki format modułów dany skrypt wykorzystuje, jakie moduły ten skrypt potrzebuje i dopiero następnie ładuje wszystko. Działa to mniej więcej tak:

1. Załaduj dany plik i zobacz czy on czegoś potrzebuje, nie? To go zwróć.
2. Jak potrzebuje, dopisz plik do listy, i zobacz co potrzebuje.
3. Wejdź w kolejny plik i zobacz co on potrzebuje, dodaj go do listy.
4. Ładuj listę w odwrotnej kolejności pomijając już załadowane zasoby.

Dość proste.

Module Loader

Czyli jest odpowiedzialny za załadowanie danego skryptu w przeglądarce. Czy to będzie asynchronicznie czy synchronicznie zależy od formatu modułu, i sposobu jaki wykorzystamy do załadowania pierwszego pliku.

To co jest najważniejsze, nigdy, ale to przenigdy nie zostanie wykonany kod pierwszego pliku jeżeli nie uda się załadować wszystkich zależności.

Rozszerzanie

Ogólnie moduły są dostępne w JavaScript – w końcu są napisane w JS ;) Ale za pomocą systemu wtyczek możemy nie tylko ładować pliki JavaScript. Możemy zastosować dynamiczne ładowanie zasobów do plików css, less  czy html. Tego ogólnie jest dużo. Więc SystemJS robi trochę więcej. W tym na przykład po trafi w locie kompilować pliki takie jak ES6 czy CoffeeScript.

A by tego było mało SystemJS zawiera też system bundlowania plików zgodnie ze ścieżkami zależności. Jak nic prawie MacGyver :)

Podsumowanie

SystemJS jest dość ciekawym rozwiązaniem, dającym nam pewną swobodę w pisaniu aplikacji i nie przejmowaniu się tym, ze jQuery działa z AMD a angular tylko z global. SystemJS problem za nas rozwiążę. Może wymagać małej konfiguracji ale… to jest niski koszt posiadania dynamicznie ładowanych zasobów w aplikacji. Wygląda i zachowuje się też imo lepiej niż RequireJS który mnie do zawrotów głowy doprowadzał.

Z drugiej strony, to SystemJS NIE JEST częścią ES6. Będzie osobny module loader dla nowego JavaScript. Więc pytanie czy SystemJS ma przyszłość jako produkt? Niby celem jest oparcie implementacji SystemJS o standard WhatWG loader API – ale do póki nie wyjdzie ES6 (nie o to chodziło, ES6 jest dostępny od 2015 roku) ciężko mi jest powiedzieć czy taki byt jak SystemJS będzie dalej potrzebny.

Choć wiadomo jak jest :) zawsze będą stare aplikacje lub kod który nie będą mogły skorzystać z dobrodziejstw ES6 i ECMAScript Module.

Tak czy siak, to był wstęp do kolejnego Co To Jest :) więc jak widać, na pewno już gdzieś ten SystemJS jest wykorzystywany :)

PS.: w sprawie niezrozumiałego tekstu o formacie modułu global. Chodzi o to, że w konfiguracji możemy podać zależności (opcja jedynie dostępna dla formatu global). Problem pojawia się, że kiedy definiujemy zależność która nie jest zgodna z formatem global (tylko w global można ustalać zależności ale te zależności też muszą być w formacie global). Poprzez zdefiniowanie globalnych zmiennych, możemy temu częściowo zaradzić. To znaczy, możemy pozwolić by cały system korzystał z normalnie ładowanej zależności, a dla naszego formatu global zostanie załadowana specjalna, osoba zależność tylko i wyłącznie na czas wykonania kodu. Kurka jakie to pokręcone!!! A nazywanie exportów… to już chyba prosta sprawa. Cały załadowany plik będzie dostępny pod określoną nazwą.