• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

[Artykuł] Czy powinieneś użyć JavaScript MVC Framework do zbudowania aplikacji webowej?

+3 głosów
329 wizyt
pytanie zadane 15 lipca 2016 w Nasze poradniki przez użytkownika szmq Pasjonat (22,700 punkty)
edycja 15 lipca 2016 przez użytkownika szmq

Witam,

Zaczynając pisać kolejny projekt, zadałem sobie kilka pytań, a jednym z nich było czy powinienem użyć JavaScript MVC Framework do zbudowania aplikacji webowej. Jako że pewnie wielu z was zadało sobie lub zada podobne pytanie to, chciałbym wam przedstawić kilka ważnych informacji oraz zaprosić do dyskusji. Postaram wyjaśnić się różnicę pomiędzy aplikacją po stronie serwera oraz po stronie klienta, aby pomóc czytelnikom zrozumieć, jak ich projekt powinien być zbudowany.

Trochę teorii

Zanim odpowiemy sobie na tytułowe pytanie, chciałbym zbadać architekturę aplikacji po stronie serwera i klienta.

  • Jak jest zbudowana aplikacja po stronie serwera?

image

Mamy tu do czynienia z tradycyjną aplikacją po stronie serwera. W uproszczeniu zapytanie HTTP zostaje wykonane z przeglądarki użytkownika, następnie serwer przetwarza zapytanie, dynamicznie wprowadza dane do szablonu, a następnie HTML wraca do klienta.

  • Jak jest zbudowana aplikacja po stronie klienta?

image

W tym typie aplikacji wykonujesz to samo zapytanie na serwer, ale... kiedy ktokolwiek wykonuje interakcje na stronie np. kliknie w buttona, JavaScript określa, co potrzebuje do szablonu, czy zapytanie XMLHttpRequest powinno spowodować dostanie określonego szablonu i danych, które się w nim znajdą. Następnie JavaScript powoduje wywołanie AJAX i Żądanie XHR do serwera, aby uzyskać dane z powrotem. Funkcje zarządzania szablonami zostały przeniesione do klienta, więc dane i szablon zostanie odpowiednio dostosowany w jego oknie bez potrzeby przeładowania strony.

Jest wiele sposobów utworzenia aplikacji w ten sposób oraz wiele frameworków takich jak AngularJS, Ember.js i Backbone.js, które wszystkie są tego samego podejścia architektonicznego łączenia danych i szablonów w JavaScript po stronie klienta.

Ale czy potrzebuję tych wszystkich frameworkuf?​

  • JS

Nauczyłeś się używać JS do tworzenia niezbędnych walidacji formularzy, dodając pewne zachowania do swoich stron. Lubisz to albo.. niekoniecznie :) Jeżeli nie to wiesz, że nie tędy droga. API DOM jest raczej niezgrabne i trudne do zapamiętania. Zapewne lepiej użyć innego sposobu poradzenia sobie z tym problemem. Coś, co obniżyłoby poprzeczkę oraz wygodne przechodzenie przez elementy i dodawania zachowań.

  • JS + jQuery

Wow, pisanie w JS nabiera sensu! jQuery to świetna biblioteka, która ułatwia pracę z DOM-em. Dodawanie elementów stało się bardzo łatwe. Twoje strony ożywają i jesteś na szczycie świata (lub to, co czujesz). Fajnie.. ale projektując aplikacje inicjując wszystko w $(document).ready({...}) spojrzysz na kod i zobaczysz, że to jeden ogromny plik, z dużą ilością funkcji i wywołań zwrotnych oraz logiki. Wszystko na raz. Logika manipulacji DOM jest przemieszana z Ajaxem (żądaniami/odpowiedziami). Dodajesz dynamiczny HTML do kodu w tym samym miejscu, być może bez odpowiedniego systemu szablonów.

Gdy już zdecydowałeś się podzielić projekt na kilka plików stosując wzorzec MVC, aby uczynić kod bardziej do opanowania, projekt zaczyna się robić bardzo złożony. Wkrótce przychodzi do Ciebie żądanie, zmienia oznaczenia każdego postu w naszym systemie kolorowymi etykietami (coś jak tagowanie wiadomości z kolorowymi etykietami w Gmailu). Mówisz sobie, że ok, ale kiedy przechodzisz do analizy i chęci zaimplementowania, to zdajesz sobie sprawę, że aby to dodać musisz napisać wiele linii kodu z wieloma funkcjami/wywołanami zwrotnymi i powtórzeniami. Następnie udać się na stackoverflow z pytaniem, jak dany problem rozwiązać i czy jest lepszy sposób. Pisanie obiektowo w jQuery ułatwia życie i jest najlepszą drogą do dobrego zaprojektowania systemu. Można zdobyć ogromną satysfakcję. Nauczyć się dobrej organizacji kodu oraz sposobu jego działania, ale za wszystko bierzesz ogromną odpowiedzialność i piszesz dużo kodu od zera. Byłeś na drodze do napisania w pewnym sensie biblioteki, kiedy ktoś powiedział Ci o czymś takim jak framework.

  • MVC Framework (np. Backbone)

Ta-dam! Ktoś zaprojektował świetne narzędzie, które umożliwia sprawne projektowanie aplikacji, co sprawia, że pisanie kodu jest o wiele łatwiejsze. Stan nirwany osiągnięty. Paradygmaty MVC świetnie organizują Twój kod. Stosując poprawną strukturę aplikacji, sprawia ona, że kod znacznie zyskał na przejrzystości oraz jest ponownego wykorzystania. Jest to znacznie łatwiejsze od zarządzania złożonością całego projektu. Kod jest bardzo przejrzysty dla Ciebie oraz dla innych, dzięki czemu zyskujecie na wydajności pracy. Wydajność to nie wszystko.. Szacunek ludzi z githuba też jest ważny.

A SEO to co?

Napiszę krótko. Robot indeksujący Google wykonuje JavaScript na przeszukiwanych stronach. Istnieje kilka kroków, które trzeba podjąć, aby upewnić się, że aplikacja jest uzyskiwana i indeksowana.

  • HTML5 Mode.

  • Skonfigurowanie serwera.

  • Sitemap.

  • Semantyka

Podsumowując:

Framework MVC pomoże Ci z takimi rzeczami jak:

  • Określenie struktury kodu.

  • Dostarczenie przydatnych funkcji..

  • Szerokie wsparcie.

  • Organizacja kodu.

  • Efektywność pracy.

Jak myślicie? Czy waszym zdaniem jest sens korzystania z javascriptowych frameworków MVC, a jeżeli tak to na jakim etapie? Zapraszam do dyskusji oraz do komentowania artykułu.

Polecam również zapoznać się z: 

Dzięki :)

1 odpowiedź

+1 głos
odpowiedź 15 lipca 2016 przez użytkownika xandros Pasjonat (15,660 punkty)
A co jeśli nie wczyta mi się plik JS? Czy nie będę mógł swobodnie przeglądać treści strony?
komentarz 15 lipca 2016 przez użytkownika szmq Pasjonat (22,700 punkty)
Zależy. Niektóre SPA mogą być wstępnie renderowane z serwera. Poza tym dlaczego miałby się nie wczytać skrypt? :)
2
komentarz 15 lipca 2016 przez użytkownika Argeento Maniak (51,620 punkty)
komentarz 15 lipca 2016 przez użytkownika szmq Pasjonat (22,700 punkty)
edycja 15 lipca 2016 przez użytkownika szmq
Wyjmujesz link, który zbyt wiele nie mówi, a dodatkowo jest napisany przez osobę, która ma raczej nieobiektywne spojrzenie. Stara się udowodnić stwierdzenie "Everyone has JavaScript, right?". Ok, faktycznie :) Pewnie odsetek mniejszy niż użytkowników ie nie ma js, ale pomijając ten fakt przejdźmy do tego co jest na stronie. Pierwszy argument zdaje się być cytatem, ok. "If they're on a train and their net connection goes away before your JavaScript loads, then there's no JavaScript." - Faktycznie. Jak nie masz internetu to nie załadujesz każdej strony, a nie tylko opartej o SPA. Jeżeli chodzi o 3 argument to nie widzę u siebie takich problemów. Korporacje blokują JS? hm, też ciekawe. Później coś o rozszerzeniach, wyłączonym js, cnd, które wpływają na użytkowanie każdej strony, a nie tylko SPA. Następnie argument mający mi powiedzieć: Patrz jest jakiś bajer z którego nikt nie może korzystać bo nie ma wsparcia pomijając, że ktoś w ogóle chce go użyć :) Wiem, artykuł w linku ma za zadanie gnębić JS, a nie SPA, ale zauważmy, że każda strona korzysta z JS-a, a artykuł nawiązuje do SPA :)
komentarz 15 lipca 2016 przez użytkownika Comandeer Ekspert (326,890 punkty)

Faktycznie. Jak nie masz internetu to nie załadujesz każdej strony, a nie tylko opartej o SPA.

A teraz przeczytaj ten cytat jeszcze raz… ;)

 Jeżeli chodzi o 3 argument to nie widzę u siebie takich problemów. 

A co mnie obchodzi, co Ty widzisz u siebie? Mnie obchodzi, co widzę u siebie. 

Korporacje blokują JS? hm, też ciekawe.

Polecam sprawdzić, co hotelowe Wi-fi potrafią robić ze stronami. A mówimy tutaj o zwykłych proxy przy routerach. W przypadku korporacyjnych firewallów wycinane jest wszystko, co podpada pod dany wzorzec "naruszający bezpieczeństwo" (albo wszystko, co nie pochodzi z zaufanych domen). 

Wiem, artykuł w linku ma za zadanie gnębić JS

Nic z tych rzeczy. Za to zgrabnie pokazuje rzeczywistość w przypadku JS-a w przeglądarce. 

komentarz 15 lipca 2016 przez użytkownika event15 Szeryf (82,910 punkty)
komentarz 15 lipca 2016 przez użytkownika szmq Pasjonat (22,700 punkty)
edycja 15 lipca 2016 przez użytkownika szmq

Temat tego artykuły jest inny i trochę od niego odchodzicie. Pisałem o dobraniu odpowiednich narzędzi, które pomogą nam w etapie tworzenia strony, a nie o tym czy JS ma smutną rzeczywistość (czy w ogóle działa). Skoro już dyskutujemy na inny temat to chętnie z wami pogadam :) 

@Comandeer

A teraz przeczytaj ten cytat jeszcze raz… ;)

Wytłumacz bo albo Ty nie zrozumiałeś mojej wypowiedzi albo ja nie rozumiem tego o co w tym chodzi.

A co mnie obchodzi, co Ty widzisz u siebie? Mnie obchodzi, co widzę u siebie.

Gdzie widzisz? Podaj mi przykład. Chętnie sprawdzę. 

Polecam sprawdzić, co hotelowe Wi-fi potrafią robić ze stronami. A mówimy tutaj o zwykłych proxy przy routerach. W przypadku korporacyjnych firewallów wycinane jest wszystko, co podpada pod dany wzorzec "naruszający bezpieczeństwo" (albo wszystko, co nie pochodzi z zaufanych domen).

Nie mówię, że nie są takie rzeczy blokowane, ale wiem jak to wygląda bo już nie raz ciągnąłem neta z takich miejsc. Rzadkością jest, że ktoś blokuje JS.

 Za to zgrabnie pokazuje rzeczywistość w przypadku JS-a w przeglądarce.

Napisz coś więcej skoro włączyłeś się do dyskusji :) 

 

@event15

True

komentarz 15 lipca 2016 przez użytkownika Comandeer Ekspert (326,890 punkty)

Wytłumacz bo albo Ty nie zrozumiałeś mojej wypowiedzi albo ja nie rozumiem tego o co w tym chodzi.

Chodzi o sytuację, gdy wstępny "HTML" (czyli zaślepka dla JS) zostanie wczytany, po czym zabraknie połączenia. Wówczas zostaniemy z czymś, co można se po prostu wsadzić. 

Gdzie widzisz? Podaj mi przykład. Chętnie sprawdzę. 

To kup se iPlusa/inny mobilny net i wyjedź na tydzień gdzieś poza duże miasta. To w zupełności wystarczy ;)

Nie mówię, że nie są takie rzeczy blokowane, ale wiem jak to wygląda bo już nie raz ciągnąłem neta z takich miejsc. Rzadkością jest, że ktoś blokuje JS.

 I akurat pech chce, że ten 1/milion użytkownik to będzie największy potencjalny klient, który stwierdzi, że Twoja strona to jednak syf, bo tak trochę nie działa ;)

Napisz coś więcej skoro włączyłeś się do dyskusji :) 

Wystarczy poczytać mój artek, do którego zalinkował event15 :P

Wymagania są coraz większe, a przecież REST ma dużo swoich zalety.  

To teraz pozwól, że zadam Ci to samo pytanie, co zadaję każdemu devowi JS obecnie: a co ma REST (architektura backendowa) do tego jak działa JS na froncie? Na tym polega cały dowcip z REST, że on jest całkowicie niezależny od frontu i tłumaczenie, że apka nie działa bez JS, bo "jest REST" jest po prostu tragicznym nieporozumieniem. 

Jedyny argument, jaki dotąd wysunięto przeciwko mojemu artkowi o Angularze, jest właśnie tego pokroju: nie rozumiem MVC. I tu zasadza się problem, bo… nigdy nie rozpatrywałem Angulara w kontekście MVC. Niemniej istnieje jakiś bzdurny mit – tak jak w przypadku REST – że to są jakieś "nowoczesne webappki", które mogą łamać wszelkie utarte praktyki. Nie, nie mogą. Zarówno MVC jak i REST są o wiele starsze niż cały JS.

Polecam spojrzeć na np. Taunusa, gdzie 1. load zawsze generowany jest przez serwer, a dopiero wszystkie kolejne przez client side – jeśli skrypty działają. Owszem, nie we wszystkich aplikacjach się to sprawdzi, ale praktycznie we wszystkich apkach można userowi zafundować podstawową funkcjonalność, np. zamiast real time komunikatora dostanie zwykły formularz wysyłania wiadomości.

komentarz 15 lipca 2016 przez użytkownika szmq Pasjonat (22,700 punkty)

Chodzi o sytuację, gdy wstępny "HTML" (czyli zaślepka dla JS) zostanie wczytany, po czym zabraknie połączenia. Wówczas zostaniemy z czymś, co można se po prostu wsadzić. 

Tak, to miałem na myśli, ale przecież połączenia może zabraknąć przy każdej innej stronie. Np przy wczytywaniu CSS i tak dalej. Jeżeli chodzi o sam JS jest też właśnie ewentualność wstępnego renderowania z serwera.

I akurat pech chce, że ten 1/milion użytkownik to będzie największy potencjalny klient, który stwierdzi, że Twoja strona to jednak syf, bo tak trochę nie działa ;)

Niby można zaoferować podstawową funkcjonalność. Wtedy serwis traci, ale tak czy inaczej jest to strata także dla innych stron. W takim wypadku chyba najlepiej zadbać o tą podstawową funkcjonalność / wygenerowanie widoku przez node albo napisanie aplikacji mobilnej. Gdy piszemy REST, a JS generuje widoki to łatwo napisać aplikacje np. w takim IONIC. 

To teraz pozwól, że zadam Ci to samo pytanie, co zadaję każdemu devowi JS obecnie: a co ma REST (architektura backendowa) do tego jak działa JS na froncie? Na tym polega cały dowcip z REST, że on jest całkowicie niezależny od frontu i tłumaczenie, że apka nie działa bez JS, bo "jest REST" jest po prostu tragicznym nieporozumieniem. 

Jeżeli tak jak pisałeś do mnie, że nie ma middleend to aplikacja ma prawo nie działać, więc wytłumaczenie jakieś tam jest :) 

Polecam spojrzeć na np. Taunusa, gdzie 1. load zawsze generowany jest przez serwer, a dopiero wszystkie kolejne przez client side – jeśli skrypty działają. Owszem, nie we wszystkich aplikacjach się to sprawdzi, ale praktycznie we wszystkich apkach można userowi zafundować podstawową funkcjonalność, np. zamiast real time komunikatora dostanie zwykły formularz wysyłania wiadomości.

Thx, na pewno rozwiało to dużo wątpliwości :) 

Podobne pytania

0 głosów
1 odpowiedź 101 wizyt
0 głosów
1 odpowiedź 38 wizyt
pytanie zadane 29 lipca 2016 w C# i .NET przez użytkownika Tomek Krupa Użytkownik (840 punkty)
0 głosów
0 odpowiedzi 34 wizyt
pytanie zadane 21 grudnia 2016 w C# i .NET przez użytkownika Arqu07 Nowicjusz (120 punkty)
...