Wpis z mikrobloga

@czlowiek_z_lisciem_na_glowie: a to nie jest tak, że stara się powoli odchodzić od czystego SPA na rzecz mieszanego podejścia? Na pewno nie chciałbym, żeby wykop poszedł w stronę reddita. SPA pozwala ci na osiągnięcie złożonych funkcjonalności co często jest słabe z perspektywy użytkownika końcowego, bo nie obchodzą mnie (tak jak na reddicie) customizację awatarów albo wyskakującego okienka tylko szybkie i przejrzyste przeglądanie strony
@czlowiek_z_lisciem_na_glowie: no ale nikt nie powiedział że SSR to generowanie w PHP po stronie backendu. Wręcz przeciwnie. Teraz dąży się do rozdzielenia warstw i osobno masz frontend oraz backend. Backend wystawia zwykłe API z którym może się połączyć dowolny klient (aplikacja webowa, aplikacja mobilna, aplikacja desktopowa czy nawet inne zewnętrzne API które chce się zintegrować) a frontend jest osobnym bytem.

SSR to generowanie HTMLa po stronie serwera Node.js, który serwuje całą
Hmm więc jaka jest przewaga tego nad generowaniem całego HTML w backendzie w PHP?


@czlowiek_z_lisciem_na_glowie: ekosystem JSa. Framworki/biblioteki JSowe są generalnie uważane za dobre narzędzia do robienia UIów. No i jak będziesz musiał napisać kod, który jednak jest uruchomiony na przeglądarce to masz wspólną bazę kodową
@czlowiek_z_lisciem_na_glowie: generalnie to zależy od ustawienia i podejścia. Są witryny gdzie router wykonuje normalne zapytanie HTTP po daną stronę, Node.js generuje wtedy stronę i odpowiada jak w zwykłym klasycznym podejściu ale najczęściej spotyka się sytuację gdzie za pierwszym wejściem na dany url strona jest zaciągana jako SSR a później już klient ma wszystkie assety do tego żeby user na kolejnych widokach poruszał się już po SPA czyli wewnętrznym routingu aplikacji i