1.05 (5) NextJS i co dalej?

Mianowicie dzisiaj chcieliśmy porozmawiać o NextJS jako framework, który wprowadza sporo zamieszania na rynku usług IT. Myślę, że to zamieszanie jest bardzo dobre. I dzięki temu tak naprawdę wprowadza troszeczkę może świeżości, troszeczkę dynamiczności do tego, jak ten rynek się ostatnimi laty rozwijał. Cześć Wojtku. Cześć Mateuszu. Powiedziałem na samym początku, chciałbym żebyśmy dzisiaj porozmawiali o Nextie. Jak ten temat ci leży? Jest to zdecydowanie ciekawy temat i też jak najbardziej chciałbym z tobą porozmawiać Mateuszu i poznać swoją opinię na temat samego Nexta, ale w ogóle podejście tej drogi, no tak, tej drogi Którą zmierzamy jako deweloperzy React'owi, bo przecież sam React w swojej dokumentacji w tym nowym wydaniu już poleca Nexta razem z tymi nowymi frameworkami SSR jako podstawę wszystkich nowych projektów.

To prawda, polecają. Warto też spojrzeć na to, jak to się zmieniło na przestrzeni ostatnich lat, bo jeżeli sobie cofniemy się troszeczkę w czasie, zobaczymy, że React jak zaczynał, to tak naprawdę on zaczął bardzo mocno polecał Swój własny framework do budowania aplikacji oparty o React. Mam na myśli Create React App, o ile można to nazwać mini frameworkiem, jakimś narzędziem, który tak naprawdę pomagał w budowaniu tych aplikacji, ale jak wiemy Create React App już nie jest, jakby to ładnie powiedzieć, nie jest na topie. Teraz można powiedzieć, że już tak naprawdę powoli nam Odchodzi niepamięć.

I nawet sam React, który w zasadzie jest twórcą Creative Act Apa, doprowadził do tego, że poleca narzędzia zewnętrzne. Nexta. Dlaczego poleca tego Nexta? Co w nim jest takiego ciekawego, że ten Next rzeczywiście jest fajniejszy niż ten Create React App, czy chociażby inne narzędzia, które są do tej pory tutaj dostępne na rynku i które służą dokładnie do tych samych rzeczy? To znaczy myślę, że Next, jak i pozostałe tego typu frameworki, symbolizują niejako moim zdaniem Kierunek, w którym cały team Reactowy chce się poruszać w nadchodzącej przyszłości, czyli odejście od wykonywania całego kodu u klienta w przeglądarce, niezależnie czy to jest przeglądarka desktopowa czy przeglądarka mobilna,

Właśnie w kierunku takiego podejścia hybrydowego, gdzie część rzeczy jest wykonywana na serwerze, gdzie chcemy wykorzystać ten serwer najlepiej jak potrafimy i skorzystać ze wszystkich dobrodziejstw, które daje nam wykonywanie JavaScriptu na serwerze i wykorzystanie tych Rzeczy, które daje nam wykonywanie... To wszystko przypomina mi się nasza rozmowa o SPA i SSR-ze. Tak naprawdę tutaj chyba ten koncept aplikacji hybrydowych, o którym wspomniałeś, fajnie się zazębia, bo te aplikacje klienckie są trochę passé, można powiedzieć, już w tym momencie. Mają swoje wady, o których już też mówiliśmy, odsyłamy też do naszej poprzedniej rozmowy na ten temat.

Na przykład etykiety. To też jest ciekawe rozwiązanie, rzadko kiedy wykorzystywane. Często myli się ludziom, deweloperom, bo nie wiedzą o istnieniu tego. Myślą, że to jest po prostu jakiś obiekt dziwny. Tak naprawdę to jest jakaś etykieta, która pozwala nam chociażby bardziej optymalnie zarządzać pętlami. Ale to są takie niuanse języka, których wiele ludzi nie zagląda i tak naprawdę mało kto wie, że coś takiego można zrobić. Ale to właśnie o to chodzi, że język to jest narzędzie. Bardziej to jest narzędzie, a Next jest frameworkiem jakimś nadrzędnym, nad budówką, na reacta, czyli na tę bibliotekę do zarządzania właśnie mutacjami w strukturach.

No nie da się tego zrobić dobrze. Dlatego też Firmy zdecydowały się w końcu na przejście właśnie na te rozwiązania czy od Adobe, czy właśnie od Magento, czy od Presty, czy od WordPressa. Tego się pojawiło od groma, ale za tymi projektami stała społeczność, która dostarczała nowe pomysły, która dostarczała rozwiązania popularnych błędów, która dostarczała wtyczki. I to jest trochę tutaj obserwujemy dokładnie to samo, wydaje mi się. Bo sam React, wiesz, za nim stoi ogromna rzesza ludzi, ale sam React chyba już zauważył, że pomimo to jest nadal tylko i wyłącznie biblioteką.

Ale wracając już do naszych tematów programistycznych, zgadzam się z tobą, chociaż myślę, że to był w ogóle duży plus Reacta od samego początku, że ten core'owy team Reacta od tej wersji szesnastej, tak na dobrą sprawę, on był dość mały, ale dość się twardy na to, co się dzieje w community. Chociaż to było też fajnie, bardzo moim zdaniem moderowane. Dzięki temu też ten framework się tak nie rozrósł i myślę, że to jest ogromny plus właśnie w porównaniu do takiego Angulara, gdzie masz tysiąc narzędzi zapewnionych przez sam framework. A w Reactie bardzo dużo rzeczy możesz wybrać samemu. Od routingu, które mamy dwie duże biblioteki, tak? Po narzędzie do defleczowania danych, więc właśnie to Community bardzo mocno wzbogaca ten framework i widzimy to tutaj znowu ponownie na przykładzie Nexta.

Tak samo jest z Nextem. Next też dostarcza cały zestaw bibliotek. Od fontów, poprzez obrazki i routing, skończywszy na chociażby takich paczkach do dynamicznego ładowania komponentów. Więc mi się wydaje, że Nextowi bliżej do Do Frameworka, czy też do konkurencji dla Angulara, niż Reactowi, który sam w sobie, pomimo tego, że jest to po prostu biblioteka, która ma jakiś tam model kompozycyjny zapewnić, która dostarcza kilka fajnych API typu właśnie konteksty, to poza tym tak naprawdę w Reactie nic nie ma. Może to był też powód, dla którego zespół core'owy Reacta postanowił właśnie znaleźć kogoś, kto im pomoże, bo trochę może utknęli.

Bo może utknęli właśnie w tym takim rozwijaniu biblioteki. Gdzieś musieli zrobić następny krok, żeby po prostu tego Reacta puścić do przodu. No bo pojawia się bardzo dużo koncepcji nowych typu właśnie wprowadzenie chociażby React Server Components. Pojawiają się nowe refactoringi, pojawiła się ostatnim czasem nowa dokumentacja, która jest o wiele fajniejsza, czytelniejsza. Więc ten projekt żyje, on się rozwija. Gdzieś tam usuwają stare legacy API, pojawiają się różnego rodzaju dodatki, które mają spowodować, że będzie nam się lepiej z tym pracowało.

Ale w ostatecznym rozrachunku React nadal pozostawia dużo wolności, bo to jest biblioteka. Pozostawia wolność, którą ty możesz sobie samodzielnie zagospodarować tak jak chcesz. Next opozycji jest. Next już tego nie daje. Next mówi słuchajcie, tu macie routing, tu macie images, tu macie fonts, tu macie to, tu macie tamto. Kto razem tworzy Nexta? Chcecie korzystać z Nexta? Korzystajcie z tego, co wam dostarczamy. Zgadzam się z tobą Mateuszu, chociaż myślę, że w momencie kiedy jesteś autorem takiej biblioteki jak RIAC, moim zdaniem jest to dla ciebie idealne w ogóle rozwiązanie. Ktoś testuje różne podejście do twojej biblioteki.

I po przetestowaniach zupełnie oddzielnie gdzieś właśnie na boku, czy jeśli chodzi o jakiś routing, data fetching i tak dalej i tak dalej, możesz bardzo szybko, ta biblioteka może ewoluować, w związku z tym, że jest mała i właśnie oddzielnie są te wszystkie zależności jakieś dodatkowe. I bardzo możesz go też dostosowywać w momencie, kiedy już dochodzi do takiego momentu, że chcesz jakoś mocno zmienić framework, tak jak w przypadku Reacta i React Server Components, gdzie jest to ogromna zmiana jakby właśnie w samym podejściu do myślenia o tej bibliotece. Właśnie dlatego, że Jest całe to community, które tworzy te wszystkie narzędzia, testuje, sprawdza co najlepiej działa, a ty jako autor biblioteki możesz korzystać z tej całej pracy, która została zrobiona dookoła tego.

I ty jesteś odpowiedzialny za tę część komponenty slash routing, a ja jako ala backend developer jestem odpowiedzialny dalej w tej samej aplikacji, w tych samych komponentach za właśnie tę część ala backendową, czyli zapewnianie ci tych server actions w postaci SQL-a i tym podobnych rzeczy. Powiem ci, że to jest dość zabawne. Zabawna perspektywa. Pomyślałem sobie, że Jakbyśmy spojrzeli na to, że kiedyś ten frontend był traktowany tak po macoszemu i w zasadzie nikt się nim nie przejmował o tą frontend, a tylko CSS i HTML, to co to tam ma być? I najczęściej było tak, że jeżeli mieliśmy aplikacje typowo właśnie serwerowe, te tak zwane MPA, to było tak, że ten frontend był generowany przez backend i wysyłany do przodu.

Wyglądało, tylko że mówię od strony backendowej. No tak. Od strony backendowej, frontend tam przychodził, o tutaj sobie coś tam dopiszę. Jakieś jQuery dodam. Dokładnie, dodam jQuery i będę programistą. Będę programistą i będę tam tworzył. To było we wszystkich frameworkach. To backend narzucał to, jak backend będzie generowany. Chociażby Magento 1. Zobacz, backend podjął decyzję, że struktury będą definiowane za pomocą XML-a i lub, bo można było tak lub tak, PHTML-ek. To był wymysł backendu, bo chciał dostarczać jakieś dane, jakieś kontrolki, które można było wstrzyknąć do komponentu.