Як я свічнувся з .NET на Svelte, або чому цей фреймворк вартий уваги

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Привіт, спільното! Мене звати Владислав, я Full Stack Software Engineer. Пів року тому я приєднався до освітньої команди Genesis, де почав багато працювати зі Svelte та SvelteKit — здебільшого саме для розробки нових проєктів. У цій статті хочу поділитися власним досвідом використання Svelte, коротко поговорити про стан фреймворку у 2025 році, а також залишити кілька думок та спостережень.

До Genesis я займався бекенд-розробкою на .NET. Пробував фронтенд — трохи React, трохи Astro. Але саме Svelte став моїм першим повноцінним досвідом роботи з фронтенд-фреймворком і, фактично, стартом у фулстек-розробці.

Цей матеріал не є технічним порівнянням фреймворків чи спробою когось переконати. Лише ділюся історією з практики — про те, як Svelte працює в реальних умовах і чому він підійшов нашій команді.

Трохи статистики про Svelte у 2025 році

Вибір Svelte і його метафреймворку SvelteKit для створення продуктів може здатися не найтиповішим рішенням. Але чи справді він настільки «нішевий», як здається на перший погляд?

Згідно з даними State of JS 2024, Svelte використовують 26% опитаних розробників, а SvelteKit — 16,6%. Для порівняння: React — 81%, Next.js — 54%. І хоча Svelte суттєво поступається провідним фронтенд-фреймворкам — він лише четвертий у рейтингу після React, Vue та Angular, — у 2024 році його використовували удвічі більше розробників, аніж Preact, і втричі більше, аніж SolidJS.

Популярність — не єдиний показник, на який варто зважати. Якщо поглянути на рівень задоволеності серед тих, хто вже працює з фреймворком, картина кардинально відрізняється. У щорічних опитуваннях Stack Overflow з 2021 року Svelte стабільно входить до переліку найулюбленіших інструментів серед розробників.

У нашій команді ініціатором переходу на Svelte був Team Lead Марк Мотлюк, Software Engineer в Genesis. Ось як він пояснює своє рішення:

«Я обрав Svelte через його мінімальність. Фреймворк не нав’язує складні патерни, стейт-менеджмент чи абстракції. Щоб впевнено ним користуватися, потрібно опанувати лише кілька концепцій. Завдяки цьому команда може зосередитися на розробці нового функціоналу, а не витрачати час на рутинний код. Мінімальність також дає гнучкість — архітектуру проєкту можна вибудувати під власні потреби, без жорстких рамок самого фреймворку.

За два роки використання Svelte ми реалізували кілька масштабних технічних продуктів: CRM для керування подіями та їхніми учасниками; платформу для взаємодії між стартапами й фондами; платформу для українських студентів, яка допомагає їм презентувати себе продуктовим IT-компаніям, а також внутрішнє рішення для автоматизації звітності у Head Office».

Практичний кейс використання Svelte

Серед найпоширеніших побоювань і застережень щодо використання фреймворку, які я зустрічав у статтях і коментарях до них, — неготовність Svelte бути гарним production-рішенням.

Втім, наш досвід — протилежний. Наприкінці 2024 року в освітньому департаменті Genesis ми запустили INTRO — онлайн-платформу для студентів і випускників, яка допомагає краще зрозуміти специфіку роботи в продуктовому ІТ, сформувати навички для старту кар’єри та розповісти про себе компаніям з екосистеми.

Цей проєкт нам вдалося реалізувати досить швидко — і без втрати якості. Раніше я не працював зі Svelte, але завдяки його інтуїтивності зміг оперативно розібратися з основами, зрозуміти концепції фреймворку й бути продуктивним уже з перших тижнів.

На момент написання статті платформа складається з трьох основних частин:

• Анкета-резюме — конструктор резюме з drag-and-drop логікою. Досить складна частина з погляду обʼєму, валідації, умовних полів і edge-кейсів. Однак завдяки кастомності користувачі отримують більш персоналізовані результати.
• Навчальні матеріали — це мапи професійних траєкторій у продуктовому IT: від дизайну до QA. З технічного боку це було досить цікаве рішення, адже створення цих roadmap потрібно було автоматизувати на базі CMS. В CMS визначаються теми, залежності між ними та сам контент. Далі, на основі тем та їх залежностей генерується код для mermaid-діаграми. У результаті можемо автоматично створювати гарні SvelteFlow-діаграми на базі отриманих координат.
• Профілі продуктових IT-компаній — дають можливість детальніше ознайомитися з компаніями, їхніми продуктами та досягненнями.

Для розробки платформи ми використовували метафреймворк SvelteKit та Svelte 5. Щодо інструментів та бібліотек:

• стилізація — TailwindCSS;
• бібліотека компонентів — shadcn-svelte (порт shadcn/ui на Svelte);
• форми — sveltekit-superforms;
• для редагування блоків анкети у профілі — svelte-dnd-action.

Більшість додаткових бібліотек — звичайні JavaScript-рішення, які легко інтегруються без потреби у специфічних обгортках. Це ще один плюс Svelte як фреймворку: інтеграція з vanilla JS-екосистемою UI-компонентів абсолютно безболісна.

Що стосується взаємодії з Back-end, ось як описує підхід Марк:

«У SvelteKit нативні способи взаємодії з Back-end досить обмежені — це лише load-функції (виконуються на сервері перед рендером сторінки) та form actions (серверна обробка форм). Через це ми також використовуємо tRPC — він забезпечує зручну роботу з Back-end ендпоінтами, гарантуючи безпеку типів (end-to-end type safety).

Також на одному з внутрішніх проєктів ми впровадили Telefunc — бібліотеку, яка дозволяє викликати серверні функції прямо з клієнтського коду, ніби вони локальні.

Підхід колокації Back-end та Front-end, реалізований в інструментах на кшталт tRPC, Telefunc та самому SvelteKit, суттєво спрощує та прискорює процес розробки».

Що саме сподобалося у Svelte та SvelteKit

SvelteKit пропонує класний developer experience. Особисто мені подобаються підхід до розробки, інструменти та філософія, що він пропонує.

Структура проєкту

У SvelteKit реалізований file-based routing. Згідно з цією системою, кожна сторінка визначається всередині теки /routes в окремому файлі +page.svelte. +page префікс використовується і в назві файлів, що належати до цієї сторінки. Наприклад, +page.server.ts (визначає серверну логіку) та +page.ts (код, що може виконуватись і на сервері, і у браузері перед рендером сторінки).

У цих файлах можна створювати функції load, що дозволяють завантажувати дані на сторінку. Для визначення лейаутів використовується префікс «+layout»: +layout.svelte, +layout.server.ts, +layout.ts. Досить інтуїтивно та зрозуміло.

Ось, наприклад, view частинки файлової системи на проєкті INTRO:

src/
├── lib/
├── params/
├── routes/
│   ├── (auth)/
│   ├── api/
│   ├── companies/
│   ├── learning/
│   ├── profile/
│   │   ├── +page.server.ts
│   │   └── +page.svelte
│   ├── +error.svelte
│   ├── +layout.server.ts
│   ├── +layout.svelte
│   └── +page.svelte

Компоненти

Як і сторінки, компоненти у Svelte визначаються кожен в окремому файлі (Single-File Component), і експортуються за замовчуванням. Код у компонентах підтримує TypeScript і є «реактивним» out of the box. Ось невеличкий приклад компонента на Svelte 5, для загального розуміння структури:

<script lang="ts">  
  import { onMount } from 'svelte';  
  
  type Props = {  
    name: string;  
  };  
  
  let { name }: Props = $props(); // отримуємо аргументи компонента  
  
  let isOpen = $state(false); // так можна створити реактивну змінну  
  
  onMount(() => { // відпрацьовує при ініціалізації компонента  
    console.log('Component mounted');  
  });  
  
  // реактивна функція, викликається при зміні залежностей, тут - isOpen та name 
  $effect(() => {  
    if (isOpen) {  
      console.log(`${name} is open`);  
    }  
  });  
</script>  
  


<button onclick={() => isOpen = !isOpen}>
  {isOpen ? "Закрити" : "Відкрити"}
</button>

{#if isOpen}
<h2 class="name">  
  Hello, {name}!  
</h2>
{/if}

<!-- Так можна визначати scoped-стилі для компонента -->
<style>  
  .name {  
    font-size: 2rem;  
    color: #333;  
  }  
</style>

Також у Svelte є two-way data binding, який, якщо ним не зловживати, є досить зручним. Щоб позначити аргумент як «bindable» використовується руна $bindable():

<script lang="ts">  
  let { value = $bindable(), ...props } = $props();  
</script>  
  
<input bind:value={value} {...props} />

Відповідно тепер, при зміні значення value, воно зміниться й у parent-компоненті.

Перфоманс

SvelteKit має класний performance «з коробки» та імплементує чимало способів оптимізації сторінок. Окремо варто виділити:

• автоматичний preloading посилань під час ховеру;
• об’єднання різних серверних load-запитів в один HTTP-запит;
• можливість пререндеру (prerender) статичних сторінок (можна налаштувати для кожного роуту);
• паралельне завантаження не пов’язаних load-функцій.

Більше про перфоманс та те, яким чином SvelteKit оптимізує вебсайт, можна почитати на сторінці в документації (доки у Svelte, до речі, досить гарні та зрозумілі).

Головний виклик Svelte

Наразі Svelte справді має меншу спільноту та екосистему, ніж React або навіть Vue. Попри те, що фреймворк уже використовується у чималій кількості production-проєктів — зокрема таких, як Apple Music, Yahoo Finance та Stack Overflow, — він усе ще сприймається як менш перевірений або менш універсальний варіант, особливо під час вибору стеку для масштабних продуктів. У більшості випадків вибір, найімовірніше, схилиться до популярніших рішень — навіть попри те, що Svelte може виявитися зручнішим і швидшим у розробці.

Менша кількість production-кейсів також означає й меншу кількість спеціалістів на ринку, які вже мають досвід роботи зі Svelte. І це, на мою думку, — основний бар’єр, що стримує ширше впровадження фреймворку.

Попри це, для нашої команди цей вибір спрацював.

Ось як це пояснює Марк:

«Хоча ринок досвідчених Svelte-спеціалістів наразі обмежений, для нас це не стало перешкодою під час масштабування команди. Ми шукаємо не просто Svelte-розробників, а насамперед талановитих інженерів-універсалів. Пріоритет — здатність розв’язувати складні задачі та створювати якісний продукт, а не володіння конкретним стеком.

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

Висновки

Чи варто обирати Svelte як фронтенд-фреймворк — це питання, відповідь на яке залежить від конкретного проєкту, команди та контексту. Так, Svelte справді поступається React чи Vue за популярністю й розміром екосистеми. Також знайти спеціаліста з досвідом саме у Svelte може бути складніше.

Але не варто відкидати Svelte лише через скептичне ставлення до нього як до не «production ready» інструмента — наш досвід свідчить про інше.

Особисто для мене Svelte виявився легким та інтуїтивним у вивченні. Його логіка зрозуміла, він пропонує чимало інструментів та налаштувань «з коробки». Через свою мінімалістичність та підхід до розробки, він дозволяє досить оперативно будувати навіть складні вебзастосунки.

Тож якщо ви — команда інженерів-універсалів і шукаєте ефективний, легкий у старті та гнучкий у використанні інструмент для фронтенду — спробуйте Svelte. Цілком можливо, він вас приємно здивує.