Angular, Aurelia, Vue, React, Ember - jakie korzyści z "nowego" podejścia w webdev?

Question

Od kilku lat front end coraz częściej robi się we frameworkach JS, jak Angular, Vue, React, itd. Wymusza to duże zmiany w webdev, zamiast typowych stron coraz częściej robi się SPA lub PWA w tych frameworkach, a backend to już tylko API podające dane w różnej formie (zwykle JSON)....

OK, tylko jakie to ma zalety? Nie widzę specjalnie korzyści -> A cały webdev przez to został utrudniony.

 

Zwolennicy tego podejścia wyliczają zalety:

• mniej żądań do serwera
• odseparowanie frontu od backendu (tylko po co kolejne?)
• strony WWW przypominają aplikacje desktopowe
• większa szybkość działania, aplikacje reaktywne, itp.

Jest też sporo wad:

• duże kłopoty z SEO
• "podstrony" nie mają swojego linku, unikalnego URL
• brak historii, funkcje przeglądarki Back, Forward nie działają
• start strony jest wolniejszy bo trzeba ściągnąć więcej danych na początku

 

Więc po co to wszystko? :) Czy nie jest tak, że korzyści jest mniej niż wad?

W jakich zastosowaniach, w jakiego typu aplikacjach nowy sposób budowy aplikacji www się sprawdza najlepiej?

Z czego wynika obiecywane szybsze działanie tego typu stron?

 

Answer 1

Jest też sporo wad:

• duże kłopoty z SEO
• "podstrony" nie mają swojego linku, unikalnego URL
• brak historii, funkcje przeglądarki Back, Forward nie działają
• start strony jest wolniejszy bo trzeba ściągnąć więcej danych na pocz

A skąd takie przekonanie :)?

Problemy z seo wynikają z tego, że wiele osób nie robi po prostu Server Side Rendering, a jak to zrobisz np. z React to klient dostaje normalnego html i google wszystko widzi :)

Co do punktu 2 i 3 to nie zgodzę się - poczzytaj np. o react-router w React czy innych analogicznych rozwiązaniach z pozostałych technologiach.

Z tym startem też bym nie dramatyzował. No chyba, że np. w takim React zapuścimy klientowi pełną wersję react bez żadnej minifikacji itp. Rozmiar można łatwo zmniejszyć np. poprzez minifikację plików i do tego jakąś kompresję gzip.

 

Ale oczywiście nie są to technologie do wszystkiego. Na przykład nie ma wg mnie sensu ładować React do małego portfolio czy wizytówki mechanika, gdzie wszystko opykasz w parudziesięciu linijkach JS, ewentualnie wspomaganego jQuery jak ktoś bardzo chce.

Ale z kolei już przy bardziej rozbudowanych apkach zauważa się potęgę takich technologii. Jest to kolejna warstwa abstrakcji nałożona na całą apkę, ale wg mnie warto. A jak dodasz sobie np. redux w React + react-router + thunka itp. to robi się bardzo miło, oczywiście nie zapominając o SSR :)

Answer 2

Z czego wynika obiecywane szybsze działanie tego typu stron?

Z tego że po wolniejszym pierwszym wczytaniu nie następuje ani jedno pełne odświeżenie strony, ergo – jest szybciej albo – co jeszcze ważniejsze – sprawia wrażenie szybszego.

• odseparowanie frontu od backendu (tylko po co kolejne?)

Bo generowanie widoku nie jest już częścią backendu, zwłaszcza jeśli widoki różnią się w zależności od np. typu urządzenia. Stąd powstała idea middleendu czy też backends for frontends. No i tym samym uwalnia się dane od jakiegokolwiek sposobu prezentacji.

• "podstrony" nie mają swojego linku, unikalnego URL
• brak historii, funkcje przeglądarki Back, Forward nie działają

Hasło-klucz: History API.

• start strony jest wolniejszy bo trzeba ściągnąć więcej danych na początku

Tylko za pierwszym razem. Przy drugim wchodzi agresywny cache i Service Worker. 

Answer 3

• "podstrony" nie mają swojego linku, unikalnego URL
• brak historii, funkcje przeglądarki Back, Forward nie działają

Nieprawda, w obydwóch przypadkach jest pełne wsparcie. 

• duże kłopoty z SEO

Brakuje mi tutaj szerszej arguemntacji jak w zasadzie przy każdym innym punkcie. Jeśli chodzi o wsparcie SEO przez aplikacje CSR to nie jest ono takie złe, pamiętajac że roboty rozumieją bufor na generowanie js. Do tego dochodzi jeszcze możliwość usprawnienia swojej semantycznej aplikacji uruchomieniem JS po przez SSR - co w przypadku reacta i vuejs ma spore wsparcie (nie wiem jak jest z angularem). 

• start strony jest wolniejszy bo trzeba ściągnąć więcej danych na początku

Dlatego istnieją zasady czystego kodu które mają uchronić twoją aplikację od ładowania miliona zbędnych dla niego linii, to jaki efekt otrzymasz na koniec zależy od Ciebie i twojego zespołu. Przy obecnym rozwoju technologii zazwyczaj js sciąga się w sekunde, a same biblioteki frameworki zajmują od 5kb do 100kb. 

Z czego wynika obiecywane szybsze działanie tego typu stron?

Jakie obiecywane szybsze działanie stron? W kwestii użytkiownia przez klienta, sporą zaletą jest SPA, dzięki której klient nie odczuwa procesu ładowania się strony w tak dużym stopniu, moze o to właśnie chodzi? Pytanie trochę bez kontekstu. 

Answer 4

Z tego co rozumiem glownie chodzi o obciazanie serwera. Przy naszych malych web apkach nie ma to znaczenia, ale jezeli taki fb czy Youtube musialby wysylac za kazdym razem tone kodu HTML to jest to po prostu wielkie jego niepotrzebne obciazenie.

Co do wczytywania: Jezeli odpalasz jakikolwiek program to wczytuje on najpierw potrzebne bajery. Tak samo mozna potraktowac wiekszy portal. Juz sama nazwa web apps sugeruje ze sa to aplikacje internetowe.

Answer 5

• mniej żądań do serwera

To zależy właściwie od samej konstrukcji endpointów, jeżeli mówimy o typowych danych. Nie zawsze to jest prawda. 

• odseparowanie frontu od backendu (tylko po co kolejne?)

Byś mógł separować stany i zarządzać stanem z dowolnego miejscu za pomocą Vuex, Redux, mobX choć tutaj podejście jak zarządzać stanem jest różne.

• większa szybkość działania, aplikacje reaktywne, itp.

Nie do końca prawda. Po prostu taniej jest zrzucić moc przerobową na klienta, niż mielić to w kolejnym wątku. 

• duże kłopoty z SEO

Prawda, boty wolniej indeksują, prawdopodobnie spowodowane jest to analizą JS.

• "podstrony" nie mają swojego linku, unikalnego URL

Routing, historyAPI?

• brak historii, funkcje przeglądarki Back, Forward nie działają

To trzeba, tak projektować UI by dać taką możliwość. W grze chyba też nie masz natywnego przycisku cofaj ;)?

• start strony jest wolniejszy bo trzeba ściągnąć więcej danych na początku

To zależy, jak zaprojektowaliśmy nasze komponenty ;)

 

Answer 6

Do zalet można dorzucić prostotę wdrażania nowych wersji aplikacji w porównaniu z rozwiązaniami typu ClickOnce.

M.

Answer 7

Dzięki za odpowiedzi!  Nie spodziewałem się tak wielu i tak obszernych

Większość wad, tak jak opisaliście można obejść, ale jakby nie patrzeć jest to dodatkowa robota.

Jedna rzecz jeszcze wymaga wyjaśnienia - w jakich stronach, jakiego typu ma to sens?

• Czy typowy sklep internetowy skorzysta na czymś?
• Czy to ma sens w przypadku galerii fotografii lub portalu strumieniującego muzykę?
• Na jakich stronach to rozwiązanie przyniesie najwięcej korzyści?

---

Jeśli mamy stronę z paginatorem (np. typowego bloga) pokazującą kilka wpisów na stronie (tekst + zdjęcia), to klient (przeglądarka) i tak musi ściągnąć np. 5 tekstów i 5 zdjęć, jak użytkownik kliknie link nastepna_strona to znów wysyła podobną liczbę żądań i znów ściąga 5 tekstów i 5 zdjęć co trochę trwa - gdzie tu jest zysk?  Można by ściągnąć więcej zdjęć "na zapas" (już wcześniej, do "bufora"), żeby klient nie czekał na ściąganie zdjęć... Ale to rozwiązanie też ma pewne wady. 

 

 

Comments

Ale Ty wszystkie "aplikacje" webowe wrzucasz do jednego worka. A przecież to nie tak działa.

Każda strona powinna być PWA. Wystarczy dorzucić Service Workera i manifest (bo HTTPS pewnie już jest). Minimalny nakład pracy, a dostajemy stronę działającą w trybie offline.

Większość wad, tak jak opisaliście można obejść, ale jakby nie patrzeć jest to dodatkowa robota.

Problem w tym, że wady, które wymieniłeś, nie są wadami, bo… nie istnieją. Dobrze zrobiona aplikacja w duchu PE ma po prostu działające URL-e, ma normalny server side rendering, a wolniejszy start to wina złej optymalizacji, nie posiadania web appa.