1.01 (1) SSR, SSG, SPA czy MPA?

Cześć! Witam Was serdecznie w naszym podcaście Piwnica IT. Dzisiaj chcielibyśmy porozmawiać na temat SSR-a, technologii SSR-owych we współczesnym dewelopmencie webowym. W szczególności poruszyć temat Remixa, Nexta, Gatsby'ego. Natomiast, żeby to wszystko pięknie wyglądało, chciałbym, żebyśmy się troszeczkę poznali. Dzisiaj jest ze mną człowiek niebanalny, pomimo młodego wieku bardzo świadomy, świetny kompan do żartów, dyskusji, nie tylko o świecie IT. Poznajcie Wojtka, JS-owego ogarniacza, któremu niestraszne najdziwniejsze refaktoryzacje. Cześć Wojtek. Cześć Mateusz. Nie wiem czy wszyscy już Cię znają, więc pozwól, że przedstawię Cię tym, którzy jeszcze o Tobie nie słyszeli.

Mateusz to świetny przyjaciel zarówno w pracy jak i po. Posiada szeroką wiedzę o najróżniejszych zakątkach świata programowania. Poznajcie Mateusza, mentora programistów, typescriptowego ninja, który zjadł zęby na wielu frontendowych aplikacjach. Ale mi posłodziłeś. Cześć. Chcielibyśmy dzisiaj porozmawiać o SSR, czyli Server Site Renderingu. W ogólnym ujęciu chcielibyśmy na początku ugryźć temat, co to w ogóle jest, jaka jest tego przyszłość, jaka jest teraz obecna pozycja SSR-a w kontekście aplikacji typu SPA, aplikacji typu SSG. Jakie jest Twoje zdanie, Wojtek, na ten temat? Na pewno masz dużo doświadczenia z SSR-em, zresztą we współczesnym dewelopmencie

A co ty sądzisz? Wiesz co, ja dość dużo pracuję z SSR-em tak naprawdę i się totalnie zgadzam z tym, że to jest takie nowe MPA. W zasadzie już od wielu lat wydaje mi się, że odgrzewamy stare kotlety, próbujemy wymyślić coś nowego, tak jak było w przypadku SPA, czyli wymyśliliśmy coś nowego, żeby przenieść z jednej strony aplikację na 1.01 1 SSR, SPA czy MPA?.

Nie spełniło do końca swojej roli na rynku, w szczególności pod kątem SEO, pod kątem mediów społecznościowych i tego, jak w ogóle rozwija się internet. Więc z tej perspektywy na pewno powrót do czegoś, co było podobne do MPA, czyli do SSR-a, stał się czymś naturalnym. I wydaje mi się, że ten SSR w takim ujęciu, w jakim jest w tym momencie, jest w zasadzie 1.01 1 SSR, SSG, SPA czy MPA?. 1.01 1 SSR, SSG, SPA czy MPA?. 1.01 1 SSR, SSG, SPA czy MPA?.

1.01 1 SSR, SSG, SPA czy MPA?. Z każdym z tych trzech rodzajów aplikacji spotkamy się. Nawet mamy MPA na rynku w dalszym ciągu. Z każdą z tych aplikacji spotkamy się tak naprawdę. Czy bazując na Twoim doświadczeniu, na tym co już tak naprawdę zrobiłeś i znasz każde z tych podejść tak naprawdę, jak myślisz, do których projektów najlepiej by było wybrać

Jest to jakiś dashboard, są to jakieś wykresy. 1.01 1 SSR, SSG, SPA czy MPA?. Jak media społecznościowe, czy coś w stylu Airbnb, czy innych platform zajmujących się powiedzmy wynajmem mieszkań, właśnie tam skorzystałbym z technologii. A Ty Mateuszu, masz inne zdanie na ten temat? W zasadzie chyba nie. Jeśli chodzi na przykład o

Więc warto by było też to przemyśleć, wydaje mi się, co my chcemy zrobić, jak chcemy pewne integracje przygotować. Tu z tej perspektywy na pewno cenię sobie Nexta za to, że daje nam takie właśnie jednocześnie, oprócz SSR-a i oprócz podejścia hybrydowego, czyli tak naprawdę możliwość wyboru, czy my chcemy widoki mieć SSG, czy chcemy widoki SSR, daje nam też opcję na to, że Możemy sobie własne API na przykład stworzyć, więc możemy sobie stworzyć własny taki, że tak powiem ładnie backend for frontend w naszej aplikacji, który tak naprawdę może nam te newralgiczne elementy aplikacji ukryć, można je odpowiednio zabezpieczyć.

I w tym ujęciu na pewno się zgadzam w stu procentach z tobą. Więc aplikacje takie biznesowe, myślę, że SPA, zdecydowanie SPA. Takie, gdzie użytkownik zewnętrzny nie musi wejść. Natomiast aplikacje klienckie, gdzie mamy też duży narzut w postaci pozycjonowania, w postaci właśnie mediów społecznościowych, w postaci jakiejś widoczności z dodatkowymi ustawieniami, to myślę, że SSR zdecydowanie będzie tutaj najciekawszą opcją. Zgadzam się z Tobą w 100%. Myślę, że tu jest kwestia z tego, jak dużo interakcji, jak bardzo chcemy, żeby interaktywna była, czy też był ten produkt, który tworzymy, czy też ta aplikacja internetowa, którą tworzymy. Myślę, że to głównie powinno decydować to, z jakiej technologii skorzystamy.

Ale jeśli już mówię, To jakikolwiek jest tutaj... Tak, dokładnie. Ale tu też nie mówimy o technologiach takich typu HTML. To nie jest tak, że piszesz to od nowa. Tylko korzystasz z jakichś gotowych rozwiązań. No nie. Korzystasz z gotowców po to, żeby szybko dostać... Celem jest czas. To jest waluta w tym momencie, w takim biznesie. Więc tak, ja się zgadzam, że jeżeli chcemy zrobić coś fajnego, to taki SSR będzie ciekawszym rozwiązaniem. Ale na przykład, bo trochę odbiegliśmy od tematu. Jeżeli chcemy zrobić jakąś stronę, wybieramy SSG chociażby, to SSG sprowadza się do tego, że ty piszesz w React, ale docelowo będziesz miał statyczne strony w HTML czy CSS, które będziesz hostował na serwerze.

I tutaj zgadzam się, że te podejścia właśnie, o których wspomniałeś, czyli między innymi WordPress, 1.01 1 SSR, SSG, SPA czy MPA?. Albo stwierdzenie, że okej, nie potrzebujemy żadnych technologii i zwykły HTML będzie wystarczający, bo mamy gdzieś tam prostego landing page'a, nie przewidujemy, że będzie tam potrzebny jakikolwiek CMS. No myślę, że oboje byśmy wybrali właśnie jedną z tych technologii, o których rozmawiamy dzisiaj. Myślę, że raczej nie piszę byś tego od nowa, wiesz, po prostu w czystym HTML-u, tak?

I porównując Nexta na przykład z Gatsbym, wydaje mi się, że większość wybierze Nexta, bo Next więcej oferuje. Więc ten Developer Experience daje większą swobodę. To podejście hybrydowe da nam większą swobodę niż przy Gatsbym. Zgadzam się z Tobą. Mamy narzędzie Gatsby'ego jako Do tego miejsca, w którym Gatsby jest, czyli do budowania prostych, szybkich, dynamicznych stron, to tutaj może się pojawić ta rozbieżność. Czy to będzie bardziej MPA, czy to będzie bardziej SSR? Nie chodzi nam o całą technologię, o podejście do technologii, tylko bardziej, w którą stronę to przypisać. Więc biznesowo ten Gatsby mi się nie klei.

Tak, więc myślę Mateusz, że nie wrzucę bym Swelta do jednego worka, bo jest to o tyle problematyczne, że to jest trochę inna rzecz, ale jeśli chodzi o Developer Experience, o którym właśnie wspominasz, słyszałem dużo dobrego od innych deweloperów i wiele osób sobie chwali te rozwiązania, które tam są, chociaż mi osobiście on też nie bardzo się podoba i tak jak wspominałeś przypomina Vue, które też nie bardzo mi się podoba. Więc jest to rzecz zdecydowanie ciekawa. Jeśli chodzi o inne technologie, takie jak Remix chociażby, jest on bardzo ciekawy i osobiście chyba najbardziej mi się podoba. Jeśli ja miałbym dzisiaj właśnie stworzyć taki projekt SSR-owy powiedzmy, to właśnie skorzystałbym z Remixa.

Na przykład w Reaktcie w tamtym czasie był ten case dosyć słynny, gdzie był taki dość wątpliwie rozumiany zapis, który mówił według niektórych, że wszystkie narzędzia, wszystkie rzeczy napisane z wykorzystaniem Reacta 1.01 1 SSR, SSG, SPA czy MPA?.

Tak naprawdę. Więc mi się wydaje, że jakbyśmy spojrzeli na to, co ludzie wybierają, co ludzie wybierają pod kątem jakiejś sympatii bardziej, emocji. A czy my wybierzemy remixa, reacta, nexta? No nexta, to jakbyśmy wybrali reacta. Jeżeli wybierzemy reacta, Będziemy potrzebowali SSR, to wybierzemy Nexta. Jeżeli SSG, to weźmiemy Gatsby'ego, bo też jest React. Tak mi się wydaje. Jeżeli nie będziemy sympatyzować z polityką Facebooka, to w życiu nie wybierzemy. Nasza firma w życiu nie wybierze Reacta. Biznesowo nie zgodzą się na to. Pójdziemy w stronę Google. Największe korporacje wybierają Google'a,

I Angulara wydaje mi się z dwóch powodów. Z jednej strony, to jest zatem olbrzymia firma, gigant, że tak powiem, technologiczny, który bardzo dużo inwestuje w ten produkt i na dzień dzisiejszy można powiedzieć, że uczynił go dość stabilnym. Początki były słabe, ale można powiedzieć, że na dzień dzisiejszy Angular jest stabilnym, dojrzałym produktem, który wydawany jest, kolejne wersje są wydawane w regularnych cyklach półrocznych, Naprawdę ten produkt już się nie zmienia aż tak. To nie jest to, co było pomiędzy RC5 a RC6, że wywalamy wszystko i wpiszemy od początku. Na ten moment jest to stabilne rozwiązanie. I tak samo jest chyba, jeśli chodzi o Reacta, bo w tym momencie wybieramy Reacta, ale czy my wybierzemy Nexta, Gatsby'ego czy czystego Reacta, to tak jakbyśmy wybierali SPA, SSG czy SSR.

Chcesz sympatyzowania z czymś, nie? Tak mi się wydaje. Zdajesz sobie sprawę, że Remix to jest 3, jak tak na dobrą sprawę? Tak, wiem. Tak, zdaję sobie z tego sprawę. Nie umiem go jeszcze umiejscowić, tak naprawdę. Nie wiem, czy to jest bardziej SSR, bardziej SSG, czy to jest bardziej SPA, bo powiem, no aż tak jeszcze nie zagłębiałem się w ten temat. Ok, chcę się upewnić tylko. Ale ogólnie tak, zgadzam się z Tobą. Myślę, że tych technologii jest tyle. Rzeczywiście jest to wybór pomiędzy dużymi firmami. Jest to moim zdaniem ciekawy model biznesowy.

Super ciekawy pomysł na nie jako startup, czyli stworzenie właśnie takiego frameworku czy też biblioteki tak dużej, że wiesz może się przerodzić to w taką dużą firmę, tak jak to było z Nexem czy ze Stripe'em, więc spoka rzecz. Czyli co, ty dzisiaj byś wybrał Nexta? Jeśli byś pisał taką właśnie stronę, miałbyś takie wymaganie stworzenia takiej strony w stylu SSR? Jeśli bym pisał stronę internetową na przykład dla naszego podcastu i miało to być SSR, to wybrałbym Nexta, bo Developer Experience mi się podoba. Aczkolwiek Nie pracowałem z Remixem, a wiem, że bardzo go chwalisz, więc może.

Może to jest dobry moment. Może to jest dobry moment. Kto wie, możemy spróbować. Spróbować coś napisać razem i na jakimś żywym produkcie to wykorzystać. Natomiast tak teraz jeszcze chodzi mi po głowie jedna kwestia. No bo rozmawiamy sobie o tym SSR-ze, rozmawiamy sobie o SSG i SPA, rozmawiamy o tym, jaki to ma wpływ tak naprawdę na pozycjonowanie, na developer experience, na media społecznościowe, jak użytkownicy to wybierają, a jaki to ma wpływ na performance. Zastanawiałeś się nad tym? Czy te wszystkie wskaźniki performance'owe, takie jak np. time to first byte albo

Albo wszystkie inne, które są bezpośrednio powiązane z performance'em, z wydajnością. Która z tych podejść może być dla nas najciekawsza, jeśli chodzi o wydajność? Myślę, że tutaj znowu Remix wygrywa. Ale jeśli chodzi ogólnie o te matryki, myślę, że jest to wszystko powiązane. A Remix to będzie... Remix to będzie Wojtek... SSG czy SSR? Myślę, że ja powinienem zmienić może imię i nazwisko. Wojciech Remix. Brzmi całkiem nieźle. Wojciech Remix. Serio, myślę, że są to ważne metryki, dlatego, że jest to bardzo powiązane ze sobą, a przede wszystkim powiązane z SEO i Googlem. Właśnie jak takie metryki performance'owe wpływają na to, jak nasza strona jest pozycjonowana.

I mają chyba jeden z największych wpływów na to, jak nasza strona szybko się załaduje. Poza tym, Jeszcze inne rzeczy, typu jaki jest czas odpowiedzi z serwera. Przy SSR na pewno będzie dłuższy. SSG będzie szybszy, no bo dostarczamy tylko i wyłącznie HTML, CSS. Jeszcze mamy ten czas, który musi przeglądarka poświęcić na przygotowanie, na skryptowanie całego tego naszego, całej naszej aplikacji. Więc ten performance mi się wydaje, że my powinniśmy też ugryźć z tej perspektywy Pozyskamy klienta, ok, niech to SEO sobie tam działa, ale teraz jak go utrzymać, żeby go nie zniechęcić, żeby te magiczne 700 milisekund, które mamy na dostarczenie wartościowego contentu dla użytkownika rzeczywiście zostało osiągnięte.

Tak, że nie wiem czy w sumie jest coś takiego C2C, nieważne. W każdym razie B2C jest mega ważne, bo to koniec końców może naprawdę ogromnie wpływać na to jaką konwersję użytkowników uzyskujemy i ile pieniędzy zarabiamy, koniec końców. No tak, jak nie wiadomo o co chodzi to chodzi o pieniądze. Dokładnie tak. Wojtek. To jeszcze jest kwestia, jeszcze pozostaje nam kwestia jedna, nie rozstrzygnięta. Rozmawialiśmy sobie o SSR, rozmawialiśmy sobie o SSG, o SPA, o MPA, a gdzie tu umieścić najnowszy pomysł Reacta? Czyli jak pewnie sobie zdajesz sprawę, co mam na myśli, React Server Components.

Bo ja na tą koncepcję patrzę w tym momencie tak, że nie jest to SSR według tego, co Jest to komponent, który de facto będzie przekształcany do jakiegoś prostego streama, prostego tekstu, który będzie można później sobie sparsować na komponent i wykonać tam hydratację danymi na poziomie już przeglądarki. W teorii Z tego co rozumiem, idea jest taka, że komponenty serwerowe mają znaleźć się po prostu bliżej źródła danych, czyli bliżej bazy, czy po prostu bliżej źródła danych, więc tak naprawdę bliżej serwera w większości przypadków.

Rozwiązania bezpośrednio optymalizacyjne pod Reacta. Tak naprawdę nie jest to żaden game changer w stylu wprowadzenia nowego podejścia, wprowadzenia nowego sposobu tworzenia aplikacji. Tak jak sami mówią, nie jest to SSR. Myślę, że to jest po prostu czy też będzie po prostu kolejna jakaś tam opcja, kolejne narzędzie w twoim zestawie narzędzi, z którego będziesz mógł skorzystać. No i wygląda to jak po prostu fajny dodatek, który będzie można wykorzystać w jakichś tam specyficznych miejscach, ale który wiąże ze sobą czy też niesie ze sobą dużo ciekawych właśnie pomysłów i sposobów na optymalizację kodu.

Okej, Wojtek, mamy jeszcze jeden temat, który nam został. Poruszyliśmy w zasadzie na samym początku case tego, że mamy do dyspozycji właśnie SSR, SSG i SPA. Mówiliśmy też o tym MPA naszym, czyli tym Multi-Page Application. O ten nieszczęsny WordPress zahaczyliśmy. Ten WordPress na rynku, tak jak patrzyłem na statystyki w zeszłym roku, to jest około 70% aplikacji stron internetowych, czy blogowych, czy firmowych, tak naprawdę pisanych w oparciu o WordPressa, nadal na rynku. Wiadomo, proporcja się zmienia. Prawdopodobnie docelowo na niekorzyść WordPressa.

Adwentu tych technologii, o których rozmawiamy, które by były idealne jako alternatywy WordPressa w połączeniu z jakimś rozbudowanym systemem CMS i dużym katalogiem gotowych template'ów. Właśnie ponoć do Gatsby'ego jest tworzony zbiór template'ów, ale jest on dość ubogi. Więc z tej perspektywy, no ten system template'ów i plugin'ów w WordPressie wygrywa wydaje mi się w dalszym ciągu. Jeśli chodzi o headlessy, czyli te CMSy headlessowe, które np. pod takie rozwiązania, o jakich dzisiaj rozmawiamy, czyli o rozwiązania typu SSR, SSG czy SPA, to takie CMSy headlessowe mają wielki sens i dają często dużą swobodę użytkownikom.