Wpis z mikrobloga

Luźne pytanie na weekend: co sądzicie o przyszłości single-page application? Wszyscy wiemy jak zawsze(jeszcze nie tak dawno) tworzyło się strony internetowe - #php lub coś innego generowało HTML po stronie serwera, a przeglądarka wczytywała #js, #css i tylko pewne elementy na stronie korzystały z AJAXa. Dziś mamy Angular, Ember, React i wiele innych frameworków, bibliotek i narzędzi, które zmieniły sposób tworzenia stron internetowych. Popularne stały się single-page applications, czyli aplikacje, które eliminują potrzebę kontaktowania się przeglądarki z serwerem przy przechodzeniu z jednej strony na drugą. W ostatnich latach mechanim ten znacząco się rozwinął(HTML5, pushState, ...) i staje się (bardziej) powszechny w webdevie.

Zalety:
+ mocne oddzielnie frontendu(UI) i backendu(dane), MVC
+ brak widocznego "przeskoku" w nawigacji, przede wszystkim na urządzeniach mobilnych(upodobnienie do aplikacji mobilnych)
+ JS/CSS ładowane tylko raz
+ strona może obsłużyć większą ilość użytkowników, polegamy w większym stopniu na urządzeniu klienta, więc serwer otrzymuje mniej requestów, a odpowiedzi są krótsze(JSON)
+ walidacja z łatwością może się odbywać po stronie klienta
+ wiele innych...

Wady:
- SEO jest jednym z największych problemów, nie wszystkie wyszukiwarki/crawlery renderują Javascript
- pliki JS mogą być ogromnych rozmiarów(z pomocą przychodzi np. Webpack)
- dłuższy czas ładowania strony(to też zależy od jej struktury - Webpack)
- bezpieczeństwo(np. łatwiej "podpiąć się" do "prywatnego" API strony, oczywiście można to rozwiązać na różne sposoby, był dzisiaj wpis na ten temat na mirko)
- starsze przeglądarki/podprzeglądarki mogą sprawiać problemy

Jak Wy budujecie swoje aplikacje webowe? Jakich frameworków w JS używacie? Czy architektura SPA powinna stać się standardem, normą? :)

#programowanie #webdev #kiciochpyta
Pobierz 5z7k9 - Luźne pytanie na weekend: co sądzicie o przyszłości single-page application? ...
źródło: comment_8djdgW8Nq9rW4GHA1hJnPmBIcec4iies.jpg
  • 16
Można wszystko pogodzić, jak jest kasa i czas.

SPA dla użytkowników,
czysty HTML dla botów i starszych Useragent
dynamiczne ładowanie tylko wymaganych komponentów - Webpack jak wspomniałeś.
Bezpieczeństwo ~ JWT

Na dobrą sprawę przy pierwszym załadowaniu strony można ładować czysty HTML,
a dopiero dalszą nawigację przekazywać Javascript.

Wszystko zależy od projektu i kasy jaką można poświęcić na niego.

Od siebie polecam na start #vuejs
@5z7k9: Ja jestem wielkim fanem podejścia SPA. Jak dla mnie do zalet jeszcze można dodać (choć trochę pokrywa się z pierwszym pkt) bardzo łatwo np. zmienić język backendu. Bo od servera otrzymujemy z konkretnego urla np. jsona. Pracowałem w dwóch projektach jeden był z podejściem SPA (java + angular) drugi SOAP. Muszę powiedzieć, że dużo łatwiej się pracuje z SPA. Jednak tak jak wspomniałeś dużym minusem jest bezpieczeństwo, ale tutaj nie
@5z7k9:

+ mocne oddzielnie frontendu(UI) i backendu(dane), MVC

MVC niczym demokracja, słowo klucz i odpowiedź na wszystko.

brak widocznego "przeskoku" w nawigacji, przede wszystkim na urządzeniach mobilnych(upodobnienie do aplikacji mobilnych)

Do osiągnięcia również w aplikacjach nie SPA. pjax, turbolinks itd.

+ JS/CSS ładowane tylko raz

Również możliwe w nie SPA.

+ walidacja z łatwością może się odbywać po stronie klienta

To chyba żart.

+ wiele innych...

Jakich?

- pliki JS mogą
@stacktrace:

MVC niczym demokracja, słowo klucz i odpowiedź na wszystko.

Nie napisałem, że MVC to najlepsze co może być, sam nie jestem tego wielkim orędownikiem, ale dla wielu osób jest to zaleta, a w SPA taka architektura jest łatwiejsza do osiągnięcia. Półobiektywna zaleta.
.

Do osiągnięcia również w aplikacjach nie SPA. pjax, turbolinks itd. (...) Również możliwe w nie SPA.

Nie napisałem, że nie. Sam gdzieś w poprzednich wpisach podawałem pjax.
Strony powinny być robione wg. metodyki "Progressive enhancement". Wobec czego większość SPA powinno zapewniać podstawową funkcjonalność bez JS. Nie zapominając, że renderowania części rzeczy po stronie serwera jest szybsze niż ładowania wszystkiego przez JS za pomocą Ajax. Wystarczy spojrzeć choćby na sztandarowy przykład Twittera.
@newblob z tą szybkością to jest różnie - przy dużej skali warto przerzucić obliczenia na użytkownika w celu zmniejszenia serwerowni. Komputery obecnie są szybkie, a ich moc obliczeniowa się marnuje
@AhoCorasick Przede wszystkim trudno indeksować tego typu strony wyszukiwarkom. Po drugie aktualnie masa gównianych programistów tworzy atrapy aplikacji, które są nieużywalne dla osób niepełnosprawnych, a dla których powstał cały standard tworzenia aplikacji internetowych (ARIA). Cel biznesowy, a gdzie tu etyka? - oczywiście, ale programista musi implementować te aplikacje tak, by można było je używać przez ludzi wykluczonych.
Pierwszy lepszy pajac wstawi sobie jakiś gówniany komponent i och ach zadowolony bo działa, oczywiście
SEO jest jednym z największych problemów, nie wszystkie wyszukiwarki/crawlery renderują Javascript


@5z7k9: google przecież normalnie indeksuje strony z jsem, a reszta się nie liczy, > walidacja z łatwością może się odbywać po stronie klienta

walidacja z łatwością może się odbywać po stronie klienta


tak czy siak musi ona też być po stronie serwera

JS/CSS ładowane tylko raz


tutaj nie rozumiem o co ci chodzi

bezpieczeństwo(np. łatwiej "podpiąć się" do "prywatnego" API
@Jurigag:

google przecież normalnie indeksuje (...)

reszta się nie liczy

Zależy od potrzeb i wymagań, a renderowanie JS przez Google nie jest do końca pewne i niewiadomo czy w 100% sprawne.

tutaj nie rozumiem o co ci chodzi

Pliki JS/CSS nie muszą być(a raczej przeglądarka się do nich nie odwołuje, bo normalnie i tak nie pobierze drugi raz przez cache) pobierane przy każdym przejściu pomiędzy podstronami.

tu tez nie wiem o
Zależy od potrzeb i wymagań, a renderowanie JS przez Google nie jest do końca pewne i niewiadomo czy w 100% sprawne.


@5z7k9: jest pewne i sprawne bo widzę na swojej stronie xd

Pliki JS/CSS nie muszą być(a raczej przeglądarka się do nich nie odwołuje, bo normalnie i tak nie pobierze drugi raz przez cache) pobierane przy każdym przejściu pomiędzy podstronami.


@5z7k9: przecież nie są bo są trzymane w cache O_O
Przede wszystkim o to, że w SPA często polega się np. na REST i korzysta z tokenów(niewygasających również), więc komuś łatwiej "hackować" naszą aplikację, ma dostęp do naszej usługi w bardzo łatwy sposób. Trudniej to zrobić w nie-SPA, ale wiadomo - dla chcącego nic trudnego.


JWT i tokeny mogą się regenerować się co zapytanie,
zresztą API końcowe powinny mieć z góry założone limity i zwracać tylko konkretne dane a nie zrzut np.