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

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

Object Storage Arubacloud
+1 głos
482 wizyt
pytanie zadane 2 kwietnia 2018 w Offtop przez NIMuser Stary wyjadacz (11,030 p.)

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?

 

7 odpowiedzi

+5 głosów
odpowiedź 3 kwietnia 2018 przez Tomek Sochacki Ekspert (227,510 p.)

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 :)

+2 głosów
odpowiedź 3 kwietnia 2018 przez Comandeer Guru (603,480 p.)

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. 

+1 głos
odpowiedź 3 kwietnia 2018 przez suweren Nowicjusz (160 p.)
  • "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. 

0 głosów
odpowiedź 3 kwietnia 2018 przez Alex.Ironside Stary wyjadacz (14,900 p.)
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.
0 głosów
odpowiedź 3 kwietnia 2018 przez ShiroUmizake Nałogowiec (46,300 p.)
  • 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 ;)

 

0 głosów
odpowiedź 3 kwietnia 2018 przez maciej.tokarz Nałogowiec (27,280 p.)
Do zalet można dorzucić prostotę wdrażania nowych wersji aplikacji w porównaniu z rozwiązaniami typu ClickOnce.

M.
0 głosów
odpowiedź 3 kwietnia 2018 przez NIMuser Stary wyjadacz (11,030 p.)

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. 

 

 

komentarz 3 kwietnia 2018 przez Comandeer Guru (603,480 p.)

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. 

Podobne pytania

0 głosów
1 odpowiedź 201 wizyt
pytanie zadane 26 lutego 2020 w Offtop przez JakSky Stary wyjadacz (14,770 p.)
0 głosów
1 odpowiedź 1,066 wizyt
pytanie zadane 4 maja 2018 w JavaScript przez sapero Gaduła (4,100 p.)
0 głosów
3 odpowiedzi 423 wizyt
pytanie zadane 15 września 2019 w Offtop przez JakSky Stary wyjadacz (14,770 p.)

92,757 zapytań

141,679 odpowiedzi

320,429 komentarzy

62,101 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...