Do czego wlasciwie sluzy angilar? Zalozmy ze pisze sobie aplikacje asp.net mvc i w widokach chcialbym uzyc angulara. Czy angular zastapi mi w jquery , js i inne podobne rzeczy?
0
0
Angular nie zastąpi JQuery. Zasadnicza różnica: JQuery to biblioteka, a Angular to Framework. Zupełnie inne rzeczy.
0
Angular to framework, który ułatwia chować content :D
Załóżmy, że masz stronę HTML z pierdyliardem zdjęć. Odpalasz przeglądare, wchodzisz na tą stronę i ta stronka się ładuje pierdyliard lat, bo ma dużo contentu w postaci tychże zdjęć.
Przy pomocy Angulara przedstawisz tylko te zdjęcia (linki do zdjęć), które akurat chcesz widzieć, a resztę zostawiasz w spokoju do momentu ich wywołania. To poprawia działanie przeglądarki, komputer nie dyszy i ogólnie marnujesz mniej prądu :)
2
Kilka powodów:
- Odciążanie serverów, redukcja trafficu przez konsumowanie REST'a
Normalny schemat przeciętnej stronki bez resta wygląda tak:
Użytkownik wysyła zapytanie -> Strona robi swoją magie, generuje HTML'a -> Zwraca odpowiedź w postaci całej strony z nagłówkami itd.
---Nie ma w tym nic złego, klasyczna stronka. Jednak każde zapytanie usera powoduje generowanie całej stronki z html i zjada dużo zasobów
W przypadku angulara, stronka konsumuje REST, więc wygląda to tak:
Użytkownik wysyła zapytanie po raz pierwszy -> Stronka zwraca HTML'a z angularem -> Angular wysyła zapytanie rest'owe i go dostaje -> kolejne zapytanie -> znowu dostaje REST'a a nie całego HTML'a
---Nowe komputery są bardzo silne, nawet telefony. Za pierwszym razem najpewniej będzie się ładowało najwolniej użytkownikowi gdyż dostanie on dużą część aplikacji od servera Od razu "na raz". Jednak kazde jego zapytanie nie będzie skutkowało tym że server zwraca całego html'a , a resta czyli w skrócie taki pliczek tekstowy z samymi czystymi danymi ( przykład: http://jsonapi.org/examples/ ) , a potem po stronie użytkownika te dane są generowane i to nie jest tak że cała strona jest zmieniana, tylko ta część o którą użytkownik prosił, więc server jest odciązony. - Oddzielanie front-endu i back-endu
REST może być robiony w php/python/java/c#/cokolwiek, i front-enda nie obchodzi w czym jest robiony, jedyne co go obchodzi to gdzie "wystawiane" są informacje przez REST'a. Czyli front-end w tym wypadku może robić wersje wizualną strony której back-end był napisany w javie bez pracy z javą - Przyjemniejszy user experience
Animacje, przejścia, zazwyczaj płynniejsze ładowanie ( patrz punkt 1) , generalnie konkurencja rośnie. W przypadku stron angularowych itd. użytkownik ma wrażenie że dostaje "aplikacje" a nie strone. Jak odpalasz program to nie przeładowywuje się on z każdym kliknięciem tylko zmienia część kontentu zazwyczaj, tak samo ze stronami w angularze
Dlaczego wcześniej tego nie było?
- Bo technologie były w powijakach
- moc obliczeniowa pc'tów przeciętnych kowalskich była dużo słabsza
- ludzie się aż tak nie przejmowali UX jak teraz
- kiedyś było to ogólnie niemożliwe, bo walczono o kompatybilność co było głównie spowodowane sporymi udziałami IE8/9, teraz dużo się zmieniło bo prawie wszyscy używają już najnowszych wersji przeglądarek, i nawet jezeli jest jakaś niekompatybilność to jest ona bardzo mała
Generalnie koncept client-side renderingu nigdzie nie idzie a raczej zostanie na długo. Angular to nie jedyny taki framework który na to pozwoli,są jeszcze inne jak React ( + jakieś dodatki zazwyczaj), no i te niszowe ale nie warto chyba nawet o nich wspominać.
2
zerogravity napisał(a):
Jednak każde zapytanie usera powoduje generowanie całej stronki z html i
To chyba w PHP, bo normalne technologie i serwery potrafią keszować wyniki żądań i zwracać całe gotowe strony z pamięci.
zjada dużo zasobów
Zasoby to zżerają "nowoczesne frameworki JS". 5 lat temu dało się otworzyć 10 stron w przeglądarce, teraz już nie, bo każda jest tak obsrana animacjami i płynnymi przejściami, że w sumie zżerają wszystkie 4 rdzenie procka.
- Oddzielanie front-endu i back-endu
REST może być robiony w php/python/java/c#/cokolwiek, i front-enda nie obchodzi w czym jest robiony, jedyne co go obchodzi to gdzie "wystawiane" są informacje przez REST'a. Czyli front-end w tym wypadku może robić wersje wizualną strony której back-end był napisany w javie bez pracy z javą
To chyba jak ktoś pisał spaghetti w HTML i PHP, to coś mu teraz Angular oddzielił, bo sensowni programiści oddzielali front-end od back-endu już 10 lat temu.
- Przyjemniejszy user experience
Animacje, przejścia, zazwyczaj płynniejsze ładowanie ( patrz punkt 1) , generalnie konkurencja rośnie. W przypadku stron angularowych itd. użytkownik ma wrażenie że dostaje "aplikacje" a nie strone. Jak odpalasz program to nie przeładowywuje się on z każdym kliknięciem tylko zmienia część kontentu zazwyczaj, tak samo ze stronami w angularze
SPA też istniały już dawno.