Front-endowe CLI - pojedynek narzędzi wspomagających produktywność

Front-endowe CLI - pojedynek narzędzi wspomagających produktywność

Ekosystem najpopularniejszych frameworków front-endowych jest w dzisiejszych czasach na tyle duży, że stworzenie aplikacji typu “hello world” zgodnie z najnowszymi trendami na rynku przerasta wielu początkujących programistów. Konfiguracja projektu w zależności od środowiska, układ folderów i plików czy też narzędzia odpowiedzialne za poszczególne etapy budowania aplikacji – wszystko to sprawia, że “bootstrapując” aplikację opierającą się np. o Reacta czy Angulara wielu z nas może poczuć się zagubionymi. Aby proces inicjalizacji znacząco uprościć możemy w tym celu wykorzystać narzędzia typu Angular CLI czy też create-react-app, których zadaniem jest maksymalne uproszczenie oraz przyśpieszenie startu pracy z wybraną technologią. Dzisiaj przyjrzymy się wybranym rozwiązaniom realizującym takie zadania.

Tematem dzisiejszego posta będą:

Różni je wiek, przeznaczenie, poziom skomplikowania i oferowane funkcjonalności, ale przede wszystkim różni je framework który wspierają. Czego będzie dotyczyło dzisiejsze porównanie? Wymienionym narzędziom przyjrzymy się pod kątem czasu jakiego potrzebujemy od instalacji do momentu uruchomienia pierwszej aplikacji, jakości ich dokumentacji, komponentów które wchodzą w ich skład oraz ogólnie pojętego “developer experience”. Do testów wykorzystamy Node.js w wersji 10.4.0 oraz npm 6.1.0.

Zaczynamy!

Pozycja w wyszukiwarce oraz ocena społeczności

Zacznijmy od tak z pozoru błahej sprawy jak pozycja narzędzia w wyszukiwarce Google (w trybie incognito) oraz liczbę gwiazdek na GitHubie. Dzięki tym wskaźnikom dowiemy się jak popularne są testowane dzisiaj narzędzia oraz jak łatwo dowiedzieć się o ich istnieniu.

Ember CLI – 3,218 gwiazdek, w wyszukiwarce na pozycji nr 1.

Angular CLI 18,020 gwiazdek, w wyszukiwarce na pozycji nr 2.

 

create-react-app50,035 gwiazdek, w wyszukiwarce na pozycji nr 6.

vue-cli12,726 gwiazdek, w wyszukiwarce na pozycji nr 2.

Jeśli weźmiemy pod uwagę jedynie wyszukiwarki, to tutaj zwycięzcą jest Ember CLI. Po wpisaniu frazy “ember new project” Google natychmiast kieruje nas do strony tego właśnie narzędzia. Niestety, do pełnej oceny musimy wziąć pod uwagę ocenę społeczności, a tutaj narzędzie dedykowane dla Embera po prostu odstaje od całej reszty. To create-react-app jest rozwiązaniem które nie ma sobie równych i niemal trzykrotnie (!) przebija popularnością drugie w kolejności Angular CLI. Niska pozycja w wyszukiwarce to zapewne zasługa nietypowej nazwy narzędzia, jednak zdecydowanie większą wagę powinniśmy przykładać do rozmiaru społeczności (pozycja nr 6 wciąż nie wymaga od nas przeglądania kolejnych stron z wynikami wyszukiwania). Zwycięża więc CRA – czy tak będzie do końca?

Od zera do startupera

Kolejnym zadaniem będzie instalacja narzędzia oraz jak najszybsze uruchomienie przykładowej aplikacji – można powiedzieć, z klapkami na oczach. Wcielamy się w rolę założyciela genialnego startupu który potrzebuje jak najszybciej przekuć swój pomysł na formę MVP, więc nie wczytuje się w dokumentację lecz skupia się na jak najszybszym dostarczeniu wymarzonej funkcjonalności. Które narzędzie okaże się najprostsze w obsłudze w pierwszym podejściu?

Ember CLI

Szybkie spojrzenie na obietnice twórców:

It provides a consistent project structure, a powerful addon system, and a fast Broccoli-powered build pipeline. Whether you are looking for a zero-config experience or the ability to make your own customizations, Ember CLI has the tools you need.

Brzmi nieźle, a jak to wygląda w praktyce? Strona główna wita nas od razu komendą dzięki której zainstalujemy Ember CLI, natomiast poniżej znajduje się standardowa dokumentacja.

Pierwsza strona poświęcona jest przeglądowi możliwości tego właśnie narzędzia oraz wyjaśnienia po co właściwie go stosować. Niestety, informacji o stworzeniu pierwszego projektu na homepage’u nie znajdziemy – w tym celu udajemy się na podstronę “User Guide”. Tutaj pierwszy minus – przed rozpoczęciem pracy z Ember CLI na systemie macOS musimy wgłębić się w tajniki kolejnego narzędzia (Watchman) które ułatwi nam śledzenie zmian w projekcie. No dobra, ryzykuję i instaluję (wczytując się w międzyczasie w artykuł z 2013r. wyjaśniający czym Watchman jest). Dobrych kilka minut później, przy nie do końca udanej instalacji Watchmana, mogę w końcu wykonać komendy ember new hello-world-ember oraz ember server.

Czekam na instalację niezbędnych paczek a następnie uruchamiam serwer developerski. Konsola daje nam możliwość szybkiego odnalezienia się w tym co właśnie zaszło i mówi gdzie znaleźć nowopowstałą aplikację:

Angular CLI

A command line interface for Angular

Tutaj sprawa wygląda zdecydowanie lepiej niż u poprzednika. Strona główna jest czytelna a komendy niezbędne do zainicjalizowania projektu mamy na wyciągnięcie ręki (niestety nie w formie tekstowej):

Stworzenie nowego projektu za pomocą komendy ng new odbywa się bezproblemowo, jednak funkcjonalność nowego npma (audit) ostrzega nas o potencjalnie niebezpiecznych paczkach użytych w projekcie:

 found 13 vulnerabilities (9 low, 4 high)

No cóż – ryzykujemy i uruchamiamy naszą aplikację komendą ng serve:

Tutaj, tak samo jak w przypadku Ember CLI, dowiadujemy się o adresie pod którym znajdziemy aplikację, a także o rozmiarze zbudowanych paczek powstałych po zbudowaniu naszego projektu.

create-react-app

Create React apps with no build configuration.

Jak poradzi sobie najpopularniejsze narzędzie z testowanej dzisiaj czwórki? Zaczyna się nieco inaczej, bo nie od dedykowanej strony a od GitHuba. Jest też komenda npx create-react-app dzięki której w jednej linijce instalujemy tymczasowo (a nie globalnie!) narzędzie oraz tworzymy natychmiast strukturę nowego projektu. O tym, czym jest npx przeczytacie tutaj.

Po utworzeniu nowego projektu możemy przejść do jego katalogu głównego i wykonać klasyczną komendę npm start:

Strona początkowa nie zawiera niczego szczególnego. Miłym dodatkiem do inicjalizacji projektu jest automatyczne otwarcie strony przeglądarki z adresem pod którym znajdujemy naszą aplikację. Duży plus!

vue-cli

Tutaj podobnie jak w CRA zaczynamy od GitHuba. Na starcie czytamy niestety o statusie projektu i potencjalnych zagrożeniach wynikających z korzystania z niego:

Most of the planned features are in place but there may still be bugs. API may still change until we reach RC phase. Do not use in production yet unless you are adventurous.

W momencie pisania tego posta nie istniała jeszcze dedykowana strona dla vue-cli, jednak kilkanaście godzin temu to się zmieniło. Pod adresem https://cli.vuejs.org/ znajdziemy więc wszystkie niezbędne informacje potrzebne do rozpoczęcia pracy z Vue. Przeznaczenie vue-cli jest natomiast podsumowane jednym prostym zdaniem:

Standard Tooling for Vue.js Development

Zacznijmy więc testy – na start, wg instrukcji z powyżej strony, będziemy musieli wykonać komendę vue create hello-world-vue. Proces inicjowania projektu nie jest jednak automatyczny, bowiem od rozpoczęcia pracy dzieli nas jeden krok dotyczący wyboru konfiguracji – manual lub default (babel, eslint). Wybieramy default, czekamy na instalację paczek i po przejściu do katalogu z projektem uruchamiamy lokalne środowisko developerskie komendą npm run serve.

Strona początkowa dostarcza nam kilka przydatnych linków, np. do dokumentacji samego Vue, dokumentacji wybranych pluginów oraz miejsc takich jak forum czy czat społeczności frameworka. Cały proces odbył się bezproblemowo, za co również plus.

Ember CLI, poprzez nieprzyjazną dokumentację oraz nieco zaciemniony obraz konfiguracji (Watchman) zajmuje niestety ostatnie miejsce. Kolejny jest Angular CLI, którego czas uruchomienia jest znacznie dłuższy niż konkurencji (ok. 6 sekund) – do tego dochodzi jeszcze ostrzeżenie o potencjalnie niebezpiecznych zależnościach. vue-cli dla porównania uruchamia serwer developerski w ok. 1.5 sekundy – podobnie wygląda to w przypadku create-react-app. To właśnie te dwa narzędzia wygrywają konkurencję w której najbardziej liczyła się przejrzystość dokumentacji oraz prostota zainicjalizowania projektu.

Przegląd projektu

Dwa pierwsze testy nie mogły dać ostatecznej odpowiedzi co do użyteczności testowanych dzisiaj narzędzi. W końcu pozycja w wyszukiwarce, popularność czy inicjalizacja projektu to tylko ułamek całej przygody z projektem który dopiero utworzyliśmy. Dlatego właśnie w tym etapie naszego testu przyjrzymy się bliżej naszym projektom, mając na oku takie kwestie jak przejrzystość struktury, liczbę plików konfiguracyjnych czy poziom skomplikowania wygenerowanych części aplikacji.

Zacznijmy od domyślnej struktury projektu zaraz po otworzeniu go w jednym z wybranych edytorów. W którym z narzędzi struktura plików będzie najprostsza, a w którym pełna pułapek i podfolderów?

Już na pierwszy rzut oka widać, że create-react-app oraz vue-cli witają nas bardzo prostą, wręcz identyczną strukturą plików. Nieco bardziej skomplikowanie wygląda output z Angular CLI, natomiast Ember CLI idzie najdalej z całej czwórki dostarczając nam cała masę plików konfiguracyjnych.

Jak to będzie wyglądać w momencie kiedy rozwiniemy wszystko poza node_modules?

Tutaj różnice są jeszcze większe!

Idąc od prawej, vue-cli oraz create-react-app dostarczają nam bardzo płaską, jedno- bądź dwupoziomową strukturę katalogów. W folderze src znajduje się kod źródłowy z którym pracujemy na bieżąco, natomiast public to katalog odwzorowujący miejsce gdzie znajdzie się zbudowany projekt serwowany na wybranym przez nas serwerze. CRA dostarcza nam jeden główny komponent reprezentując całość aplikacji, natomiast w przypadku Vue widzimy komponent HelloWorld oraz komponent nadrzędny App w którym rejestrujemy kolejne subkomponenty.

Struktura projektu wygenerowanego przez Angular CLI wygląda nieco bardziej skomplikowanie – na pierwszym poziomie znajdziemy katalogi src oraz e2e, odpowiednio dla kodu źródłowego oraz testów end-to-endowych uruchamianych przy pomocy Protractora. W folderze z właściwą częścią aplikacji znajdziemy przede wszystkim główny moduł App, oraz pierwszy komponent – AppComponent. Do tego pliki konfiguracyjne oddzielnie dla środowiska produkcyjnego oraz lokalnego, konfigurację testów jednostkowych uruchamianych przy pomocy Karmy czy też pliki konfiguracyjne TypeScriptu.

Ember CLI to wszystko czego potrzebujesz na starcie oraz… wiele więcej. Mamy tutaj główny moduł z aplikacją, konfigurację środowisk, konfigurację przeglądarek z którymi aplikacja ma być zgodna, ale mamy też… mnóstwo pustych folderów sugerujących odpowiedni układ plików. Wystarczy spojrzeć na takie foldery jak tests/helpers, tests/integration, czy app/components (wszystkie puste) aby przekonać się, że konwencja to niemal najważniejsza rzecz w idealnym projekcie Emberowym.

Ciekawostką jest to, że Angular CLI to narzędzie które powstało na podstawie odpowiednika dla Embera – w wersji beta odniesień do Ember CLI było całe mnóstwo. Widać jednak, że twórcy Angular CLI poszli nieco inną drogą niż oryginał na którym się opierali, ponieważ odpowiednia (tj. odpowiadająca konwencji) struktura projektu tworzy się w momencie dodawania kolejnych komponentów. Ale o tym za chwilę…

Ciężko wskazać w tym momencie jednoznacznego zwycięzcę, ponieważ każde z opisywanych dzisiaj narzędzi wspiera framework* o innej filozofii – Ember i Angular to zdecydowanie bardziej określone i zopiniowane frameworki porównując je do Reacta oraz Vue, co odbija się znacznie na początkowej strukturze projektu i poziomie jej skomplikowania. Najsłabszym zawodnikiem w tym momencie jest chyba Ember CLI z mnóstwem pustych folderów, co ma wymusić na programistach trzymanie się odpowiedniej konwencji (tutaj wstaw to, a tutaj tamto). Sprawę można byłoby jednak rozwiązać o wiele bardziej elegancko, co pokazuje Angular CLI (o tym zaraz).

Po wygenerowanej strukturze projektu można byłoby pewien wyrobić sobie zdanie co do samych frameworków, jednak kwestia nie jest tak oczywista jak mogłoby się wydawać. Rozwiązania takie jak create-react-app czy vue-cli ukrywają dużą część swojej konfiguracji w paczkach dociąganych poprzez npm’a (bądź dodaję je wprost po wybraniu ręcznej konfiguracji), przez co użytkownik końcowy nie musi się mierzyć z aż tak dużą liczbą plików do zrozumienia. W łatwy sposób można to sprawdzić przyglądając się bliżej narzędziom wykorzystywanym przez np. vue-cli do budowania projektu, zaczynając od skryptów w package.json, przechodząc do node_modules i przyglądając się tej “ukrytej konfiguracji”:* – tak tak, React to biblioteka, a nie framework – dla ułatwienia w dzisiejszym poście stosuję to zamiennie

Przegląd funkcjonalności

Poszczególne aspekty każdego z opisywanych dzisiaj narzędzi, takie jak czas uruchomienia czy poziom skomplikowania projektu mogą wiązać się z różną liczbą dostarczanych przez nie funkcjonalności. Na nic nam szybki czas uruchamiania projektu, jeśli znajduje się w nim jedynie podstawowa konfiguracja a bardziej skomplikowane elementy musimy dodawać ręcznie. Podobnie w drugą stronę – czy długi czas budowania projektu równoważony jest tym, że dane narzędzie to jedyne czego będziemy potrzebować do pracy z naszym projektem?

Pierwszy komponent

Różnice pomiędzy narzędziami o których dzisiaj mowa ujawniają się przy najprostszych nawet zadaniach, takich jak stworzenie nowego komponentu dla danej aplikacji. O ile w Ember CLI oraz Angular CLI znajdziemy generatory tworzące komponenty (wraz z testami i stylami) i importujące je w miejsce których wymaga framework…

…to w create-react-app oraz vue-cli praca z nowymi komponentami polega na ręcznym utworzeniu odpowiednich plików oraz zaimportowaniu ich wedle życzenia potrzeby programisty. Możemy co prawda użyć narzędzi dostarczanych z zewnątrz takich jak https://github.com/diegohaz/generact które są stworzone do tego właśnie celu, jednak dzisiaj skupiamy się na tym co otrzymujemy po zainstalowaniu tylko jednego z czterech testowanych narzędzi.

Różnic nie ma na szczęście w możliwości ciągłej pracy z aplikacją uruchomioną w trybie deweloperskim, ponieważ w każdym z projektów pliki z którymi pracujemy są na bieżąco obserwowane, a aplikacja aktualizowana jest na podstawie zmian w projekcie.

Testy

Angular CLI przygotowuje projekt skonfigurowany pod dwa rodzaje testów – testy e2e obsługiwane przez Protractora, oraz testy komponentów i serwisów które moglibyśmy nazwać czymś w rodzaju testów jednostkowych. Do dyspozycji mamy dwie komendy – ng test oraz ng e2e – które uruchamiają wybrany rodzaj testów. Ciekawostka – w świeżo wygenerowanym projekcie znajduje się bug który uniemożliwia przejście serii domyślnych testów bez ingerencji w same przypadki testowe – do poczytania tutaj. Wygenerowane testy podpowiadają od razu dobre praktyki testów integracyjnych, takie jak wzorzec Page Object:

W przypadku Ember CLI wygląda to niemal identycznie – do dyspozycji mamy testy integracyjne oraz testy jednostkowe, a całość uruchamiana jest komendą npm test. Do testowania możemy wykorzystać wbudowane generatory np. testów akceptacyjnych które przypominają nam to co oferuje Protractor – za ich pomocą możemy symulować poruszanie się po stronie, interakcję z poszczególnymi komponentami oraz weryfikację struktury aplikacji.

create-react-app do domyślnie utworzonego komponentu dostarcza testy uruchamiane poprzez Jesta, co dla wszystkich fanów ekosystemu Reacta nie powinno stanowić żadnego zaskoczenia:

W przypadku vue-cli kwestia testowania wygląda nieco inaczej, ponieważ nie są one zamieszczone w domyślnej konfiguracji projektu. Aby projekt który utworzymy był skonfigurowany tak aby obsługiwać testy, w momencie wykonywania komendy vue create służącej do zainicjalizowania projektu musimy wybrać konfigurację ręczną – tam mamy możliwość dodania obsługi testów jednostkowych oraz integracyjnych jak w przypadku pozostałej trójki.

Style, obrazki, ikonki

Do aplikacji bogatej w funkcjonalności nie wystarczy jedynie zbiór dobrze przetestowanych komponentów. Aby nasz produkt był celem pożądania użytkowników, musimy przede wszystkim zadbać o jego warstwę wizualną. W tym celu w projekcie przyda nam się kilka reguł CSS, grafiki czy obsługa formatu SVG. Sprawdźmy więc ile wysiłku wymaga ostylowanie projektów utworzonych poprzez testowane dzisiaj narzędzia.

Angular CLI

W kwestii styli Angular CLI już w momencie generowania nowego projektu pomaga nam wybrać sposób w jakim będziemy się nimi posługiwać. Do wyboru mamy dwie opcje – –inline-style oraz –style. Pierwszy z parametrów pozwoli nam generować style dla komponentów w odrębnych plikach bądź wewnątrz plików z komponentami (*.ts)natomiast drugi pozwala na wybranie preprocesora (sass, less, stylus) z którym chcemy pracować. Jeśli chodzi o zasoby takie jak np. obrazki, Angular CLI trzyma się tutaj konwencji opartej o dedykowany folder src/assets, chociaż konfiguracja działającego pod spodem Webpacka pozwala na używanie np. relatywnych ścieżek do obrazków w plikach ze stylami. W przypadku plików SVG mamy małe ograniczenie polegające na braku możliwości importowania ich z poziomu pliku .ts jako string (ponownie kwestia konfiguracji), natomiast z poziomu CSS wszystko działa jak należy.

create-react-app

Tutaj konfiguracja Webpacka pozwala nam na nieco więcej niż w przypadku Angulara, ponieważ pliki CSS oraz SVG są możliwe do importowania bezpośrednio do komponentu (jako string). Dzięki temu możliwe są np. takie konstrukcje:

Jeśli chodzi o obsługę formatów styli innych niż CSS, to wg dokumentacji preferowanym podejściem jest doinstalowanie narzędzia które będzie obserwować nasze pliki ze stylami (np. node-sass w przypadku Sassa), w przypadku zmian będzie je kompilować do formatu .css, a css-y będziemy już importować do naszych modułów np. z komponentami (więcej na ten temat tutaj).

vue-cli

W domyślnej konfiguracji vue-cli wspiera jedynie style w formacie CSS, jednak nasz projekt może się wzbogacić o odpowiedni preprocesor już na etapie konfiguracji innej niż domyślna:

Bardzo podoba mi też możliwość “leniwego” wspierania formatów innych niż CSS w domyślnej konfiguracji Webpacka, gdyż pozwala to rozpocząć pracę z klasycznymi css’ami, a po dojściu do wniosku dot. migracji można po prostu doinstalować do projektu odpowiedni loader aby importy np. sassa były możliwe z poziomu kodu.

Ember CLI

Domyślna konfiguracja projektu przewiduje pracę ze stylami w formacie CSS, jednak tak jak u poprzednika, nic nie stoi na przeszkodzie żeby doinstalować odpowiednią paczkę poprzez wykonanie komendy…

…i cieszyć się wsparciem styli tworzonych w formacie sass. W przypadku Embera filozofia pracy ze stylami jest nieco inna niż u “konkurencji”, ponieważ zamiast importowania styli bezpośrednio do poszczególnych komponentów, importujemy je do “entry-pointu” app.css. Warto też zauważyć, że narzędziem które odpowiada tutaj za cały pipeline budowania np. styli nie jest Webpack, a Broccoli (co wiąże się z np. różnicą w stosowanych przez wszystkie te narzędzia pluginach).

W tym przypadku trudno wskazać jedno narzędzie które wyróżnia się zdecydowanie na plus lub minus. Obsługa niestandardowego preprocesora styli znalazła się w każdym z uczestników naszego porównania (chociaż implementowana na różne sposoby), więc podstawowy test zaliczamy w stu procentach. Zasoby takie jak obrazki czy pliki svg wspierane są bezpośrednio, lub  przez dedykowane pluginy tworzone przez społeczność – po prostu nie ma się do czego przyczepić.

Ekosystem, rozszerzenia, dostosowywanie konfiguracji

Domyślna konfiguracja mówi nam wiele jeśli chodzi o tzw. “happy path” pracy z każdym z opisywanych tutaj narzędzi, jednak to ekosystem rozszerzeń oraz możliwości dostosowywania konfiguracji do swoich potrzeb stanowią o sile wykorzystania takiego narzędzia w projekcie z prawdziwego zdarzenia. W przypadku tego punktu dokładnie połowa narzędzi zdecydowała się oprzeć rozszerzanie swojej funkcjonalności na pluginach, natomiast druga połowa… druga połowa ma to dopiero przed sobą 😉

Narzędziami które bardzo mocno stawiają na ekosystem pluginów są vue-cli oraz Ember CLI.

vue-cli to narzędzie które zapunktuje u wszystkich, którzy szukają odpowiedniego balansu pomiędzy łatwością obsługi a przyszłościowym ekosystemem rozszerzeń. W samym npmie na dzień dzisiejszy znajduje się ponad 70 różnego typu rozszerzeń pomocnych w przypadku testowania, obsługi styli czy wspierania np. PWA, a z każdym dniem baza paczek będzie zapewne rosnąć:

Jeśli chodzi o rozszerzenie konfiguracji działającego pod spodem Webpacka to – co jest ogromnym plusem tego narzędzia – oficjalna dokumentacja zawiera wszelkie niezbędne informacje:

Proste.

Największą zaletę Ember CLI jest dobrych kilka lat rozwoju całej społeczności skupionej wokół tego narzędzia i samego frameworka. Dla wszystkich zainteresowanych rozszerzeniami do Embera udostępniona została strona Ember Addons która na dzień pisania tego posta proponuje nam nieco ponad 4 tysiące rozszerzeń, a tych skupionych na cli – zawierających w nazwie fragment “ember-cli-” – jest ponad 300 (na podstawie 30 stron wyników które przejrzałem w trakcie tworzenia posta). Oficjalna dokumentacja zawiera też bardzo obszerny opis tworzenia własnych pluginów, szablonów tworzonych plików (blueprints, pods), czy samego API którym tworzone rozszerzenia mogą się posługiwać:

Angular CLI przyjmuje stanowisko inne do tego o którym właśnie przeczytaliście, bo wg filozofii jego twórców konfiguracja będzie ukrywana tak długo jak to tylko możliwe, a brakujące elementy będą implementowane w kolejnych oficjalnych wydaniach. W trakcie swojej przygody z Angular CLI już kilkakrotnie zdarzyło mi się dojść do ściany jeśli chodzi o pracę np. z Webpackiem, więc taka decyzja jest dla mnie mocno niezrozumiała (społeczność Angulara również nie jest z tego powodu zadowolona). Jeśli chodzi o rozszerzenia dostępne w repozytorium npm, to ich liczba jest naprawdę znikoma. Do niedawna dodanie do projektu obsługi formatu pug wyglądało tak:

Hmm…

create-react-app deleguje swoją konfigurację do paczki o nazwie react-scripts. Jeśli chodzi o dostosowywanie konfiguracji projektu do swoich potrzeb to propozycji społeczności i autorów jest kilka, zaczynając od ejecta, czyli przejścia na całkowite “sterowanie ręczne”, przez modyfikację konfiguracji standardowej poprzez zewnętrzne narzędzia, aż po podmianę react-scripts na własną paczkę. Na pewno nie brzmi to tak przyjemnie jak rozwiązania proponowane przez vue-cli czy Ember CLI.

Narzędzia pokroju tych które opisuje w dzisiejszym poście powinny moim zdaniem sprawdzać się w dwóch momentach życia każdego projektu – na samym początku, oraz w momencie kiedy projekt zamienia się w coś bardziej zaawansowanego. Ważne jest, żeby zachować odpowiedni balans pomiędzy dostarczaniem programiście niezbędnej konfiguracji oraz zależności i dodatków potrzebnych do uruchomienia projektu, a możliwościami dostosowywania tej właśnie początkowej konfiguracji do własnych potrzeb. W tej kategorii – dzięki podejściu opartemu o system pluginów – wygrywają zdecydowanie Ember CLI oraz vue-cliAngular CLI oraz create-react-app, pomimo bardzo przyjaznej w obsłudze inicjalizacji projektu, nie dają o sobie zapomnieć w dalszych etapach życia projektu, przez co wielu programistów (co widać chociażby po artykułach znalezionych w sieci) narzeka na ograniczone możliwości podążania ścieżką inną niż domyślna.

No więc? Kto wygrał?

Hmm… wnioski są nieco inne.

Przede wszystkim chciałbym zaznaczyć, że powyższy post nie miał na celu wyłonienia najlepszego narzędzia zarządzającego naszym projektem na front-endzie. Każde z nich powstało z myślą o innej technologii, więc wybór numeru jeden to pytanie pokroju “jabłka czy pomarańcze” – nie ma jednego zwycięzcy.

Do myślenia na pewno daje to, jak na pierwszy rzut wiele wspólnego ma np. Angular CLI z Angularem, vue-cli z Vue, a create-react-app z Reactem. Dlaczego? Można byłoby przecież wyjść z założenia, że tworzone w całkowitej separacji narzędzia powinny minimalizować pewne ograniczenia frameworków i technologii z którymi są związane, a maksymalizować ich mocne cechy. Co wynika z dzisiejszego porównania? Angular CLI to narzędzie najbardziej zopiniowane, zawierające najbardziej ukrytą konfigurację oraz dające bardzo niewielkie możliwości podążania własną ścieżką. Z drugiej strony – sprawdzi się doskonale tam, gdzie zespół potrzebuje jednego, ściśle określonego podejścia do robienia projektów. Brzmi jak pewien framework na A? vue-cli to narzędzie czerpiące garściami z pozostałej trójki, w którym niwelowane są słabe strony każdego z uczestników a do tego dokładane jest coś ekstra (interfejs przeglądarkowy, którego możecie odkryć samemu!) – brzmi jak pewne rozwiązanie na V? Ember CLI czyli moc społeczności, ogromna baza rozszerzeń i dość konserwatywne podejście do nowinek technologicznych – brzmi jak framework na E?

Wygląda więc na to, że w świecie front-endowych CLI w przyszłości może się jeszcze sporo wydarzyć. Brakuje moim zdaniem rozwiązania niezależnego, które zaproponuje świeże spojrzenie na daną technologię i które będzie mogło zniwelować słabe strony tych narzędzi które dzisiaj określamy mianem standardowych. Jasne, sam rozmiar projektów nie sprzyja na pewno rozwijaniu ich jednoosobowo, jednak nie wcale nie zdziwi mnie jeśli w przyszłości pojawi się ktoś kto powie “słuchajcie, mam 20% funkcjonalności tego co używacie dzisiaj, ale realizuje 80% funkcjonalności o które prosicie”.

Kolejną ważną lekcją jaką wyciągam z tego przeglądu narzędzi jest to, w jaki sposób realizują one posługiwanie się konfiguracją samą w sobie. Dan Abramov, jeden z członków core-teamu Reacta poświęcił temu tematowi jedną z jego prezentacji:

Konfiguracja to toolbox, którym powinniśmy się posługiwać jak jedną z wielu zależności w projekcie – toolbox powinien być wersjonowany, reużywalny i dostarczający niezbędne, intuicyjne API. Ważna lekcja.

Jakie są wasze doświadczenia w pracy z opisywanymi dzisiaj narzędziami? Użyteczne? Ograniczające? Dajcie znać w komentarzach!

Powiązane

O migracji do Angulara, czyli debiut w świecie ope... Niedawno pracując przy jednym z projektów które współtworzę natrafiłem na zadanie wymagające żmudnej, manualnej pracy powtarzanej w ten sam sposób...
Frameworki frontendowe, nauka CSS, git books ̵... Paczka wartościowych materiałów, które możecie znaleźć w sieci. Jeżeli chcesz zapoznać się z pozostałymi ciekawymi linkami możesz zrobić to tutaj....
10 powodów przez które język JavaScript jest tak p... Zastanawiasz się o co chodzi z całym tym hałasem dotyczącym języka JavaScript? Czemu powstają o nim dziesiątki memów i żartów? Dlaczego ludzi poświęca...
Open Source? A komu to potrzebne? Ruch Open Source od ponad 20 lat skupia wokół siebie osoby tworzące oprogramowanie z otwartym kodem źródłowym. Dla wielu programistów idea ta moż...