Фреймворк який підтримує SSR і SSG, але має суттєву перевагу над Next.js та Nuxt.js.
Перевага полягає у тому, що оскільки SvelteKit не юзає Virtual DOM, то для нього гідрація на клієнті не така страшна як для Next.js та Nuxt.js.
Нагадаю, шо там відбувається під час SSR-рендерингу.
- Ми рендеримо на сервері.
- Результат рендеру конвертуємо в HTML (на інішл лоаді).
- Віддаємо HTML + JS (який потрібен для гідрації).
- Браузер отримав HTML і шоб відтворити Virtual DOM, ще раз рендерить документ.
- Тільки після рендеру навішуються обробники подій, що робить сторінку інтерактивною.
Тобто, проблема на кроці 4 призводить до того, що:
- JS-файл, який сервер віддає клієнту, є великим;
- Вантажиться він довше;
- Юзає 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.
Цей текст взято з особистого блогу після отримання дозволу автора.
Favbet Tech – це ІТ-компанія зі 100% українською ДНК, що створює досконалі сервіси для iGaming і Betting з використанням передових технологій та надає доступ до них. Favbet Tech розробляє інноваційне програмне забезпечення через складну багатокомпонентну платформу, яка здатна витримувати величезні навантаження та створювати унікальний досвід для гравців.
Цей матеріал – не редакційний, це – особиста думка його автора. Редакція може не поділяти цю думку.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: