Якщо ви провели останні кілька років, перестрибуючи між метафреймворками, SvelteKit 2 викличе у вас дивне поєднання полегшення та підозри. Полегшення — тому що він насправді зменшує складність, а не додає її. Підозри — тому що ви постійно чекаєте, що ось-ось щось піде не так. Але цього ніколи не стається. У поєднанні зі Svelte 5 цей стек є одним із найпродуктивніших способів розробки full-stack додатків у 2026 році, і цифри підтверджують якість досвіду розробника. Розмір бандлів приблизно на 35% менший, ніж у Svelte 4. Маршрутизація, серверні функції та патерни автентифікації є повноцінними можливостями системи, а не плагінами, які доводиться з'єднувати «синьою ізоляційною стрічкою».

Руни роблять реактивність явною

Найбільший зміст у сприйнятті приносять руни (runes) у Svelte 5. Попередні версії Svelte використовували мітку $: та багато магії компілятора для відстеження залежностей. Це працювало, але коли щось ламалося, ви відлагоджували «невидимі дроти». Руни замінюють цю магію явними функціями. Ви чітко вказуєте компілятору, що саме потрібно відстежувати, і він слухає.

Ось що вам потрібно знати.

  • $state керує реактивними змінними. Огорніть будь-яке значення в $state(), і компілятор зрозуміє, що за ним треба стежити.
  • $derived обчислює значення на основі іншого стану. Потрібен відфільтрований список або відформатована сума? Використовуйте $derived. Ключова відмінність від $effect полягає в тому, що $derived призначений для значень, а не для дій.
  • $effect виконує побічні ефекти. Думайте про оновлення заголовка документа, ручні вимірювання DOM або таймери, які потребують очищення. Він запускається після того, як DOM зафіксовано (commits), подібно до хука життєвого циклу, але прив'язано до конкретних реактивних залежностей.
  • $props замінює старий патерн export let для отримання даних у компонентах. Це зрозуміліше і краще взаємодіє з TypeScript.

Ця модель окупається на практиці. Оскільки компілятор відстежує лише те, що ви позначили, мертвий код залишається мертвим. Ви перестаєте гадати, чому змінна спровокувала оновлення, і починаєте довіряти власним явним інструкціям.

Маршрутизація за допомогою папок, а не конфігурації

SvelteKit використовує вашу файлову систему для маршрутизації. Вам не потрібно підтримувати окремий файл роутера. Покладіть файл +page.svelte у директорію, і ця директорія стане живим маршрутом.

Спільний інтерфейс (UI) огортає ці маршрути через +layout.svelte. Розмістіть його в корені, і кожен дочірній маршрут успадкує його. Розмістіть його глибше в дереві, і обгортка застосується лише до цієї секції.

Серверна логіка живе в +page.server.ts. Вона виконується перед рендерингом сторінки, тому саме тут ви робите запити до бази даних, перевіряєте cookie або відхиляєте неавторизованого користувача. Типи автоматично передаються з вашої функції load у компонент сторінки, що означає, що ваші дані типізовані без написання ручних інтерфейсів.

Сирі API-ендпоінти розміщуються у файлах +server.ts. Вони експортують стандартні обробники HTTP — GET, POST, PUT, DELETE — тому створення REST back end поруч із вашими сторінками виглядає природно.

Одна недооцінена функція: групування маршрутів. Огорнувши назву папки в дужки, наприклад (auth), ви створюєте спільний макет (layout) без додавання сегмента до URL. Це ідеально підходить для сторінок входу та реєстрації, яким потрібен однаковий мінімалістичний інтерфейс, але які мають жити за адресами /login та /signup, а не /auth/login.

Дані, безпека та прогресивне покращення

Сучасні фреймворки люблять говорити про full-stack, але багато з них залишають вас у здогадках, куди саме ставити перевірки автентифікації або логіку форм. SvelteKit надає чіткі інструменти.

Використовуйте +page.server.ts для отримання даних. Функція load там виконується виключно на сервері, тому ваші облікові дані бази даних ніколи не потраплять у браузер. SvelteKit генерує типи на основі значень, які повертає load, тому ваш фронтенд завжди працює з коректними даними.

Використовуйте hooks.server.ts, щоб обмежити доступ до всього додатка. Це виконується під час кожного запиту, що робить цей файл ідеальним місцем для перевірки сесій, терміну дії JWT або додавання контексту користувача до вхідних подій.

Для мутацій використовуйте form actions. Замість того, щоб підключати окремий API-ендпоінт і обробляти JSON, ви визначаєте дію (action) всередині +page.server.ts. Краса тут у прогресивному покращенні. Якщо JavaScript не завантажився — або якщо користувач його вимкнув — форма все одно надішле дані на серверну дію, і сторінка перерендериться з результатом. Якщо JavaScript присутній, SvelteKit покращує цей досвід без повного перезавантаження сторінки. Ви отримуєте стійкість і відшліфованість за допомогою одного й того самого коду.

Одне правило, яке варто пам'ятати: виконуйте обчислення в $derived, а не в $effect. Використання $effect для обчислення значень може спричинити цикли оновлень, які важко відстежити. Залиште $effect для справжніх побічних ефектів, а $derived нехай відповідає за ваш обчислюваний стан.

SvelteKit проти Next.js

Обидва фреймворки підходять для розгортання production-застосунків, але компроміси є реальними.

Розмір бандла — перевага SvelteKit. Оскільки Svelte компілює компоненти у чистий JavaScript і повністю оминає Virtual DOM, розмір середовища виконання залишається мінімальним. Next.js несе з собою механізм reconciliation React.

Реактивність також відрізняється. SvelteKit обробляє runes під час компіляції. Браузер отримує прості оновлення. Next.js покладається на runtime-хуки та reconciliation React, що означає, що більше роботи виконується на стороні клієнта.

Ознайомлення з SvelteKit проходить легше. Ментальна модель простіша. Вам не потрібно маніпулювати масивами залежностей useEffect або розв'язувати головоломки з мемоїзацією, щоб уникнути повторних рендерингів. Інтеграцію з TypeScript також варто згадати. Хоча обидва фреймворки