Analiza i porównanie frameworków JavaScript, cz. 2

Damian Kołodziejski

Analiza i porównanie frameworków JavaScript, cz. 2
Grudzień 14, 2017 Katarzyna Sobczak

Analiza i porównanie frameworków JavaScript, cz. 2

Druga część serii. Porównanie ze względu na budowę małych oraz dużych aplikacji internetowych.

Tworzenie małych aplikacji

Aplikacje tego typu są bardzo popularne. Aby stwierdzić czy framework nadaje się do użycia na serwisach typu Multi Page Application, gdzie każda aplikacja jest tylko na jednej stronie, trzeba odpowiedzieć na trzy pytania.

Pierwszym pytaniem jest kwestia, czy można po prostu zaimportować plik solucji aplikacji, by ta zaczęła działać.

Angular nie został stworzony do tego typu solucji. Nie można natomiast powiedzieć że się nie da go w taki sposób wykorzystać. Do stworzenia aplikacji w Angularze potrzebny jest TypeScript. Przeglądarki nie rozumieją jego składni dlatego przed uruchomieniem aplikacji jej kod jest tłumaczony do kodu JavaScriptu. Operację tą dokonuje się przeważnie przed wrzuceniem solucji na stronę. Są metody by dokonywać operacji tłumaczenia kodu TS na JS u klienta. Byłby to natomiast ogromny krok wstecz jeśli chodzi o optymalizację kodu. Więc Angular nie został stworzony do aplikacji na serwisy MPA. Vue.js z kolei pozwala na prosty import biblioteki i rozpoczęcie korzystania z frameworka. Nie trzeba używać plików .vue, które wspiera biblioteka. Framework nie wymusza pisania aplikacji w TypeScript. Wystarczy prosty import potrzebnych do solucji bibliotek i można zacząć tworzyć aplikację. Dla Reacta też jest to możliwe. Nie jest to metoda, za pomocą której pisze się większość aplikacji w tym języku, ale jest to jak najbardziej możliwe rozpoczęcie budowy takiej aplikacji nie jest wcale skomplikowane.

Drugim pytaniem, na które warto odpowiedzieć jest to, czy framework został napisany do tego typu zadań.
Po części odpowiedź zostałana już podana, przy poruszaniu poprzedniej kwestii, jednak odpowiadając na to pytanie można dodatkowo zadać inne pytanie. Czy framework zawiera dużo niepotrzebnego kodu?

Z pewnością Angular nie został stworzony do małych aplikacji na stronę internetową. Kodu jest za wiele, ma zbyt skomplikowaną strukturę i co z tym idzie, nie został stworzony do kontrolowania małych fragmentów pojedynczych stron. Vue.js świetnie działa na takich stronach. Można swobodnie kontrolować tylko jedną część drzewa DOM, tą którą chce się kontrolować, resztę pozostawiając bez zmian. Ostatni framework można używać w taki sposób, nawet sam zespół Facebooka czyli twórców z niego w taki sposób korzysta. W momencie kiedy będzie dużo małych aplikacji, możliwe że zaistnieje potrzeba wprowadzenia prekompilatora, który będzie porcjował dane, by nie pobierać za każdym razem wielkiej paczki JS z mnóstwem skryptów, które bedą użyte na innej stronie.

Ostatnim pytaniem, które w tej kwestii można zadać, jest, czy jest zalecany lub potrzebny kompilator, który bedzie porcjował odpowienie dane.

W przypadku Angulara odpowiedź brzmi „tak”. Obecność kompilatora jest konieczna. Jest to niewątpliwa wada przy budowie małych aplikacji. Przy Vue.js nie jest to wymagane, można zastosować kompilator ale przy tworzeniu aplikacji na pojedynczą stronę może się to okazać albo przerostem formy nad treścią albo usprawenieniem budowy Aplikacji. Tutaj odpowiedź jest zmienna w zależności od wielkości aplikacji. Taka możliwość wyboru podczas budowy jest niewąpliwą zaletą. React nie wymaga żadnych prekompilatorów. Co prawda najlepiej działa w standardzie EcmaScript 6. Aby z tego standardu korzystać niezbędne jest środowisko deweloperskie, ponieważ przegladarki nie obsługują jeszcze tego standardu.

Podsumowując tą kwestię można jednoznacznie stwierdzić, że Angular nie jest stworzony małych, oddzielonych od siebie aplikacji na serwisie. Vue.js jest świetnym narzędziem, jeśli chce się go wykorzystać na małych stronach. React tak samo jak poprzednik, jest do tego stworzony, więc jak najbardziej można go używać na serwisie MPA.

Tworzenie dużych aplikacji

Ponownie, by odpowiedzieć na pytanie, jak framework poprawnie skaluje się wraz ze wzrostem rozmiarów aplikacji, trzeba odnieść się do kilku bardziej szczegółowych kwestii.

Pierwszą z nich jest zagadnienie zarządzania kodem, wtedy gdy jest go niewiele i wtedy gdy jego ilość rośnie wraz z czasem. Istotny jest tu fakt, czy istnieją dobre praktyki związane z nazewnictwem plików, katalogów, komponentów, modułów itp. Jest to bardzo istotne podczas tworzenia aplikacji.

W przypadku Angulara odpowiedź na pytanie, czy da się w prosty sposób zarządzać aplikacją podczas jej budowania brzmi „tak”. Jest mnóstwo dobrych praktyk, począwszy od tego, jak pliki powinny się nazywać, aż do kwestii ich przechowywania. Angular CLI (o którym więcej można przeczytać w tym wpisie) udostępnia oprócz środowiska deweloperskiego zespół takich dobrych praktyk. Podczas tworzenia nowych komponentów, pliki, katalogi, komponenty i inne moduły są nazywane według określonego schematu. Vue.js z kolei nie narzuca takich praktyk. Jest to zdecydowanie jego wada jak i zaleta. Przy przeglądaniu dokumentacji można zaobserwować pewne techniki, ale z tej racji, że nie są narzucane, nie są też powszechnie stosowane. Zmianę wprowadza natomiast oficjalnie udostępniony CLI. Pozwala on na szybkie budowanie skalowalnych aplikacji z narzuconymi pewnymi technikami. Wśród deweloperów Vue.js panuje swoboda, każdy stosuje taką metodę, jaka mu odpowiada najbardziej. Podobnie wygląda to w przypadku Reacta. Jest kilka praktyk które wywodzą się ze społeczności korzystającej z tego frameworka, ale jest w kwestii programisty, by o nich poczytać, wybrać te, który mu najbardziej odpowiadają, i stosować się do nich.

Drugą ważną kwestią jest to, czy deweloperzy muszą w dużej mierze polegać na paczkach kodu nie wywodzących się od twórców frameworka oraz czy wystarczająco dużo funkcji i możliwości oferuje framework sam w sobie.

Angular jest samowystarczalny, ma zaimplementowane mnóstwo rozwiązań, które na ogół przy tworzeniu aplikacji wystarczają. Plusem tego jest fakt, że dodatki są aktualizowane wraz z nową wersją frameworka. Przy Vue.js jest troszkę inaczej. Jest co prawda oficjalna paczka do routingu, jest paczka od twórców do zarządzania stanem aplikacji o nazwie Vuex. Jednak jeśli chodzi chociażby o walidacje formularzy, to jest to coś, czego nie ma w zaimplementowanym przez twórcę frameworku. Wtedy trzeba polegać na społeczności. React wypada najgorzej w tej kwestii. Zbiór realizowanych przez niego funkcji jest bardzo mały, a dodatki takie jak Redux, który jest odpowiedzialny za stan aplikacji, albo React Router, są stworzone przez społeczność. Nieoficjalne zbiory mają dużą konkurencję, co sprawia, że często trudno podjąć decyzję, która paczka spełnia wymagania projektu.

Kolejną, niezbędną do poruszenia kwestią, jest możliwość optymalizacji. To, czy łatwo zoptymalizować kod i czy łatwo go sprowadzić do stanu zadowalającego.

Angular posiada bardzo dużo tego typu wzorców. Są one niezbędne do optymalizacji danego programu użytkowego. Zbudowana wersja deweloperska do stanu produkcyjnego bez takich procesów posiada bardzo duży rozmiar. Vue.js sam optymalizuje częściowo kod, więc stosowanie rozwiązań osób trzecich nie jest konieczne. Tak samo jest z Reactem. Podczas tworzenia wersji produkcyjnej aplikacja zostanie odpowiednio zmniejszona.

Ostatnią sprawą jest łatwość zarządzania stanem aplikacji. Bardzo szybko przy rosnących aplikacjach pojawia się ten problem. Ważne wówczas są metody radzenia sobie z tym problemem, to czy jest jakiś wzorzec, biblioteka, czy nie ma nic.

Przy tworzeniu aplikacji w Angularze do dyspozycji są serwisy, które przestają się sprawdzać przy tworzeniu bardzo dużych aplikacji. Wtedy warto sięgnąć po rozwiązanie społeczności o nazwie NgRx, które pozwala zarządzać stanem aplikacji za pomocą klasy Observable. Vue.js rozwiązuje ten problem za pomocą oficjalnej biblioteki Vuex, która ładnie się integruje z aplikacją. Nadal trzeba poznać metodę, jak to zrobić poprawnie, jakie praktyki są najlepsze przy tego typu zagadnieniach, ale jest to duże ułatwienie, ponadto oficjalne narzędzie sprawia że nie ma rozwiązań konkurencyjnych dla tego stanu aplikacji. A co z tym idzie, Internet jest pełen poradników i wskazówek. Zespół Facebooka tworząc Reacta nie zapewnił takiego rozwiązania. Środowisko osób trzecich stworzyło jednak dobre biblioteki, takie jak Redux czy Flux. Plusem ich jest to, że bardzo łatwo je zintegrować z aplikacją, ale wymagają dodatkowej nauki.

Podsumowując, Angular został zaprojektowany od początku do tworzenia dużych aplikacji typu SPA i na pewno jest bardzo dobrym wyborem przy tworzeniu takich aplikacji. Za pomocą Vue.js także można tworzyć bardzo dobre, zarówno małe, jak i duże aplikacje oparte na interakcji. I to samo można powiedzieć o Reactcie. Pozwala on na tworzenie dużych aplikacji, jeśli nie stanowi problem wybieranie każdej części projektu.

Podziel się

Autor: Damian Kołodziejski

Damian Kołodziejski

Damian Kołodziejski

Zespół: Apps

Ostatnie artykuły autora

Analiza i porównanie frameworków JavaScript, cz. 2

Analiza i porównanie frameworków JavaScript, cz. 2

Porównanie ze względu na budowę małych oraz dużych aplikacji internetowych. Druga część serii.

Zmiana wyglądu formularzy

Zmiana wyglądu formularzy

Zmiana wyglądu checkbox, radio, select jest możliwa tylko za pomocą CSS. W artykule pokazuję jak to zrobić.

Tooltip w prostym i efektownym wykonaniu

Tooltip w prostym i efektownym wykonaniu

W tym artykule pokazano, jak wykorzystać niestandardowe atrybuty w elementach HTML, by wyświetlić ładny tooltip. Można utworzyć z niego moduł CSS, który będzie można zaimportować do każdego projektu.

Skontaktuj się z autorem

 

Administratorem danych gromadzonych z wykorzystaniem formularza jest A.P.N. Promise S.A. Podane przez Ciebie dane będą przetwarzane w zakresie niezbędnym do podjęcia kontaktu lub realizacji określonego żądania zgodnie z art. 6 ust. 1 lit. b RODO przez okres niezbędny dla realizacji Twojego zgłoszenia. Wszelkie informacje w zakresie przetwarzania podanych przez Ciebie w formularzu danych oraz posiadanych uprawnieniach znajdziesz w Polityce prywatności. Kliknij i dowiedz się więcej jeżeli informacje podane powyżej nie są dostatecznie jasne!