Czemu SPA (Single Page Application) to zło?

1

Czytając wątek Przepiszmy 4programmers/coyote do .net core 4fun natknąłem się na opinie że SPA jest do niczego. Trend stosowania SPA na stronach WWW można zauważyć już od wielu lat. Weźmy na przykład systemy transakcyjne banków. Większość z nich (które widziałem) to SPA.

Nie mówię że SPA to coś złego, nie jestem ich przeciwnikiem. Jako osoba która pisze również w JS, muszę powiedzieć, ze frameworki takie jak Angular czy React zrewolucjonizowały rynek. Pamiętam jak wiele lat temu nowością był jQuery. Również była to swego rodzaju rewolucja, jednak porównując jQuery a obecne frameworki JS to jak niebo a ziemia.

Sporo obecnego kodu 4programmers.net to legacy code w jQuery. Kod jest niestety paskudny i ciężki w utrzymaniu. W SPA dostrzegam jedną wadę, a mianowicie gorsze indeksowanie przez boty i "lag" który jest zauważalny przez ładowanie strony. Jest jednak coś takiego jak SSR (Server Side Rendering), który eliminuje ten problem.

Jaka jest Wasza opinia w tej sprawie?

1

(Patrząc na aktualne 4P)

Zadajmy sobie pytanie - na jakie obszary 4P dodanie dużej dynamiczności wpłynęłoby najbardziej?

Obstawiam:

  • Przechodzenie pomiędzy stronami w temacie.

  • Przechodzenie pomiędzy stronami na mikroblogu.

Czy zysk jest duży? nie wiem, wydaje mi się, że bardziej takie rzeczy sprawdzają się w miejscach gdzie się coś ogląda (obrazki/memy) niż czyta dyskusje.

Ale na pewno warto eksperymentować! :)

edit. Chociaż teraz się zastanawiam, czy SPA implikuje dynamiczność...

6

Podaj jakąkolwiek technologię czy podejście do programowania a zawsze znajdzie się grupka ludzi dla których to zło wcielone, oraz taka dla których to złoty środek na wszystkie problemy tego świata. Problem leży w tym, a nie w używaniu SPA samego w sobie (czy też nie używaniu). Zarówno SPA jak i tradycyjne strony mają swoje wady i zalety- o niektórych sam wspomniałeś. Kwestia wybrania odpowiedniego podejścia do danego problemu. Chociaż myślę że w przypadku SPA vs tradycyjna strona to duże znaczenie ma po prostu to w czym nam się wygodniej będzie to robić. Sklep internetowy, bank czy nawet forum mogą działać dobrze zarówno w jednym jak i w drugim. Koniec końców to tylko narzędzie.

1

Myślę, że ten hejt na SPA jest podobny do mojego "hejtu" na JWT. JWT to fajne rozwiązanie w pewnych sytuacjach, ale pchanie go wszędzie na siłę to głupota. Podobnie ze SPA - wg mnie to forum by ucierpiało, gdyby przeszło na SPA. Fakt, że za każdym kliknięciem serwer musi wyrenderować stronę i przesłać masę powtarzalnych elementów (nagłówek, stopka, wszelkie powtarzające się elementy w obrębie jednej strony), ale koniec końców dostaję odpowiedź w 100, góra 200ms.
Przy serwisach, na których jest spory ruch, SPA pozwala przerzucić część pracy serwera (renderowanie szablonów) na klienta, ale jak wszyscy wiemy, przedwczesna optymalizacja nie jest dobra :) więc trzymamy się zasady, że jeśli coś działa, to tego nie ruszamy.
Jeśli chodzi o legacy kod w jQuery to Reacta można użyć do części elementów na stronie, a resztę zostawić tak, jak jest. Dzięki temu nie musimy się kopać z problemami typowego SPA - routing, żmudne klepanie formularzy, oskryptowanie każdego, nawet najbardziej banalnego buttona itp., a dynamiczne elementy (np. gdybyśmy chcieli zrobić paginację w tematach bez przeładowywania strony) mamy elegancko napisane w najnowszych technologiach.

3

Czasami SPA nie ma sensu, bardziej bym widział połączenie hybrydowe, czyli jakiś dynamicznie ładowany content ajax'em, reszta normalnie, nie trzeba do tego pierdyliarda paczek, opasłego frameworka, nie ma problemu z seo, nie produkujesz pińcet komponentów z oddzielnym css, aby to potem i tak zamknąć w ciężkiej paczce js :)

SPA sprawdza się np. w portalach ogłoszeniowych gdzie masz sporą interakcję z userem, wybierasz pola, zmieniasz wartości, a potem zasysasz dane z bazy i tyle.

Najgorsze potworki to SPA bez optymalizacji, gdzie js zajmuje po kilka MB i cpu się smaży na 100% niestety i tak trzeba przy tym posiedzieć, a nie każdy umie/ma chęci.
Czasowo wygląda to gorzej jak MVC+PWA, więc nie zawsze starcza godzin na dopieszczenie projektu i wychodzi kobyła :/

2

SPA ma niezaprzeczalne zalety: 1) HTML+CSS+JS jest ściągany tylko raz, później tylko przesyłamy małe porcje danych do serwera i z powrotem. 2) nie ma potrzeby trzymania danych w ciasteczkach, storage, submitownia formularzy itd. ponieważ nie przechodzimy pomiędzy stronami. 3) aplikacja jest bardziej responsywna dla użytkownika i sprawia wrażenie, że pracujemy z aplikacją desktopową.

Jednak nie ma rzeczy, które są uniwersalne. SPA sprawdziło się w przypadku Gmaila, ale niekoniecznie sprawdzi się w przypadku forum. Gmail nie musi się indeksować, a forum już powinno. Z tego względu imho jeżeli SPA na forum to tylko razem z SSR.

1

Nawet zobaczmy takie "lekkie" vue.js, które po zaciągnięciu podstawowych paczek (axios, ui itp.) prościutki projekt todo zajmuje 140MB, po zrobieniu builda js zajmują z 140kb, a to czysty text praktycznie :)
Dodatkowo budowanie componentów jest dosyć pracochłonne, to nie mva gdzie wrzucisz widoki, możesz też w ajaxie, potem formularz, dajesz cache back+front i gotowe, zostaje ci sporo czasu na dopieszczenie tematu.
Ostatnio nawet widziałem projekty pewnej firmy w vue (średniej wielkości strony) to szału nie było, ale jak ktoś za to płaci dodatkowo to wiadomo, czemu nie, nie mi osądzać.

8

Ja najbardziej lubie proste minimalistyczne strony ktore dzialaja szybko. Moze byc brzydkie pod spodem :)

SPA nie lubie bo (wiem ze teoretycznie wiekszosc tych rzeczy mozna wyeliminowac, ale przewaznie one tam po prostu sa):

SPA nie lubi wolnych laczy i slabych urzadzen.
Wkurza mnie (np na Quora) jak jest dluuuuuugi watek a pod nim cos co chce kilknac i nie moge bo strona sie ciagle doczytuje. Zreszta bardzo nie lubie jak mi sie cos na stronie przesuwa po wyswietleniu. Ktos to podsumowal w prezentacji otwieramy lodowke, siegamy po mleko a tu nagle spadaja nam z gory jajka ktore niechcacy rozbijamy.
Wkurza mnie jak to co idzie do przegladarki od razu jest duze, bo ze wzgledu na TCP slow start dluuuugo sie czeka az sie strona wyswietli i tutaj nawet mocne lacze nie pomaga.
Wkurza mnie jak nie dziala "back" w przegladarce.
Wkurza mnie cizekosc tych stron i zuzycie zasobow do ich wyswietlania.
Wkurza mnie jak traci sie pozycje scrolla i trzeba ponownie przewijac. (np. jak zrobimy refresha)
Wkurza mnie ze czesto jak chcemy otworzyc w nowej zakladce, dostajemy to co w aktualnej tylko przewiniete na poczatek. Ogolnie nawigacja jest utrudniona.

... ale strony w czystym Flashu sa jeszcze gorsze :)

4

Podpisuję się pod wszystkimi punktami @WhiteLightning :) Dodam jeszcze wirtualizację długich list, która psuje Ctrl+F przeglądarki.

0
WhiteLightning napisał(a):

SPA nie lubi wolnych laczy i slabych urzadzen.

To też jest problem na urządzeniach mobilnych zwłaszcza, drenuje cpu = baterie, plus niestety u nas pakiety internetowe nadal są dosyć drogie, więc jednak jest różnica jak strona ładuje, zamiast startowej, wszystkie zasoby nawet jak ich nie będziemy oglądać.

0

@czysteskarpety:

Podejście hybrydowe jest fajne i chyba wymagałoby najmniej pracy.

Nadal forum byłoby renderowane na serverze, ale np. przechodzenie w wątku odbywało się dynamicznie stosując

a) renderowanie jsem

lub

b) wstrzykiwanie w stronę wygenerowanego htmla (np. posty), a cała reszta już jest.

1
WeiXiao napisał(a):

@czysteskarpety:

Podejście hybrydowe jest fajne i chyba wymagałoby najmniej pracy.

Ponadto 4p ma prawie 200 requestów (w tym z różnych portali, reklamy itp.), jest spory rozrzut co widać tutaj:
https://requestmap.herokuapp.com/render/190412_0Z_98dc8064cec15911eb4744fdc17d1ff0/
więc cudu nie będzie, pewnie sporo też cache'uje cloudflare, więc ponownie nie ładuje się z 70-80% contentu, widać to nawet po navi, że nic nie "mruga" więc nie ma specjalnie jakiegoś "ciężkiego" przeładowania zasobów przy zmianie treści.

0

Tu macie jeszcze jeden minus SPA. Otworzcie sobie agende konferencji: https://4developers.org.pl/warszawa/#agenda

I sprobojcie porownac godzina po godzinie ktory wyklad warto bylo wybrac albo na ktorym sie bylo. Az sie marzy zeby to bylo w statycznej tabelce.

5

SPA to upodobnienie aplikacji przeglądarkowych do desktopu pod kątem interfejsu użytkownika (desktop nie przeładowuje strony).
SPA to odpowiedź na tendencję rynku do przechodzenia z aplikacji desktopowych do aplikacji odpalanych w przeglądarce.
Jeżeli ktoś twierdzi, że SPA jest złym rozwiązaniem to po prostu nie rozumie w jakim kierunku podążają aplikacje www i rynek it.

Strony, które wymagają indeksacji, nie potrzebują spa, bo to nie są aplikacje, tylko strony wyświetlające treść, aplikacja to coś bardziej zaawansowanego.
SPA to single page application, a nie single page website.
Nie ma potrzeby, żeby zawartość bloga wyświetlać w SPA, ale zarządzanie nim, można jak najbardziej zrobić w SPA.

0
omenomn napisał(a):

Jeżeli ktoś twierdzi, że SPA jest złym rozwiązaniem to po prostu nie rozumie w jakim kierunku podążają aplikacje www i rynek it.

Nikt nie twierdzi, że SPA jest złym rozwiązaniem, tylko nie zawsze jest najlepszym.

3

Do React jest nadbudówka: https://nextjs.org/ - ma specjalne wsparcie dla SSR, statycznych stron, automatic code splitting (a więc JS, CSS, etc jest podzielony na małe kawałki i dociągany w razie potrzeby), itd W praktyce prawdopodobnie i tak ktoś dorzuci gdzieś megabajtowy skrypt JS i cała magia kompaktowego kodu wynikowego pryśnie, ale te megabajtowe skrypty zdarzają się niezależnie od wybranego frameworka. Odpaliłem sobie Forum dyskusyjne w trybie incognito w Chrome i odświeżyłem stronę za pomocą opcji "opróżnij pamięć podręczną i wymuś ponowne załadowanie". Efekt? 984 KB transferred, 2.6 MB resources. Lekkie to to forum nie jest. Z drugiej strony, możliwe że większość transferu zjadły reklamy.

0

Sprawdź http://dev.4programmers.info/Forum gdzie nie ma reklam żadnych. 30 req i 300 kB. Natomiast na produkcji 130 req :/

0
Adam Boduch napisał(a):

Sprawdź http://dev.4programmers.info/Forum gdzie nie ma reklam żadnych. 30 req i 300 kB. Natomiast na produkcji 130 req :/

screenshot-20190415113334.png

372 KB i to pewnie po kompresji, bo jest 880 KB resources.

Na pewno plus jest taki, że nie ma laga spowodowanego ładowaniem masy JavaScriptu na starcie. Z drugiej strony przy słabym necie ściąganie 372 KB danych trochę potrwa, a SPA niekoniecznie musi ważyć dużo więcej.

0
Wibowit napisał(a):

Z drugiej strony przy słabym necie ściąganie 372 KB danych trochę potrwa, a SPA niekoniecznie musi ważyć dużo więcej.

To zobacz np. justjoin.it 5-7MB i kilkadziesiąt sekund łącznie :)

2

To jeszcze trochę zależy jak to SPA jest zrobione. Bo jeżeli mam przed sobą wynalazek, w którym:

  • nie da się otworzyć podstrony o nowej karcie,
  • nie działa "back",
  • nie da się zapisać adresu aktualnie przeglądanego miejsca, żeby tam wrócić,
  • strona doładowuje kolejne pozycje w nieskończonym ciągu, nie informując ile ich w sumie jest i nie posiadając przy tym żadnej paginacji.

To nie jest to żadne polepszenie, tylko zwyczajna tragedia.

Poza tym bywa, że chcę przeglądać jakąś stronę z wyłączonym JS i/lub CSS i efekty bywają wtedy dziwaczne do tragicznych.

Poza tym, jeśli dla wyświetlenia np. nowej podstrony forum czy listy produktów używa się JS, to bywa to dezorientujące, bo jeśli klikam w link, to oczekuję, że będzie zachowywał się jak link.

Poza tym (tak trochę na marginesie tematu) wk... animacje przed / zamiast treści. To akurat obecnie najczęściej nie wina SPA tylko gotowych (i nadużywanych) szablonów CSS/JS, które "ożywiają" strony, które później zamiast gotowej treści oferują mi "radosny kalejdoskop" przed jej wyświetleniem. Ale w przypadku SPA też bywa tak, że proste przeładowanie strony trwałoby krócej niż "kreatywna i ożywcza" animacja z dynamiczną podmianą treści.

1

Dla mnie SPA ma jedynie sens jeśli celem jest uzyskanie możliwości pracy w trybie offline. W przeciwnym razie wszystko to co oferuje SPA to przerost formy nad treścią.

Poza tym użycie React absolutnie nie oznacza, że właśnie tworzymy SPA. Co stoi na przeszkodzie, by mieć kilka widoków/stronek tak jak w tradycyjnym podejściu? React po prostu ułatwia renderowanie komponentów i tyle - aż tyle.

2

Dorzucę jeszcze, że stosowanie SPA (podobnie jak AMP) jako remedium na wolno ładujące się strony, to zwykle rozwiązywanie problemu do d... strony.
"Nasadziliśmy od cholery zamulających skryptów, frejmłorków, bibliotek i zbędnych warstw abstrakcji. Więc nasadźmy jeszcze jedną, która przerzuci przetwarzanie całego tego szrotu na komputer użytkownika albo kolejnego pośrednika".

1
Freja Draco napisał(a):

Dorzucę jeszcze, że stosowanie SPA (podobnie jak AMP) jako remedium na wolno ładujące się strony

Ale SPA stosuje się głównie oby odciążyć serwer, który też kosztuje i mniej angażować backendowców, którzy też kosztują i dorzucić pracy frontowi, który nie miał dotąd za bardzo co robić (a i tak trzeba płacić) prócz zabawy z pixelami.
Prędkość nie ma tutaj aż takiego znaczenia, bo jest w znacznym stopniu zależna od sprzętu użytkownika.

4

Pracuję w projekcie, gdzie interfejs jest ciężki i dynamiczny. Przerzucenie renderowania, danych sesyjnych i ich mielenia na stronę użytkownika znacząco polepsza skalowalność. Nasz dotychczasowy framework ma tendencję do zapychania się. Po stronie serwera generujemy aktualizacje interfejsu, czyli głównie wyrenderowane kawałki HTMLa, które są potem podstawiane w DIVa o odpowiednim ID. Jeśli wleci nam do systemu dużo zdarzeń, które wyzwalają takie aktualizacje i ich odpowiednio nie przydusimy (throttling etc) to aktualizacje te będą się kolejkować po stronie serwera (bo nie będziemy nadążać z wysyłaniem) i szybko braknie RAMu, co powoduje bliskie 100% CPU obciążenie garbage collectorem. Jesteśmy w trakcie migrowania się do SPA w Reactu i w tym przypadku nie będzie żadnego kolejkowania aktualizacji interfejsu. Frontend będzie sobie pytał backend co jakiś czas o aktualizacje i dorzucał je do swojego stanu (co wiąże się z np ponownym sortowaniem, segregowaniem, stronicowaniem, przemapowaniem danych, etc). Backend natomiast nie musi trzymać żadnych danych sesyjnych oprócz listy żywych sesji, co powoduje, że naraz może być zalogowanych masa użytkowników, a jednocześnie my (backendowcy) nie musimy bać się, że nam serwer wybuchnie bo zabraknie mu RAMu.

1
Wibowit napisał(a):

screenshot-20190415113334.png

372 KB i to pewnie po kompresji, bo jest 880 KB resources.

Używamy bootstrapa oraz fontawesome i jquery. Trochę kodu to jest:

  • jQuery: ~30 kB
  • font-awesome: 75 kB
  • vendor: 73 kB

Z kolei w dziale Praca użyty został Vue. To jest właśnie ta hybryda o której mówił @czysteskarpety.

5

TL;DR

SPA służy do budowania aplikacji. Aplikacji. Dlatego jest szybkie, ale słabo indeksowalne.
4programmers jest bardziej stroną www o ile założymy że ma być wyszukiwalne, być repozytorium wiedzy do której kiedyś ktoś może wrócić (takie polskie SO).

Ja bym tu jednak stawiał na maksymalne cachowanie - włącznie z tym na dysku serwera (w formie HTML lub JSON), w końcu post / wątek raz zapisany się nie zmienia w zależności od dnia. A na pewno dotyczy to działu Kompendium.

Jeśli 4p ma być miejscem czatowania, flawe wars i lajkowania to SPA się tu sprawdzi.

2

Czyli forum jest napisane przez wielu programistów używających różnych technik, narzędzi bez jednej wspólnej koncepcji.
Jak większość projektów na Polskim rynku :p

Wydaję mi się, że ludzie, którzy mówią, że spa to ma sens tylko i tylko wtedy gdy... np. ma działać offline, to są ludzie, którzy żadnego spa w życiu nie napisali i nawet nie mieli styczności z routingiem jsowym jak np. router vuejs, a już do user experience to w ogóle mają podejście w stylu, a co mnie to obchodzi, działa to jest okej.

Youtube jest SPA i jest indeksowalny i normalnie pojawia się w google w wyszukiwaniu. Bierzmy przykład od najlepszych i podążajmy za nimi zamiast wymyślać jakieś swoje dziwne teorie.

Może takiego forum nie ma potrzeby robić w spa, bo rzeczywiście to nie aplikacja, ale można i to też będzie super rozwiązanie.

Człowiek jak czegoś nie zna to neguje przeważnie.

5

Youtube jest SPA i jest indeksowalny i normalnie pojawia się w google w wyszukiwaniu. Bierzmy przykład od najlepszych i podążajmy za nimi zamiast wymyślać jakieś swoje dziwne teorie.

YouTube zwraca innego HTMLa dla przeglądarek i innego dla botów. W wersji dla botów ma np statycznego HTMLa zawierającego opis filmu czy link do kanału autora.

1 użytkowników online, w tym zalogowanych: 0, gości: 1