Jeśli spędziłeś ostatnie kilka lat, skacząc między meta-frameworkami, SvelteKit 2 wyda Ci się dziwną mieszanką ulgi i podejrzliwości. Ulgi, ponieważ faktycznie redukuje złożoność, zamiast ją dodawać. Podejrzliwości, ponieważ wciąż czekasz na haczyk. Ten haczyk jednak nigdy nie nadchodzi. W połączeniu z Svelte 5, ten stos technologiczny jest jednym z najbardziej produktywnych sposobów na wdrożenie aplikacji full-stack w 2026 roku, a liczby potwierdzają świetne doświadczenia programistyczne. Pakiety (bundles) są o około 35% mniejsze niż te generowane przez Svelte 4. Routing, funkcje serwerowe i wzorce uwierzytelniania to obywatele pierwszej kategorii, a nie wtyczki, które musisz sklejać na taśmę.

Runy czynią reaktywność jawną

Największa zmiana mentalna wynika z wprowadzenia run w Svelte 5. Poprzednie wersje Svelte używały etykiety $: i sporej dawki magii kompilatora do śledzenia zależności. Działało to, ale gdy coś się psuło, debugowałeś niewidzialne połączenia. Runy zastępują tę magię jawnymi funkcjami. Mówisz kompilatorowi dokładnie, co ma śledzić, a on słucha.

Oto co musisz wiedzieć.

  • $state obsługuje zmienne reaktywne. Zamknij dowolną wartość w $state(), a kompilator będzie ją śledził.
  • $derived oblicza wartości na podstawie innego stanu. Potrzebujesz przefiltrowanej listy lub sformatowanej sumy? Użyj $derived. Kluczową różnicą wzglę się do $effect jest to, że $derived służy do wartości, a nie do akcji.
  • $effect uruchamia efekty uboczne. Myśl o aktualizacjach tytułu dokumentu, ręcznych pomiarach DOM czy timerach wymagających sprzątania. Uruchamia się po zatwierdzeniu zmian w DOM, podobnie jak hook cyklu życia, ale jest powiązany z konkretnymi zależnościami reaktywnymi.
  • $props zastępuje stary wzorzec export let służący do odbierania danych w komponentach. Jest jaśniejszy i lepiej współpracuje z TypeScriptem.

Ten model sprawdza się w praktyce. Ponieważ kompilator śledzi tylko to, co oznaczysz, martwy kod pozostaje martwy. Przestajesz się zastanawiać, dlaczego zmienna wywołała aktualizację, i zaczynasz ufać własnym, jawnym instrukcjom.

Routing oparty na folderach, a nie na konfiguracji

SvelteKit wykorzystuje system plików do routingu. Nie ma potrzeby utrzymywania osobnego pliku routera. Wrzuć plik +page.svelte do katalogu, a katalog ten stanie się aktywną trasą.

Wspólny interfejs (UI) opakowuje te trasy za pomocą +layout.svelte. Umieść go w katalogu głównym (root), a każda trasa podrzędna go odziedziczy. Umieść go głębiej w strukturze, a opakowanie otrzyma tylko ta sekcja.

Logika po stronie serwera znajduje się w +page.server.ts. Wykonuje się ona przed wyrenderowaniem strony, więc to właśnie tam wykonujesz zapytania do bazy danych, weryfikujesz ciasteczka lub odrzucasz nieautoryzowanych użytkowników. Typy automatycznie przepływają z funkcji load do komponentu strony, co oznacza, że Twoje dane są typowane bez konieczności ręcznego pisania interfejsów.

Surowe punkty końcowe API (endpoints) umieszcza się w plikach +server.ts. Eksportują one standardowe handlery HTTP — GET, POST, PUT, DELETE — dzięki czemu budowanie backendu REST obok stron wydaje się naturalne.

Jedna niedoceniana funkcja: grupowanie tras. Poprzez umieszczenie nazwy folderu w nawiasach, np. (auth), tworzysz wspólny układ bez dodawania segmentu do adresu URL. Jest to idealne dla stron logowania i rejestracji, które potrzebują tej samej minimalistycznej oprawy, ale znajdują się pod /login i /signup, a nie /auth/login.

Dane, bezpieczeństwo i progresywne ulepszanie

Nowoczesne frameworki uwielbiają mówić o rozwiązaniach full-stack, ale wiele z nich pozostawia Cię w niepewności co do tego, gdzie umieścić sprawdzanie uwierzytelnienia lub logikę formularzy. SvelteKit oferuje jasne punkty styku.

Używaj +page.server.ts do pobierania danych. Funkcja load działa tam wyłącznie na serwerze, więc Twoje poświadczenia do bazy danych nigdy nie wyciekną do przeglądarki. SvelteKit generuje typy na podstawie wartości zwracanych przez funkcję load, dzięki czemu Twój frontend pozostaje spójny.

Używaj hooks.server.ts, aby kontrolować dostęp do całej aplikacji. Wykonuje się to przy każdym żądaniu, co czyni to idealnym miejscem do weryfikacji sesji, sprawdzania wygaśnięcia JWT lub dołączania kontekstu użytkownika do nadchodzących zdarzeń.

W przypadku mutacji używaj akcji formularza (form actions). Zamiast podłączać osobny endpoint API i obsługiwać

Oba frameworki pozwalają na wdrażanie aplikacji produkcyjnych, ale wiążą się z konkretnymi kompromisami.

Pod względem rozmiaru paczki (bundle size) wygrywa SvelteKit. Ponieważ Svelte kompiluje komponenty do czystego JavaScriptu i całkowicie pomija Virtual DOM, narzut runtime pozostaje niewielki. Next.js musi natomiast obsługiwać silnik reconciliacji Reacta.

Reaktywność również się różni. SvelteKit rozwiązuje runes w czasie kompilacji, dzięki czemu przeglądarka otrzymuje proste aktualizacje. Next.js polega na hookach i mechanizmie reconciliacji Reacta w czasie rzeczywistym, co oznacza, że więcej pracy musi wykonać klient.

Onboarding w SvelteKit jest łatwiejszy. Model mentalny jest mniej złożony. Nie musisz żonglować tablicami zależności useEffect ani rozwiązywać zagadek związanych z memoizacją, aby uniknąć ponownego renderowania. Warto również wspomnieć o integracji z TypeScriptem. Choć oba frameworki