SvelteKit. Його переваги й недоліки

Алекс Монахов

Фреймворк який підтримує SSR і SSG, але має суттєву перевагу над Next.js та Nuxt.js.

Перевага полягає у тому, що оскільки SvelteKit не юзає Virtual DOM, то для нього гідрація на клієнті не така страшна як для Next.js та Nuxt.js.

Нагадаю, шо там відбувається під час SSR-рендерингу.

  1. Ми рендеримо на сервері.
  2. Результат рендеру конвертуємо в HTML (на інішл лоаді).
  3. Віддаємо HTML + JS (який потрібен для гідрації).
  4. Браузер отримав HTML і шоб відтворити Virtual DOM, ще раз рендерить документ.
  5. Тільки після рендеру навішуються обробники подій, що робить сторінку інтерактивною.

Тобто, проблема на кроці 4 призводить до того, що:

  1. JS-файл, який сервер віддає клієнту, є великим;
  2. Вантажиться він довше;
  3. Юзає CPU клієнта для повторного рендеру.

Цю траблу частково хендлять в Next.js серверні компоненти, які не гідруются на клієнті. Але ж не всі компоненти серверні. Клієнтські компоненти так само мають цю проблему, просто тепер обсяг проблеми — не абсолютно всі компоненти, а тільки клієнтські, що все ще не ідеально.

В SvelteKit, оскільки ми не маємо Virtual DOM, при гідрації ми просто одразу навішуємо обробники подій на певні DOM-елементи.

Тобто, JS-файл, який ми відправляємо на клієнта, у нас менший, бо там тільки код для обробки подій. Також ми не «жремо» CPU клієнта, бо нам не треба рендерити Virtual DOM на клієнті.

Тому в SvelteKit немає потреби в серверних компонентах, так як проблеми, яку вони вирішують, просто нема у SvelteKit.

Є одна проблема…

У SvelteKit при цьому є інший мінус, з яким я зіштовхнувся. Це мале ком’юніті. Тобто, наприклад, якшо взяти Angular, то навколо нього вибудовуєтся той же Firebase, з Next.js — той Vercel, який дає комфортно юзати останні фічі фреймворку.

З SvelteKit поки не знайшов прям комфортного рішення. Спочатку глянув Firebase, там зараз активно розвивають App Hosting фічу — хостінг додатків, збудованих на SSR-фреймворках, поки що підтримує Angular та Next.js.

SvelteKit можна розгорнути на Firebase, але на cloud-функціях. Але, узявши до уваги, що вже розроблятся той же App Hosting як більш привабливе рішення, то влазити в cloud-функції не дуже хочеться.

Потім глянув, що там у Vercel, як там розгорнути SvelteKit. Це здалося простіше, ніж у Firebase, але все ж не так просто, як Next.js.

Ще один момент — хотів спокійно взяти shadcn-лібу. Для SvelteKit є fork оригінальної ліби, але також не дуже хочеться брати у прод щось, що є fork-ом.

Таких моментів ще було декілька, де рішення наче є, але глянувши на фреймворки з більшим ком’юніті, аналогічні рішення просто стабільніші.

Тому на даному етапі, все ж таки муваюсь у сторону Next.js з Vercel.

Цей текст взято з особистого блогу після отримання дозволу автора.

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

Останні статті

Мої найважливіші кроки для вдосконалення коду в команді

Блогер та розробник Джозеф Круз розповів, як покращити роботу команди розробників, так показати їм справжню…

06.06.2025

Недооцінені фішки вашого смартфона, які спрощують життя

Щодня ми носимо в своїй кишені пристрій, що в сотні мільйонів разів потужніший за комп’ютер,…

05.06.2025

В чому різниця між фіксом та «костилем»?

Оце сиджу, працюю і задумався: «А де ж проходить та тонка межа між фіксом, який…

04.06.2025

Закон Гудгарта або як метрики змінюють цінності

«Коли вимірюваний показник стає метою, він перестає бути хорошою мірою» Закон який значною мірою відповідальний…

03.06.2025

Як приймати обдумані рішення за допомогою ChatGPT? Приклади промптів

Інколи здається, що ви врахували все. Упевненість у рішенні настільки висока, що ви вже подумки…

02.06.2025

Чи можете ви програмувати, не дивлячись на екран?

Блогер та розробник Джозеф Круз розповів, як він працює програмістом, маючи доволі серйозні проблеми із…

23.05.2025