Zespół Railway, platformy do wdrażania aplikacji z ponad 200 trasami na frontendzie, właśnie opublikował wpis o tym, jak przenieśli cały frontend z Next.js na Vite z TanStack Routerem. Dwa pull requesty, zero przestojów, czas budowania z ponad 10 minut do niecałych 2. Post wylądował na szczycie Hacker News z prawie 2000 punktów i wywołał dyskusję, którą programiści webowi prowadzą już od dawna: czy Next.js nie stał się za ciężki na to, do czego go używamy?
Dlaczego Railway odeszło od Next.js?
Problem Railway z Next.js nie pojawił się nagle. Narastał. Buildy frontendu przekroczyły 10 minut, z czego 6 minut zjadał sam Next.js. Połowę tego czasu framework spędzał na etapie “finalizing page optimization”, czyli optymalizacji stron, której zespół Railway nie potrzebował.
Railway deployuje kilka razy dziennie. Każdy deploy to oczekiwanie na build. 10 minut razy kilka deployów dziennie razy cały zespół – to setki minut straconych tygodniowo na czekanie, aż framework skończy optymalizować coś, co i tak działa po stronie klienta.
Drugi problem był głębszy: architektura Next.js zakłada, że aplikacja jest serwerowa. Pages Router wymuszał niestandardowe obejścia dla współdzielonych layoutów. App Router, nowsza wersja, jeszcze mocniej pchał w kierunek renderowania po stronie serwera. Railway tego nie potrzebowało. Ich aplikacja to dashboardy w czasie rzeczywistym z połączeniami WebSocket, prawie w całości po stronie przeglądarki. Używali serwerowego frameworka do budowania aplikacji klienckiej.
Na co przeszli i jak wyglądała migracja?
Railway wybrało Vite jako bundler i TanStack Router do obsługi tras. TanStack Start (pełny framework) dał im możliwość renderowania po stronie serwera tam, gdzie tego potrzebowali (strony marketingowe), bez wymuszania tego podejścia wszędzie.
Migracja przebiegła w dwóch pull requestach:
- Pierwszy PR usunął wszystkie zależności od Next.js: komponenty
next/image,next/head,next/routeri inne importy specyficzne dla frameworka. To była praca porządkowa, setki commitów przed scaleniem. - Drugi PR zamienił sam framework: 200+ tras, integracja z serwerem Nitro, konfiguracja nowego routera. Scalono w niedzielę rano, poprawki lądowały tego samego dnia przez “pokój wojenny” na Discordzie. Produkcja nie miała ani minuty przestoju.
Konkretne liczby: co się zmieniło po migracji?
Czas budowania spadł z ponad 10 minut do niecałych 2. Serwer deweloperski startuje praktycznie natychmiast. Zmiany w kodzie pojawiają się w przeglądarce bez zauważalnego opóźnienia, bo Vite wymienia tylko zmieniony moduł, a nie przebudowuje całość.
Railway przyznaje, że straciło kilka rzeczy: wbudowaną optymalizację obrazów (zastąpioną przez Fastly na brzegu sieci) i gotowe narzędzia typu next-seo (przebudowane wewnętrznie). Zaakceptowali też ryzyko, że TanStack Start jest młodszym projektem niż Next.js, ale zaufali utrzymującym i zainwestowali w sponsoring projektu.
Czy Next.js ma problem? Co mówi reszta branży?
Railway nie jest pierwszą firmą, która odchodzi od Next.js w 2026. Na forach deweloperskich i w raportach branżowych powtarzają się podobne problemy:
- Serwer deweloperski Next.js startuje przy ~300 MB pamięci na średniej aplikacji i potrafi urosnąć do 9-10 GB podczas nawigacji między trasami. Wycieki pamięci powodujące awarie w Dockerze i Kubernetesie udokumentowano na początku 2026.
- Granica między kodem serwerowym a klienckim jest niewidoczna, dopóki coś się nie zepsuje. Deweloperzy nie wiedzą, kiedy ich kod działa na serwerze, a kiedy w przeglądarce.
- Framework stał się zbyt skomplikowany. Dwa systemy routingu (Pages Router i App Router), kilka sposobów na pobieranie danych, nieoczywiste reguły cache – próg wejścia rośnie z każdą wersją. Podobne problemy z rosnącą złożonością narzędzi opisywaliśmy w kontekście architektury agentów AI w Claude Code, gdzie prostota i przejrzystość okazały się ważniejsze od liczby funkcji.
Jednocześnie Next.js nie umiera. Vercel rozwija go aktywnie, ekosystem jest ogromny, a dla wielu projektów (zwłaszcza stron z dużą ilością treści i wymaganiami SEO) nadal jest dobrym wyborem. Problem polega na tym, że zespoły używają Next.js do wszystkiego, w tym do aplikacji czysto klienckich, gdzie jego serwerowe założenia stają się obciążeniem.
Kiedy warto rozważyć odejście od Next.js?
Nie każdy projekt powinien porzucać Next.js. Ale jeśli rozpoznajesz w tym któryś ze swoich problemów, warto się zastanowić:
- Twoja aplikacja jest głównie kliencka (dashboardy, panele administracyjne, narzędzia wewnętrzne) i nie korzystasz z renderowania po stronie serwera.
- Buildy trwają minuty, a deployujesz kilka razy dziennie.
- Serwer deweloperski zjada pamięć i zwalnia z każdą nawigacją.
- Walczysz z “magią” frameworka zamiast pisać logikę biznesową.
Alternatywy, które zyskują popularność w 2026: Vite + TanStack Router (wybór Railway), Astro (dla stron z treścią), Remix (prostsze podejście do danych), SvelteKit (jeśli chcesz odejść od Reacta). Każde z nich rozwiązuje inny problem.
Kurs n8n 2.0 · Kodożercy
Automatyzacja to dziś jedna z najbardziej poszukiwanych umiejętności
Firmy szukają ludzi którzy łączą procesy z narzędziami. Kurs n8n 2.0 na Kodożercach da Ci praktyczne umiejętności – webhookie, API, automatyczne przepływy danych – które możesz pokazać już jutro.
Zobacz program kursu →
FAQ – Najczęstsze pytania o migracji z Next.js
Czy Next.js jest zły?
Nie. Next.js to solidny framework z ogromnym ekosystemem, świetny do stron z dużą ilością treści, blogów i witryn wymagających SEO. Problem pojawia się, gdy zespoły używają go do aplikacji czysto klienckich, gdzie serwerowe założenia frameworka stają się balastem zamiast zaletą.
Jak długo trwała migracja Railway?
Railway przeniosło ponad 200 tras w dwóch pull requestach, z zerowym przestojem produkcyjnym. Scalenie głównego PR-a odbyło się w niedzielę rano, a poprawki lądowały tego samego dnia. Przed scaleniem powstały setki commitów przygotowawczych.
Co to jest TanStack Router i czy jest stabilny?
TanStack Router to biblioteka routingu dla Reacta od twórcy TanStack Query (dawniej React Query). Oferuje trasowanie oparte na systemie plików, pełne typowanie TypeScript i automatyczne uzupełnianie. Jest młodsza od Next.js, ale Railway zaufało jej na tyle, żeby sponsorować projekt.
Podsumowanie
Railway przepisało ponad 200 podstron z Next.js na Vite i TanStack Router. Zrobili to w dwóch pull requestach, bez przestojów. Efekt? Budowanie projektu spadło z ponad 10 minut do niecałych 2. Serwer deweloperski startuje od razu, zmiany w kodzie widać natychmiast. Co ważne, nie odeszli dlatego, że Next.js jest słaby. Po prostu Next.js jest stworzony do aplikacji serwerowych, a Railway buduje aplikację kliencką opartą na WebSocketach. To jak zakładanie garnituru do gry w piłkę – garnitur jest dobry, ale nie do tego. W 2026 coraz więcej zespołów podejmuje podobne decyzje. Alternatywy jak Vite, Astro czy Remix są na tyle dojrzałe, że warto dopasować narzędzie do tego, co faktycznie budujesz, zamiast domyślnie sięgać po najpopularniejszy framework.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
