Gatsby.js czy Next.js – który wybrać?

Chcesz stworzyć nową stronę firmową albo pełnoprawną aplikację i szukasz najlepszego narzędzia do tego zadania? Jeśli jesteś JavaScript Developerem albo znasz się na programowaniu, te dwa frameworki w zupełności wystarczą! Zanim przejdziemy do szczegółowego porównania, krótko wyjaśnię podstawowe założenia obu rozwiązań. Jeśli masz już doświadczenie i znasz podstawy, śmiało pomiń dwa kolejne akapity.

Czym jest Gatsby.js?

Jak podają na stronie: „Gatsby to darmowy, open-source’owy framework oparty na React, który pomaga programistom budować błyskawicznie szybkie strony i aplikacje”.

Jego głównym celem jest zapewnienie wysokiej wydajności dzięki generowaniu statycznych stron HTML. W połączeniu z wbudowanym wsparciem dla PWA, ładowaniem tylko krytycznych zasobów przy pierwszym wejściu i prefetchingiem kolejnych, otrzymujemy niemal natychmiastowe czasy ładowania. Gatsby oferuje też cały ekosystem wtyczek i gotowych motywów.

Gatsby dość jasno określa, jak dostarczać dane do aplikacji lub strony. Mimo że obsługuje różne źródła danych, takie jak headless CMS, usługi SaaS, API czy nawet pliki markdown, do wprowadzenia tych danych do aplikacji React musisz użyć GraphQL. Pełną listę funkcji znajdziesz w dokumentacji Gatsby.js. Po więcej wniosków zajrzyj też do świetnego case study Gatsby.js autorstwa naszego React Developera, Mateusza Wójcika.

Czym jest Next.js?

W przeciwieństwie do Gatsby, wydajność (choć nadal świetna) nie jest głównym celem Next.js. Jego zadaniem jest dostarczenie przemyślanego zestawu narzędzi, dzięki któremu deweloperzy mogą tworzyć strony i aplikacje renderowane po stronie serwera (Server-Side Rendering) praktycznie bez konfiguracji. Więcej o możliwościach przeczytasz w ich dokumentacji.

 Next.js daje routing, stylowanie CSS-in-JS, strukturę folderów, code splitting i data fetching od razu (out of the box). Co najlepsze, każdy z tych elementów możesz łatwo dostosować albo nawet całkowicie zastąpić. Znajdziesz mnóstwo przykładów integracji Next.js z innymi narzędziami.

Kto używa Gatsby.js i Next.js?

Możesz się zastanawiać, które duże firmy korzystają z tych frameworków. To świetne pytanie, a odpowiedź brzmi… bardzo wiele! Oto kilka przykładów:

Next.js

Wersja mobilna Twitcha,

strona Netflix Jobs,

Hulu,

IGN,

TikTok,

InVision.

Gatsby.js

Airbnb Engineering,

Impossible Foods,

Braun Canada,

Figma,

SendGrid,

Nike.

Gatsby i Next: podobieństwa

Zanim przejdziemy do różnic, zobaczmy, co łączy te frameworki. Przede wszystkim, niezależnie od wyboru, otrzymasz wydajną stronę lub aplikację — choć osiągnięte innymi metodami. Dodatkowo Next.js i Gatsby.js zapewniają dobre SEO od razu, ponieważ oba dostarczają już wyrenderowany HTML (przynajmniej przy pierwszym renderze).

Jak wspomniano wyżej, w obu narzędziach możesz liczyć na świetne doświadczenia deweloperskie (DX). Oba wspierają hot reloading od razu. W zależności od potrzeb to duża przewaga nad Create React App, gdzie większość konfiguracji i decyzji architektonicznych musisz podjąć samodzielnie. Ponieważ oba frameworki nie są przesadnie skomplikowane, krzywa uczenia jest dość łagodna, a do tego mają znakomitą dokumentację i tutoriale.

Inne przydatne funkcje, które Gatsby.js i Next.js realizują podobnie, to: 

caching,

code splitting,

prefetching,

routing.

Gatsby i Next: różnice

Skoro oba frameworki są tak podobne, to czym się różnią? Jest kilka kluczowych kwestii, ale najważniejsze to sposób renderowania stron oraz obsługa danych.

Renderowanie stron

Jak wspomniano, Next.js renderuje strony z użyciem Server-Side Rendering. Dlatego, aby uruchomić aplikacje stworzone w tym narzędziu, potrzebujemy serwera Node.js, który przy każdym żądaniu będzie dynamicznie renderował HTML. Wszystko dzieje się w runtime. Po wczytaniu początkowego HTML-a Next.js przeprowadza hydrację, aby aplikacja stała się interaktywna. 

Gatsby.js natomiast generuje HTML na etapie budowania (build time), dlatego często uznawany jest za generator statycznych stron. Nie jest to do końca precyzyjne, bo potrafi działać jako PWA i bez problemu obsługiwać wywołania API. Główna zaleta tego podejścia jest taka, że nie potrzebujemy żadnego serwera Node.js do renderowania. 

Po buildzie mamy już pliki HTML/CSS/JS, które możemy hostować gdzie chcemy. Brzmi świetnie, ale to podejście ma też wady — zwłaszcza gdy strona ma wiele podstron. Po każdej aktualizacji danych trzeba wywołać rebuild, który wygeneruje na nowo wszystkie pliki HTML, a przy setkach stron może to zająć sporo czasu.

Obsługa danych

Oba frameworki podeszły do tematu zupełnie inaczej. Gatsby.js dokładnie wskazuje, jak pobierać dane (GraphQL), podczas gdy Next.js pozostawia tę decyzję w pełni deweloperowi. Ze względu na podejście Gatsby skupimy się na nim — bo właśnie tego musisz używać. 

GraphQL pozwala pobrać tylko te dane, których potrzebujesz dla danej strony. Z drugiej strony wiąże cię z technologią, której być może nie chcesz używać. Gatsby.js oferuje też wiele wtyczek, dzięki którym połączysz się z różnymi źródłami danych. W trakcie procesu budowania dane są pobierane i zapisywane w plikach JSON do późniejszego użycia. Mogą być też aktualizowane w razie potrzeby. Obszerniejsze informacje o tym procesie znajdziesz na stronie Gatsby.js.

Gatsby czy Next: czego użyć?

W przypadku małych i średnich projektów z żadnym z nich nie popełnisz błędu. Weź pod uwagę różnice — szczególnie podejście do pobierania danych — i wybierz to, które bardziej odpowiada twoim preferencjom. Polecamy Gatsby, jeśli tworzysz stronę w oparciu o JAMstack, blog osobisty albo po prostu prostą stronę statyczną. Jeśli nie chcesz używać GraphQL i budujesz bardziej dynamiczną stronę lub hybrydową aplikację (np. jak Twitter czy Reddit), Next.js może być lepszym wyborem — głównie dzięki SSR w czasie działania (runtime).

Sprawa komplikuje się przy dużych serwisach z setkami czy tysiącami podstron i treści dodawanych przez wielu użytkowników. W takim przypadku zwycięzcą jest Next.js dzięki podejściu do SSR. Jak wspomniano, Gatsby.js generuje każdą stronę przy każdym rebuildzie. Przy dużych zbiorach treści może to trwać nawet do 20 minut. Ponieważ użytkownicy chcą widzieć dodaną zawartość w czasie rzeczywistym, a nie czekać minuty czy wręcz godziny w skrajnych przypadkach, statyczne generowanie strony nie sprawdzi się w tym zadaniu.

Jak widać, odpowiedź na nasze główne pytanie nie jest prosta — chyba że tworzysz dużą aplikację lub serwis z 500+ stronami. Jak zwykle, warto dobrać narzędzie do zadania na podstawie jego funkcji i własnych preferencji. Mamy nadzieję, że ten przewodnik pomoże ci podjąć decyzję i da wystarczającą wiedzę o plusach i minusach obu frameworków, abyś był zadowolony z wybranego rozwiązania. Chcesz wiedzieć więcej? Napisz na hello@start-up.house