Mateusz: Cześć, witam was serdecznie na naszym podcaście Piwnica IT. Dzisiaj chcielibyśmy porozmawiać na temat SSR, technologiach SSRowych we współczesnym developmencie webowym, w szczególności poruszyć temat Remix'a, Next'a, Gatsby'iego. 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 - JSowego ogarniacza, któremu nie straszne najdziwniejsze refaktoryzacje. Cześć Wojtek.

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 ninję, który zjadł zęby na wielu frontendowych aplikacjach.

M: Ale mi posłodziłeś. Cześć. ;) Chcielibyśmy dzisiaj porozmawiać o SSR, czyli Server Side 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 SSRa w kontekście aplikacji typu SPA i aplikacji typu SSG. Jakie jest Twoje zdanie Wojtek na ten temat? Na pewno masz dużo doświadczenia z SSRem. Zresztą we współczesnym developmencie, tak naprawdę od tego nie uciekniemy. Co myślisz?

W: Masz rację Mateuszu. Jest to rzecz nieunikniona. Myślę, że każdy developer słyszał o takich frameworkach jak chociażby NextJS czy Gatsby. Myślę, że jest to fajne o tyle, że oferują one naprawdę coś specjalnego i coś, czego tak naprawdę, nie da się narazie jeszcze natywnie osiągnąć za pomocą Reacta. I rozwiązują realne problemy, z którymi borykają się takie nowoczesne aplikacje w sieci. A co Ty sądzisz?

M: Wiesz co - ja dość dużo pracuję z SSRem i się totalnie zgadzam z tym, że to jest takie nowe MPA, czyli Multi Page Application. 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. Wymyśliliśmy coś nowego, żeby przenieść z jednej strony aplikację na bardziej wydajne sprzęty użytkowników, coraz bardziej wydajne sprzęty użytkowników, gdzie te aplikacje stawały się rzeczywiście coraz szybsze. Z drugiej strony olbrzymie korporacje, które wprowadziły te wielkie serwisy, z wielomilionową publicznością, próbowały jakoś sprzedać koncept SPA poprzez obniżenie kosztów eksploatacji serwera i wydaje mi się, że SPA tak naprawdę 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 było podobne do MPA, czyli do SSRa jest całkiem czymś naturalnym. I wydaje mi się, że SSR w takim ujęciu w jakim jest w tym momencie jest w zasadzie jedyną słuszną drogą w Internecie w obecnym kształcie.

W: Zgadzam się z Tobą i myślę, że właśnie te wielki firmy, o których wspomniałeś i platformy, które są tworzone i z których korzystają na co dzień miliony użytkowników, takich jak np. Twitter czy chociażby AirBnB miałyby duży problem z ich widzialnością w takich miejscach jak Google czy innych wyszukiwarkach internetowych. Dzięki takim technologiom jak NextJS czy szeroko pojęte SSRy bardzo dużo to zmienia.

M: Mamy SSR, mamy SSG, czyli Static Site Generation, mamy też SPA i w zasadzie z każdym z tych trzech rodzajów aplikacji (a nawet mamy MPA w dalszym ciągu na rynku) spotkamy się. Czy bazując na Twoim doświadczeniu, na tym co już tak naprawdę zrobiłeś i na tym, że znasz każde z tych podejść - jak myślisz, do których projektów warto by było wybrać poszczególne rzeczy. Ja ze swojej perspektywy widzę bardzo mało zastosowań dla SSG. 

W: Zgadzam się z Tobą. To pewnie też jest temat, który jeszcze poruszymy później, czyli właśnie: jaki jest sens w podejściu SSG i porozmawiamy o tym w kontekście Gatsby'iego. Jeśli chodzi ogólnie o aplikacje - myślę, że tutaj właśnie SEO jest bardzo ważne. I to jak chcemy, żeby ta nasza aplikacja prezentowała się dla użytkowników. Ze SPA skorzystałbym wtedy, kiedy nasza platforma czy też produkt, który tworzymy mieści się za logowaniem - praktycznie cała/y. Jest jakiś dashboard, są jakieś wykresy, a jedyną interakcją, którą mamy z platformą z zewnątrz jest logowanie. Tutaj SPA sprawdzi się świetnie. Jeśli chodzi o SSRy to wykorzystałbym je w takich aplikacjach jak media społecznościowe czy coś w stylu AirBnB czy innych platform zajmujących się wynajmem mieszkań. A Ty Mateuszu masz inne zdanie na ten temat?

M: W zasadzie chyba nie. Jeśli chodzi o strony statyczne, czyli powiedzmy wizytówki, wszelkiego rodzaju strony firmowe, które nie wymagają częstych aktualizacji to pewnie poszedłbym w stronę SSG. Strony generowane statycznie byłyby fajnym pomysłem. Poza takimi przykładami nie widzę za dużo zastosowań dla SSG. Chociaż warto podkreślić, że na pewno są to najoptymalniejsze aplikacje. Jeśli chodzi o podejście takie czysto biznesowe, gdzie raczej klient zewnętrzny do nas nie przyjdzie to często SPA jest fajnym pomysłem. Ale znowuż tutaj pojawia się kilka kwestii. Musimy pamiętać też o tym, że aplikacje typu SPA to są aplikacje, które mają cały kod źródłowy w przeglądarce i taka konstrukcja aplikacji trochę narzuca ograniczeń. Warto byłoby przemyśleć co chcemy zrobić, jak chcemy pewne integracje przygotować. Z tej perspektywy napewno cenię Next'a za to, że, oprócz SSRa, i oprócz podejścia hybrydowego, czyli możliwości wyboru - czy chcemy mieć widoki SSG czy SSR - daje nam też opcje na to, że możemy stworzyć własne API. Zatem możemy stworzyć własny Backend For Frontend w naszej aplikacji, który może nam te newralgiczne elementy aplikacji ukryć. Można je odpowiednio zabezpieczyć. W tym ujęciu na pewno się zgadzam w 100% z Tobą. Aplikacje biznesowe - myślę, że wybrałbym SPA (takie, gdzie użytkownik zewnętrzny nie musi wejść). Natomiast aplikacje klienckie, gdzie mamy duży narzut w postaci pozycjonowania, w postaci mediów społecznościowych, w postaci jakiejś widoczności, z dodatkowymi ustawieniami to myślę, że SSR będzie tutaj najciekawszą opcją. 

W: Zgadzam się z Tobą w 100%. Myślę, że kwestia jest tego, jak bardzo chcemy, żeby interaktywna była czy też był produkt / aplikacje, które tworzymy. Myślę, że to głównie powinno decydować z jakiej technologii skorzystamy. Chociaż tutaj też rodzi się dla mnie ciekawe pytanie, bo właśnie jako że operujemy w takich technologiach na codzień. Czy zdecydowałbyś się teraz Mateuszu, mimo tego, że robiłbyś jakąś najprostszą stronę internetową, na skorzystanie z takich technologii jak Next czy Remix? Czy raczej poszedłbyś w zwykłego HTMLa? 

M: To jest dość trudne pytanie. W zasadzie stoję na stanowisku, że powinniśmy dobierać narzędzia do potrzeb i umiejętności. Jeżeli mamy stronę wizytówkową, która ma być jakimś MVP dla naszego produktu, dla naszego klienta, to prawdopodobnie najprostsze rozwiązania są najlepsze. Pewnie prosty HTML byłby dla niego najtańszy i najskuteczniejszy. Aczkolwiek stałby się w pewnym momencie kulą u nogi, bo tak naprawdę trudno takiego HTMLa dalej rozwijać bez konkretnych umiejętności. Przydałby się jakiś CMS. Jeżeli CMS to na rynku mamy mnóstwo CMSów. Sami zresztą niedawno mieliśmy dyskusję przy jednym projekcie z działem marketingowo - biznesowym, co wybrać. Tutaj pojawiła się zagwozdka, bo tych rozwiązań jest masa. Od Wordpress'a poprzez jakieś Wix'y, itd. Low-Code, No-Code i inne tego typu rzeczy. Wydaje mi się, że ja osobiście nie chciałbym pracować już w czymś, co nie sprawi mi frajdy, ale z drugiej strony, pod kątem biznesowym, na pewno trzeba dobierać narzędzia pod potrzeby. Pewnie wybrałbym do prostego rozwiązania, do prostego MVP - HTML zamiast jakiegoś rozwiązania React'owego.

W: Ja chyba bym zrobił odwrotnie. Jak teraz Ciebie tak słucham i się zastanawiam to myślę, że nawet jakbym robił najprostszą stronę internetową, jednak bym się zdecydował na jedną z tych technologii, o których dzisiaj rozmawiamy. Dlatego, że bardzo szybko pojawiają się takie potrzeby, jak rozbudowanie strony. Jesteś zdecydowanie bardziej future proof. Ogromnie zmieniła się przestrzeń narzędziowa w zakresie Reacta i w ogóle technologii webowych. Pamiętam jak jeszcze niedawno był to ogromny problem, żeby zsetupować taki projekt. Dzięki takim narzędziom jak Vite czy wszystko-co-zapewnia-Next-w-swoim-CLI, poświęcasz 5 minut i masz zsetupowany projekt. Kolejną rzeczą, która robi dla mnie dużą robotę jest developer experience. Z React'em pracujemy na codzień. Jednak pracując z takim HTMLem experience nie jest taki świetny, szczególnie jeśli jest to duża strona internetowa. Możesz zdecydowanie łatwiej, naturalniej podzielić sobię tę stronę na jakieś drobne kawałki - patrz komponenty i zdecydowanie przyjemniej sobie programować.

M: Z perspektywy developera podoba mi się to, co mówisz. Zdecydowanie mi się podoba. Nie powiedziałem, że chciałbym pracować z czystym HTMLem czy CSSem. Zdecydowanie wolałbym pracować tak, jak pracuję. 

W: Mateusz, teraz to już jest wszystko nagrane.

M: Tak, ale fakt faktem nadal podtrzymuję, że klient który do Ciebie przychodzi bardzo często zaczyna od MVP. Jak zrobisz mu stronę internetową z Next'em, w architekturze komponentowej, do tego dorzucisz jakiś Headless CMS i wszystko będzie pięknie ładnie. Wszystko będzie cudnie napisane, ah... jeść będzie można z tego. To w pewnym momencie się okaże, że on zapłaci naprawdę horrendalną kwotę za narzędzie, którego nie wykorzysta w ogóle, albo wykorzysta 5% jego możliwości. Wydaje mi się, że z perspektywy czysto biznesowej developer experience też jest ważny, ale można go osiągnąć troszeczkę inaczej, nie zawsze musimy zaprzęgać najcięższe działa, żeby osiągnąć efekt satysfakcjonujący dla klienta. Oczywiście, ten klient przyjdzie za chwilę, jak się mu biznes rozwinie. I powie słuchajcie - zróbcie coś więcej. Wtedy, na tym drugim etapie myślę, że już rzeczywiście trzeba zobaczyć jak ten biznes się kręci, jakie są potrzeby biznesowe, co się zmieniło, w którą stronę to poszło, i wtedy tak - jak najbardziej warto pójść w coś więcej, ale na tym pierwszym etapie, na etapie MVP - zostałbym przy najprostszych rozwiązaniach. Pomimo tego, że z całego serca wolałbym pisać w React czy w Angularze, czy w czymkolwiek innym co jest tak naprawdę o wiele bardziej uporządkowane i mniej chaotyczne niż taka czysta strona HTMLowo - CSSowa. 

W: Rozumiem. Jest to ciekawe zdanie. Myślę, że ta nasza różnica zdań sprowadza się koniec końców do tego, czy uważasz, że szybciej byłoby postawić taką stronę czysto HTMLową niż taką stronę na Next'cie?

M: Pamiętasz Bootstrapa?

W: Pamiętam.

M: Jak tam się składało strony? 4 godziny i miałeś stronę postawioną. A pamiętasz albo kojarzysz może, bo nie wiem czy pracowałeś z Wordpress'em - wszelkiego rodzaju agencje interaktywne? Sam mam takie doświadczenia - kiedyś w jednej firmie, z którą pracowałem klient chciał stronę internetową. Strona została wyceniona na horrendalne pieniądze. Po czym dano mi zadanie do wykonania: kupić szablon za 49 dolarów, złożyć stronę internetową. Zajęło mi to mniej niż 5 godzin i potem poczekać 3 tygodnie, żeby klient myślał, że coś się dzieje.

W: Rozumiem.

M: Nie będę tutaj rzucał nazwami. Stronę postawisz w 5 godzin. Trudno jest to potem uargumentować klientowi, że to kosztuje X tysięcy złotych za 5 godzin pracy. Tego nikt nie chce, a biznes musi się kręcić. Nie powiem, było to bardzo niefajne. Nie powiem, że to było spoko, ale z drugiej strony jeśli chodzi o MVP to najprostsze rozwiązania, kiedy nie wiemy czy nasz biznes się opłaci, mogą być zdecydowanie łatwiejsze i szybsze do wydewelopowania niż postawienie strony w Next'cie. Nie powiesz mi, że w 5 godzin postawisz całą architekturę komponentową w Next'cie. Postawisz projekt i zbudujesz może jeden widok.

W: No ok.

M: Całej aplikacji nie postawisz, szczególnie jeśli musisz dopisać style i skrypty, do tego podłączyć wszelkiego rodzaju pluginy marketingowe itd. Przy konfiguracji Wordpressa czy Wixa masz pewne narzędzia dodane out-of-the-box. Jest to łatwiej złożyć. Mi się wydaje, że nasza różnica zdań Wojtku polega na tym, że my się zgadzamy co do tego, że React jest spoko i że developer experience jest naprawdę na najwyższym poziomie, i że jak robić, to nie robić babola, tylko od razu zrobić coś porządnie. Zgadzamy się z tym. Różnica natomiast jest w tym miejscu, gdzie pojawia się biznes. Stoję na stanowisku, że klient jak do nasz przyjdzie, to na bank nie będzie wiedział czego chce, a jeżeli chcemy podejść do niego uczciwie to powinniśmy dać mu szansę na to, żeby dostał bardzo proste MVP i dopiero wtedy, kiedy jego biznes się rozwinie zaproponować mu coś fajniejszego. Aczkolwiek zgadzam się też, że jeżeli klient przyjdzie doświadczony, pewny, z dojrzałym biznesem i zmienia, wprowadza coś nowego, to wtedy od razu wchodzimy w fajne technologie. W coś w co tak naprawdę wartościowego, bo ten biznes już się kręci. To nie będzie tak, że to będzie projekt, który nie wiadomo czy wypali, czy nie wypali. Zobacz, nasz znajomy - teraz dwa biznesy rozkręca i oba zostały postawione na Wordpress'ie - proste, szybkie strony internetowe, a budżet wynosił 400 zł na stronę, bo trzeba było szybko postawić MVP, żeby zobaczyć czy to w ogóle się wyskaluje. Lejki marketingowe czy inne tego typu rzeczy. Jeżeli ten biznes się rozwinie, to pewnie dostaniemy zapytanie czy nie chcielibyśmy tego zrobić lepiej.

W: Rozumiem, ale myślę Mateuszu, że mylisz trochę dwie rzeczy. Tutaj głównym problemem nie jest technologia sama w sobie, a bardziej projekt tej strony. To nie jest kwestia tego jak chcesz to zrobić. Chcesz to po prostu zrobić, jak najszybciej w tym wypadku o którym Ty mówisz. I tutaj rzeczywiście takie narzędzia Low-Code / No-Code, te o których wspominałeś są najlepsze. Po prostu najszybciej dają Ci jakikolwiek efekt.

M: To jakikolwiek jest tutaj słowem kluczem.

W: Tak, dokładnie, ale też nie mówimy o technologiach takich jak HTML. To nie jest tak,  że piszesz to, od nowa. Tylko korzystasz z gotowych już rozwiązań.

M: Celem jest czas. To jest waluta w tym momencie, w takim biznesie. Zgadzam się, że jeżeli chcemy zrobić coś fajnego to taki SSR będzie ciekawszym rozwiązaniem. Troszkę odbiegliśmy od tematu. Załóżmy, że chcemy zrobić jakąś stronę i wybieramy SSG (chociażby) - to SSG sprowadza się do tego, że piszesz w React'cie ale docelowo będziesz miał statyczne strony w HTMLu i CSSie, które będziesz hostował na serwerze. Nie mam doświadczenia z Gatsby, więc nie wiem jak się szybko w tym pisze. Jeżeli się pisze szybko to może Gatsby też jest takim narzędziem, które byłoby gdzieś tam pomiędzy mną a Tobą. Pomiędzy moim podejściem, które stara się skupić na tym, co potrzebuje klient a Twoim (oczywiście nie mówię, że Ty tego nie chcesz robić, ale że bardziej skupiasz się na tej drugiej części - developer experience).

W: Ja mam wrażenie, że my się zgadzamy. Tylko trochę patrzymy na inne strony tego samego problemu. Ty mówisz o czasie i tym, jak szybko możemy dostarczyć temu klientowi stronę. Tutaj zgadzam się, że te podejścia, o których wspomniałeś, czyli między innymi Wordpress, będą najszybsze. Torujemy sobie developer experience, chcemy po prostu jak najszybciej postawić jakąkolwiek stronę internetową, ale w momencie w którym zdecyduje się: ok, chcemy coś napisać lepiej i mamy do wyboru te wszystkie technologie albo stwierdzamy, że nie potrzebujemy żadnych technologii - zwykły HTML będzie wystarczający, bo mamy zrobić prostego landing page'a. Nie przewidujemy, że będzie tam potrzebny jakiekolwiek CMS. To myślę, że oboje byśmy wybrali jedną z tych technologii, o których rozmawiamy dzisiaj. Myślę, że raczej nie pisałbyś tego od nowa. Po prostu w czystym HTMLu.

M: Nie, nie. Jeśli już jesteśmy przy czystym HTMLu, to jesteśmy przy SSG. Jeżeli jesteśmy przy SSG, to jesteśmy przy Gatsby. Kiedy SSG? SSG wtedy, kiedy chcemy, tak jak mówiliśmy, postawić jakąś prostą stronę, która ma mało widoków, nie jest super dynamiczna, nie często się zmienia, bo SSG generuje nam te HTMLe / CSSy w trakcie procesu budowania projektu. Wydawałoby się, że w takim ujęciu SSG jest najciekawszym rozwiązaniem. Natomiast Gatsby od pewnego czasu zalicza spadki popularności. W takim razie jak myślisz - SSG ma w ogóle sens jeszcze? Co się stało z Gatsby'm? Co jest powodem tego, że to się tak zmienia?

W: To są wszystko dobre pytania. Mam tylko przypuszczenia. Wydaje mi się, że SSG jako sama technologia jest dalej dobrą rzeczą, która ma zdecydowanie swoje miejsce. Widać to na przestrzeni różnych frameworków, może nie po Gatsbym, ale na takich frameworkach jak Astro czy Qwik, o którym Ci wspominałem. Myślę, że problem Gatsby'iego jest trochę inny. Moim zdaniem główny problem, który jest w tym frameworku to jest jego złożoność i skomplikowanie, która jest trochę jak strzelanie ze strzelby do much, czy też z armaty do kaczek, ponieważ on między innymi wykorzystuje GraphQL do generowania tych statycznych stron, który myślę, że jest totalną przesadą w tym kontekście. Generujesz statyczną stronę, a masz wrażenie że pracujesz z jakimś mega skomplikowanym produktem. Nie wiem czy Ty miałeś jakieś doświadczenia z Gatsbym i czy masz może inne wrażenia dlaczego on zalicza takie spadki popularności.

M: Ja słyszałem znowuż o Gatsby, nie pracowałem osobiście w komercyjnym projekcie, tylko trochę prywatnie się bawiłem, natomiast z tego co, spotkałem się znowuż uderzę o tą stronę biznesową. Bardzo często porównuje się Gatsby do narzędzi typu WordPress - z prostej przyczyny, ponieważ oba narzędzia miałyby służyć do szybkiego dostarczenia produktu w prostym ujęciu. Oczywiście jeden to jest SSG, drugie to MPA, więc trudno by było to porównywać z tej perspektywy. Natomiast z drugiej perspektywy, jeżeli klient ma do wyboru, przychodzi do ciebie i mówi: Słuchaj Wojtek. Chcę stronęinternetową, landing page, najlepiej, żeby szybko został postawiony. Co mi proponujesz? A Ty mówisz: Słuchaj, zrobimy, zrobimy SSG, bo jest optymalne, bo jest szybkie, bo jest fajne. Wprowadzamy Gatsby'ego, a on mówi: No dobra, co ja mogę z tym zrobić? No słuchaj, co możesz z tym zrobić, dostaniesz od nas...

W: Napiszesz do mnie, ja Ci wszystko zrobię, tak?

M: Tak Napiszesz do mnie, ja ci wszystko zrobię. A jakbym wybrał MPA, jakiegoś CMSa, jakiegokolwiek, nawet starą Joomlę, to on sam to sobie wyklika.

W: Kurcze koszmary.

M: i teraz Gatsby wypełniał tą lukę na rynku. Tyle tylko, że trochę zaniemógł w porównaniu do mnogości opcji, które dostarczają rozwiązania rozwiązania MPA. Jeżeli byśmy spojrzeli na Gatsby w kontekście Nexta - to tutaj mamy już większe pole do popisu, ponieważ Next też może nam generować SSG. I porównując Nexta np. z Gatsby - wydaje mi się, że większość wybierze Next, 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.

W: Zgadzam się z Tobą.

M: Rozumiejąc Gatsby jako narzędzie do budowania prostych, szybkich i dynamicznych stron - może się pojawić rozbieżność. Jak go porównać? Czy to będzie bardziej MPA czy to będzie bardziej SSR? Wiadomo, że 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.

W: Zgadzam się z Tobą. Poza tym, jeśli już zostałem tutaj takim adwokatem właśnie tego Developer Experience, że tak powiem, to myślę, że jeśli chodzi o samego Gatsby, myślę, że właśnie nie zapewnia on niczego, czego nie zapewniałyby te frameworki takie jak Next czy Remix, a dodatkowo generuje jakieś dodatkowe problemy w tym, że jest dość skomplikowany i jak na wartość, którą proponuje. Dodatkowo jeszcze w rzeczach takich jak Next czy Remix integracje z innymi częściami aplikacji, które są statyczne, są hybrydowe, są dynamiczne, jest zdecydowanie lepsza niż w Gatsbym.Myślę, że dlatego z Gatsbym ostatnio jest troszkę gorzej. Co prawda też trzeba przyznać, że nie jest to tak, że nie żyje, bo został zakupiony ostatnio... wyszła ostatnio wersja piąta. Został zakupiony również przez Vercel, czyli spółkę matkę tak naprawdę NextJS, jeśli można tak powiedzieć. Zdecydowanie ktoś jeszcze z tego korzysta.

M: Wmergują to do code base Nexta. No dobra, a pozostali gracze? Mamy Nexta, o którym sobie cały czas rozmawialiśmy. Mamy Gatsby, który cały czas nam się przewija, ale na rynku są też inni gracze. Właśnie tak jak wspominałeś Remix, Svelte, chociażby Qwik, o którym też mówiłeś. Czy w ogóle są w stanie dostarczyć coś wartościowego? Jak przeglądałem sobie chociażby Svelte - to dla mnie to, to nie jest Developer Experience na najwyższym poziomie. Bardziej przypisał bym to może do Vue. Bardziej przypomina mi to Vue niż Reacta. Może dlatego, że jestem bardziej przyzwyczajony do koncepcji pisania w React czy w Angularze, to jest mi po prostu o wiele łatwiej ogarnąć te dwie koncepcje niż tą koncepcję tworzenia widoków we Vue. Natomiast fakt faktem mnie osobiście nie przekonują. A co Ty myślisz o nich? Czy w ogóle jest dla nich miejsce na rynku?

W: To znaczy Mateuszu, wiesz co, nie mieszałbym do tego naszego worka, który sobie dzisiaj stworzyliśmy, właśnie Svelte. Ja też nie widzę na razie wartości, chociaż słyszałem o nim dużo dobrego od innych deweloperów i developer experience, o którym mówimy tak dużo mówimy, wielu deweloperów docenia, więc nie wrzucałbym Svelte 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 wspominasz, słyszałam dużo dobrego od innych deweloperów i wiele osób sobie chwali te rozwiązania, które tam są. Chociaż mi osobiście 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 SSRowy powiedzmy, to właśnie skorzystałbym z Remix'a, ponieważ myślę, że on proponuje on najciekawsze rozwiązania, jeśli chodzi o technologię m.in. end-2-end type safety bez jakichś dodatkowych rzeczy, które musimy robić w Next, chociażby ciekawe podejście do formularzy i do wymiany danych. Również ciekawe podejście do stanu samego, to jak się ładuje cała aplikacja i to które części się rerenderują. W momencie, kiedy coś się na stronie.

M: Zapłacili Ci Wojtek?

W: Zapłacili. Niestety nie, szkoda, ale tak jestem adwokatem.

M: Żartuję, ale fakt faktem to brzmiało jak reklama. Oni tak się podobnie reklamują, że są fajni. Ale w takim razie skoro polecasz muszę spróbować.

W: Myślę, że to też jest temat na ciekawą dyskusję właśnie w kontekście takich dużych firm technologicznych, które tak bardzo dominują rynek. I mówię tutaj o Next i razem z tym Vercelu - to co oni zapewniają, tzn. to jak monopolizują rynek, robi się dość problematycznym, bo właśnie koniec końców będziesz musiał skorzystać z usługi, żeby sobie wyhostować chociażby Twoją stronę, która jest napisana w Next. Każda taka strona...

M: Nie musisz.

W: Rozumiem, że na razie nie musisz tego robić, bo na razie jest to inny wybór, Ale w momencie, kiedy nie będziesz miał innego wyboru.

M: Pamiętasz jak było z Reactem jak Angular pojawił się na rynku i ludzie mieli dylemat, bo na rynku był Angular i React i długo długo nic, a te wszystkie frameworki, ExtJS itd wypadały powoli. Ludzie, korporacje mieli dylemat - co wybierać. To na co patrzały? Na to nie jaki jest próg wejścia, jaki jest developer experience, tylko jakie są przepisy związane bezpośrednio z danym frameworkiem, z danym narzędziem. Np. w React w tamtym czasie był case dosyć słynnt, gdzie był taki dość wątpliwie rozumiany zapis, który mówił według niektórych, że wszystkie narzędzia / rzeczy napisane z wykorzystaniem Reacta będą podlegać w jakiś tam sposób pod Facebooka. To spowodowało dość duży odpływ w tamtym czasie i te wielkie korporacje wybierały Angulara przez jakiś czas. Więc jeżeli taki Vercel wszedł by na rynek w białych rękawiczkach i powiedział: Słuchajcie, od dzisiaj wszyscy korzystacie z naszych usług albo sio? To trochę kopaliby pod sobą dołek.

W: Zgadzam się z Tobą.

M: Zrobiliby dokładnie to samo, co zrobił Facebook ileś lat temu. Facebook z tego feralnego zapisu się dość szybko wycofał, zmienił licencję i myślę, że każdy podmiot w tym momencie zrobiłby dokładnie to samo.

W: Rozumiem. Mam nadzieję, że moje stwierdzenie, że Next chce zmonopolizować rynek i koniec końców, aby hostować jakąkolwiek aplikację będziesz musiał zapłacić im, jest jakimś daleko posuniętym armageddon. Powiedzmy. Ale mówię tutaj o takiej rzeczy, że tak jak wspominałeś w wypadku Angulara i Reacta i o tych zapisach, które były w React miałeś wybór, bo miałeś Angulara. Nie podobał Ci się React. Były tam jakieś zapisy, które Ci nie odpowiadały czy Twojej firmie? Więc wybierałeś Angulara, bo była to alternatywa, a w momencie kiedy taka firma jak Vercel dominuje rynek i dominuje wszystkie technologie, które tam są, to wtedy pojawia się problem, bo nie masz wyboru, nie masz Angular i Reacta, masz tylko Vercel i musić im zapłacić albo nie hostować aplikacji, czyli też nie korzystać z ich usług.

M: Pytanie czy Vercel jest na tyle silny, żeby kupić Google czy Metę?

W: Tak, ale ja mówię...

M: Zobacz, kto kupił Remixa? Salesforce. Ci najwięksi na rynku mają swoje frameworki.

W: No to prawda.

M: Tak naprawdę zawsze tak było.

W: To prawda.

M: Jeżeli my się kłócimy o to, co wybrać, to tak naprawdę kłócimy się pomiędzy czy wybrać jakieś rozwiązania indywidualne typu Vue. Nie wiem czy widziałeś ten dokument nt. Vue? On jest już dosyć stary, na kanale na youtubie, Honeypot.

W: Widziałem.

M: Bardzo fajny w ogóle. Więc jeżeli ktoś ze słuchaczy naszych nie widział i ma ochotę zobaczyć jak powstaje framework, jeden z największych na świecie, pisany przez jedną osobę, to warto ten dokument zobaczyć. Jakość wykonania jest naprawdę spoko. Natomiast wracając do tematu. Mamy do wyboru albo narzędzia takie jak React od Facebooka (od Mety), Angular od Google, Vue od chłopaka, który samodzielnie go napisał i za nim stoi w tym momencie chyba środowisko PHP - Laravel z tego, co pamiętam. Chyba żadna firma taka typowo frontendowa nie jest wmieszana w ten temat. Mamy do dyspozycji jeszcze Salesforce i Remix'a w tym momencie. Więc mamy kilka wyborów, ale tak naprawdę każdy z nich to wybór pomiędzy firmą jakąś, pomiędzy jakimś może punktem widzenia. Bo kto wybiera Vue? Najczęściej oczywiście są jakieś przesłanki technologiczne do wyboru, ale w większości przypadków, jak spojrzymy na to, gdzie jest największe użycie Vue to ono jest w Chinach, w Azji. Tam, skąd pochodzi twórca Vue. Wydaje mi się, że jakbyśmy spojrzeli na to, co ludzie wybierają, to ludzie wybierają pod kątem jakiejś sympatii bardziej, emocje. A czy my wybierzemy Remix'a, Reacta, Next'a? Nexta to tak jakbyśmy wybrali React'a. Jeżeli wybierzemy i Reacta i będziemy potrzebowali SSR to wybierzemy Nexta. Jeżeli SSG to weźmiemy Gatsby to też jest Reacta. Tak mi się wydaje. Jeżeli nie będziemy sympatyzować z polityką Facebooka to w życiu nie wybierzemy Reacta, 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 stoi za tym 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órego kolejne wersje wydawane w regularnych cyklach półrocznych. Ten produkt już się nie zmienia aż tak. To nie jest to, co było między RC 5 a RC 6, że wywalamy wszystko i piszemy od początku. Na ten moment jest to stabilne rozwiązanie i tak samo jest chyba, jeśli chodzi o Reacta. W tym momencie wybieramy React, ale czy my wybierzemy Next Gatsby czy czystego Reacta, to tak jak byśmy wybierali SPA, SSG czy SSR. W kontekście sympatyzowania z czymś.

W: Taki side note: zdajesz sobie sprawę, że tak na dobrą sprawę Remix to jest React.

M: Tak, wiem, tak zdaję sobie z tego sprawę. Nie umiem go jeszcze umiejscowić. Nie wiem czy to jest bardziej SSR czy SPA, bo jeszcze nie zagłębiałem się w ten temat.

W: Tak chciałem się upewnić tylko. Ale ogólnie zgadzam się z Tobą. Myślę, że tych technologii jest tyle, że jest to wybór koniec końców pomiędzy dużymi firmami i jest to też, moim zdaniem, ciekawy model biznesowy i super ciekawy pomysł na niejako startup, czyli stworzenie takiego frameworku czy też biblioteki tak dużej, że może się przerodzić to w taką dużą firmę, tak jak to było z Next czy ze Stripe'm. Spoko rzecz. Czyli Ty dzisiaj byś wybrał Next'a, jeśli byś pisał stronę i miałbyś w wymaganiach: stworzenie takiej strony w stylu SSR?

M: Jeśli bym pisał stronę internetową np. dla naszego podcastu i miałoby to być SSR to wybrałbym Nexta, bo developer experience mi się podoba. Aczkolwiek nie pracowałem z Remixem. Wiem, że bardzo go chwalisz, więc może możemy się przyłożyć do tego. Może to jest dobry moment? Kto wie. Możemy spróbować coś napisać razem i na jakimś żywym produkcie to wykorzystać. Teraz jeszcze chodzi mi po głowie jedna kwestia, bo rozmawiamy sobie o tym SSR, rozmawiamy sobie o SSG i o SPA, rozmawiamy o tym, jaki to ma wpływ tak naprawdę na pozycjonowanie, na developer experience, na media społecznościowe, jak użytkownicy 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 wszystkie inne, które są bezpośrednio powiązane z performance, z wydajnością. Które z tych podejść może być dla nas najciekawsza, jeśli chodzi o wydajność?

W: Myślę, że tutaj znowu Remix wygrywa, ale jeśli chodzi ogólnie o te metryki, myślę że jest to wszystko powiązane.

M: A Remix to będzie SSR, SPA czy SSG?

W: Myślę, że ja powinienem zmienić imię i nazwisko. Wojciech Remix - brzmi całkiem nieźle. Ale tak już serio są to ważne metryki, ale to dlatego, że jest to bardzo powiązane ze sobą, przede wszystkim powiązane z SEO i Googlem. Jak takie metryki performance'owe wpływają na to, jak nasza strona jest pozycjonowana. Nie wiem czy Ty masz inne doświadczenia? Ogólnie też user experience, bo też nie chcesz ryzykować.

M: To powinno wybrzmieć.

W: Zgadzam się.

M: Te czasy wydajności, które musimy osiągnąć, bo też o tym często nie myślimy. Jak tworzysz aplikację biznesową, to nie myślisz o tym, ile ten biznesowy klient będzie czekał, bo ten czas nie jest tak istotny. Oni są przyzwyczajeni, niestety, do tego, że ta aplikacja się często długo ładuje i rozwiązaniem najczęstszym problemów jest po prostu jakiś loader'ek. Pach, pach. Pomieli, pomieli, działa, jest ok. Natomiast przy takim kliencie indywidualnym to: SEO to jest to jak my widzimy w Internecie, jak łatwo mogą nas znaleźć, ale klienta możemy też stracić, nie tylko go pozyskać lub nie pozyskać. Możemy go też stracić, na przykład, kiedy za długo ta strona będzie się wczytywała. Pamiętasz strony flashowe z lat dwutysięcznych?

W: Pamiętam taki plugin flashowy, który wykorzystywałem, ale on był niezły. Co tam nie robiło na tej stronie internetowej.

M: No właśnie, co się tam nie robiło. Ale najważniejsze w tym wszystkim jest to, że tam był loader na początku i pasek postępu i to leciało od 1 do 100%. Albo się mieliło, mieliło, mieliło. Czasami to trwało, szczególnie na tamtym łączu, w tamtych czasach. OK, możemy powiedzieć, że dzisiaj mamy szybsze łącza, więc możemy sobie pozwolić na trochę więcej. Z drugiej strony, np Next bardzo fajnie wspiera optymalizację obrazków, które niewątpliwie są najcięższą częścią całej aplikacji. Mają chyba jeden z największych wpływów na to, jak nasza strona szybko się załaduje. Poza tym są jeszcze inne rzeczy typu: jaki jest czas odpowiedzi serwera (przy SSR na pewno będzie dłuższy). SSG będzie szybszy, bo dostarczamy tylko i wyłącznie HTML, CSS. Jeszcze mamy ten czas, który musi przeglądarka poświęcić na przygotowanie dla nas całej naszej aplikacji. Więc wydaje mi się, że Perfomance 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. Nie wiem jakie Ty masz przemyślenia, ale mi się wydaje, że najszybszy byłby w tym wypadku pomimo wszystko SSG.

W: Zgadzam się z Tobą. Najszybsze podejście to statyczny HTML. Dlatego też pojawiają się te wszystkie rozwiązania EDGEowe, o których też jest bardzo głośno ostatnio i serwowanie tego naszego contentu jak najbliżej użytkownika, który też pomaga. Chociaż myślę, że zależy jak szeroko zakrojoną walkę prowadzimy tak na dobrą sprawę i jak bardzo tego potrzebujemy. Strona stronie nierówna, więc też może się to bardzo różnić od siebie: jakie mamy wymagania i jak bardzo musimy ją optymalizować? Jak pewnie wiesz po projektach, nad którymi Ty pracowałeś, Mateuszu, to naprawdę bardzo zależy od tego, jak wygląda nasza pierwsza strona. Ile jest takich rzeczy o których wspomniałeś: jak obrazki, animacje itd? I zdecydowanie strona, taka, która ma 50 tysięcy animacji, 50 tysięcy jakichś ogromnych obrazków i składa się praktycznie z tego. Będziemy musieli zdecydowanie więcej walczyć i może nawet pokusić się o inne technologie, żeby uzyskać jak najlepszy wynik performance w przeciwieństwie do mniejszej strony, czy trochę inaczej zaprojektowanej, która bierze to pod uwagę i gdzie już sama jej budowa zapewnia nam to, że nie musimy tego, aż tak bardzo optymalizować, żeby renderowała się ona super szybko. Myślę, że jeśli chodzi o te metryki, o których tutaj rozmawiamy, są one jak najbardziej ważne, szczególnie w momencie, kiedy tworzymy aplikacje (gdzie nie są to projekty B2B, tylko są to projekty B2C, czy też C2C nawet). B2C jest mega ważny. 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.

M: No tak, jak nie wiadomo o co chodzi, to chodzi o pieniądze.

W: Dokładnie tak.

M: Wojtek. To jeszcze pozostaje nam jedna nierozstrzygnięta kwestia. Rozmawialiśmy o SSR, rozmawialiśmy o SSG, o SPA, o MPA, gdzie tu umieścić najnowszy pomysł Reacta? Czyli jak pewnie sobie zdaje sprawę, co mam na myśli, React Server Components? Ja na tę koncepcję patrzę w tym momencie tak, że nie jest to SSR - według tego, co mówi nam React. Jest to komponent, który de facto będzie przekształcany do jakiegoś prostego stream'a, prostego tekstu, który będzie można później sobie sparsować na komponent i wykonać 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 po prostu bliżej źródła danych, więc tak naprawdę bliżej serwera w większości przypadków. Powinny być po to, aby wykonać te najcięższe operacje po stronie serwera, aby zdjąć je bezpośrednio z użytkownika, typu jakieś przekształcenia skomplikowane Markdowna na HTMLa. A z drugiej strony nadal to jest tylko koncepcja, o której React mówi, ale tego nie udało się jeszcze wdrożyć. Chyba tylko Next próbował, ale z tego co zrozumiałem to nadal to nie działa do końca. I tak naprawdę nie wiem, co o tym myśleć.

W: Myślę Mateusz, że React, co jest dużym plusem w porównaniu do takich frameworków jak Angular, trochę mu zajmuje wprowadzanie zmian, ale te zmiany są bardzo przemyślane i zazwyczaj są też relatywnie małe. I myślę, że tego typu zmiana, czyli Servers Side Component czy też dodatek do już istniejącej biblioteki jest fajny, bo daje Ci po prostu wybór. Myślę, że inzynierowie Reacta do tej pory moim zdaniem zrobili świetną robotę jeśli chodzi o API i porusza się ono w bardzo dobrą stronę. I wygląda na to, że właśnie te Server Side Components są niejako trochę odpowiedzią czy próbąadaptacji do potrzeb rynku, czyli właśnie do próby współgrania z tymi technologiami, o których dzisiaj rozmawiamy i też dania możliwości ich wykorzystania developerom w bardziej natywnych środowiskach. I właśnie może nawet w takich aplikacjach jak te, o których rozmawialiśmy dzisiaj, czyli aplikacjach B2B, gdzie będziemy mogli lepiej zoptymalizować front naszej aplikacji i już nie pokazywać 50 loaderów i nie robić dynamicznych komponentów, tylko zrobić Server Side Components, co też może prowadzić do łatwiejszego utrzymywanie kodu, bo nie musisz pamiętać, że ten komponent ma stan, ten nie ma, tutaj muszę się martwić rerenderowanie itd. Wiem, że jeśli ten komponent jest oznaczony jako Serwer, wiem, że nie potrzebuję tam tego stanu i jeśli ktoś próbuje to zrobić albo go tam dodać, albo zmienić, to musi mieć dobry powód, żeby to zrobić. Więc myślę, że ta zmiana jest jak najbardziej na plus i mam nadzieję, że zostanie wprowadzona już niedługo, mniej więcej tak się na to zapatruje.

M: Czyli w zasadzie jest tak jak ja, czyli że to jest rozwiązanie bezpośrednio optymalizacyjne pod Reacta, ale nie jest to żaden game changer w stylu wprowadzenie nowego sposobu tworzenia aplikacji. Tak jak sami mówią, nie jest to SSR. W zasadzie jest to nadal React.

W: To będzie po prostu kolejna jakaś tam opcja, kolejne narzędzie w Twoim zestawie narzędzi, z którego będziesz mógł skorzystać. Wygląda to jak po prostu fajny dodatek, który można wykorzystać w jakichś specyficznych miejscach, ale który wiąże ze sobą, czy też niesie ze sobą dużo ciekawych pomysłów i sposobów na optymalizację kodu.

M: Ok. Wojtek, mamy jeszcze jeden temat. 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 MPA naszym, czyli Multi Page Application. O ten nieszczęsny WordPress zahaczyliśmy. WordPress na rynku tak jak widziałem statystyki w zeszłym roku to jest około 70% aplikacji, stron internetowych czy blogowych, firmowych, tak naprawdę pisanych w oparciu o WordPressa nadal na rynku. Wiadomo proporcja się zmienia. Prawdopodobnie docelowo na niekorzyść WordPressa, ale czy przy takiej mnogości dostępnych możliwości WordPress długo jeszcze z nami będzie? Czy w końcu ktoś go zastąpi? Czy ten kod, który tam jest - nie wiem czy miałeś przyjemność bawić się, że tak powiem, w bebechach Wodpressa...

W: Miałem tę nieprzyjemność Mateuszu.

M: Czy właśnie w związku z tym ktoś w końcu zrobi z tym porządek? Czy Wordpress według Ciebie będzie długo z nami? Bo ja odnoszę wrażenie, że to tak szybko nie odejdzie. To jest tak jak jQuery. JQuery w zasadzie nikt już świadomie nie wybiera do projektu, ale JQuery cały czas się rozwija, bo jest zależnością do wielu różnych rzeczy.

W: To nawet nie wiedziałem. Odpowiadając na Twoje pytanie a propo WordPressa Mateuszu, mam szczerą nadzieję, że to jest już koniec WordPressa. Ale jeśli zapytał byś mnie 3 lata temu, czy też zadał mi to samo pytanie, myślę że odpowiedziałbym tak samo. I myślę, że to tylko potwierdza Twój punkt widzenia, z którym ja też się, niestety, zgadzam. Czyli że WordPress z nami jeszcze chwilę zostanie. I też jestem trochę zdziwiony, że rozwiązania w tej przestrzeni takiego tworzenia stron - właśnie na takiej zasadzie WordPress'owej - jakiegoś takiego rozwiązania w miarę out of the box, tak jak oferuje WordPress, nie ma, czy też nie są aż tak popularne dzisiaj mimo mnogości tych technologii czy też właśnie adventu 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.

M: Właśnie ponoć do Gatsby jest tworzony z zbiór template'ów, ale jest on dość ubogi. Z tej perspektywy system template'ów i pluginów w Wordpress'ie wygrywa w dalszym ciągu, jeśli chodzi o headless, czyli te CMSy headless'owe, które pod takie rozwiązania o jakich dzisiaj rozmawiamy, czyli o rozwiązania właśnie typu SSR, SSG czy SPA to takie CMS headlessowe mają wielki sens i często dają często dużą swobodę użytkownikom. Nie wiem czy miałeś przyjemność z Prismic'iem pracować? Prismic działa w ten sposób, że tworzysz sobie, pomijam szatę graficzną, która jest, że tak powiem, okropna i ten UX po stronie Prismic'a jest taki sobie. Natomiast to, co on daje, on daje tak naprawdęużytkownikowi biznesowemu, temu, który będzie de facto content managerem, daje mu możliwość za pomocą tego uwielbianego przez wszystkich użytkowników drag'n'dropaa ustawianie kolejności wyświetlania komponentów w aplikacji Reactowej. Generujemy sobie jakieś komponenty, przygotowujemy je w procesie developmentu, dostarczamy je do aplikacji i Content Manager sam podejmuje decyzję, jak ta strona będzie zbudowana, z jakich komponentów, w jakiej kolejności będą one wyświetlone i z jakimi danymi. Ma to też sens. To też jest trochę odpowiedź na to, co robi WordPress, że z jednej strony my tworzymy aplikacje czy to SSR, czy SPA, czy to SSG, podpinamy w to jakiś tam system CMSowy i wychodzimy. Tak naprawdę możemy czerpać z korzyści, czyli tych wszystkich zalet, które dadzą nam poszczególne podejścia w zależności od wybranej drogi. Ale możemy czerpać też zyski z zalet tego, co dawał nam wcześniej WordPress ze swoimi znienawidzonymi przeze mnie pluginami typu Elementor. Wydaje mi się, że to jest, gdzieś to się dzieje. Pojawiają się narzędzia nawet w tej części, którą my sobie pod kątem developer experience wybieramy i pod kątem rzeczywiście wydajności, bo te aplikacje Reactowe, Angularowe czy Vue czy cokolwiek innego będą często bardziej wydajne niż WordPress zbudowany przez Elementora. Ale fakt faktem, użytkownik wydaje mi się końcowy, że wybierze jednak na razie WordPressa, bo to co powstaje jest jeszcze, że tak powiem, w powijakach. Jeszcze to jest takie niedojrzałe.

W: Zgadzam się z Tobą Mateuszu. Ostatnie moje kończące zdanie naszą dzisiejszą rozmowę. Zgadzam się z Tobą. Myślę, że też brakuje takiego rozwiązania, przynajmniej ja się z takim nie spotkałem, takiego out-of-the-box, które oferuje WordPress czyli Prismic o którym mówisz, z którym mieliśmy okazję pracować, ja niestety nie, który brzmi fajnie, póki masz zamknięte oczy z tego co rozumiem. To właśnie one dalej nie oferują takiego podejścia no-development, czyli Ty mając jakąś tam podstawową wiedzę informatyczną i oglądając tutoriale na YouTube jesteś w stanie postawić tą stronę.

M: Musisz mieć developera, który Ci dostarczy ten zestaw komponentów.

W: Myślę, że to jest ten problem. W WordPressie po prostu możesz go zainstalować, masz bazę danych, masz serwer, wybierasz template i masz gotową stronę, pozmieniasz tam kilka rzeczy, poklikasz i wszystko będzie gotowe. Tutaj jednak ten developer jest potrzebny, ktoś Ci musi opracować te komponenty.

M: Wojtku. Podsumowując, wydaje mi się, że stoimy obaj na stanowisku, że bardzo wartościową rzeczą w przypadku każdego z tych trzech podejść jest to, że deweloper experience przy każdym z tych podejść będzie stał na o wiele wyższym poziomie niż budowanie aplikacji z wykorzystaniem aplikacji typu MPA, gdzie frontend jest wbudowany w backend. Wydaje mi się też, że zgodzimy co do tego, że wybieranie pomiędzy SSR, SSG a SPA jest bardziej kwestią biznesową niż kwestią deweloperską, ponieważ każda z tych aplikacji ma trochę inne cechy, trochę inny performance, trochę inne czasy dostarczenia. I tak naprawdę biznesowo to się musi spinać. I wydaje mi się, że zgadzamy się co do tego, że rozwój tego, co się dzieje na rynku, idzie w naszym odczuciu w dobrym kierunku. Pojawia się coraz więcej opcji, coraz fajniejszych pomysłów, które tak naprawdę mogą za chwilę stać się takimi game changerami. Sam wspominałeś o Remixie, którego nie miałem przyjemności jeszcze testować w akcji, a trochę mnie do niego przekonałeś i czuję się zachęcony.

W: Super Mateuszu, wiedziałem, że będziesz dobrą osobą na zrobienie tego podsumowania. W 100 procentach się z Tobą zgadzam. Koniec końców sprowadza się to do tego, jaki przede wszystkim problem biznesowy chcemy rozwiązać. Jak to zawsze bywa jak pewnie wiecie, w takich technologiach czy też na naszym rynku programistycznym, wszystko zależy od tego, co tak naprawdę robimy, co chcemy zrobić i na czym nam zależy, jak są rozstawione nasze priorytety.

M: Myślę, że na sam koniec Wojtku warto też powiedzieć o tym, że to jest nasz pierwszy odcinek. Mamy w planach jeszcze 11, ale robimy to po raz pierwszy i chcielibyśmy w jakiś sposób też zaistnieć troszeczkę dla Was trochę w tej grupie. W związku z powyższym, jeżeli Wam się podobało, to dajcie znać w komentarzach, możecie do nas napisać. W opisie tego odcinka pojawią się dane kontaktowe, pojawią się informacje, które mogą być przydatne. Postaramy się też wrzucić wszelkiego rodzaju ciekawe linki, które mogą Wam troszeczkę poszerzyć wiedzę na temat tego, o czym tutaj rozmawialiśmy. Zachęcamy do udostępniania, do dzielenia się tym naszym contentem i mamy nadzieję do usłyszenia.

W: Dzięki wielkie. Mam nadzieję, że był to niezły początek i próba wgryzienia się w to środowisko podcastowe. Tak jak powiedział Mateusz dużo wiedzy znajdziecie poniżej i razem z odcinkiem. Dodatkowo jeszcze myślę, że tak naprawdę podczas tej naszej dzisiejszej rozmowy Mateusz zahaczyliśmy tylko o kilka tematów. W żaden nie wkleiliśmy się jakoś tam głębiej, więc pewnie fajnie sobie gdzieś tam posprawdzać te linki, które zostawimy, żeby dowiedzieć się więcej.

M: Tak jest.