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 призводить до того, що:

Спецпроєкти

Крихкі зони: як виявляти їх вчасно. Досвід FAVBET Tech

Що вмітиме український ChatGPT та якою буде ІТ-освіта. Підсумки Tech360 у Києві

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

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

Спецпроєкти

Хмарна vs локальна: як обрати ідеальну СRM і що вона повинна вміти

Ефективний моніторинг сучасного PHP-застосунку. Як тут працюють системи спостереження Observability?

В 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.

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