Экосистема Svelte

Команда выбирает Svelte для нового продукта и сразу спотыкается о привычку из React: ищет готовую огромную библиотеку компонентов на любой случай и не находит аналога такого же размера. Возникает соблазн объявить экосистему бедной и вернуться назад. Но при ближайшем рассмотрении базовые потребности закрыты: адаптеры под все платформы, несколько зрелых UI-библиотек, mdsvex для документации, Paraglide для локализации. Реальный вопрос не в том, есть ли пакет, а в том, как оценивать выбор, когда вариантов меньше.

• SvelteKit поставляет официальные адаптеры под Node, статику, Vercel, Netlify и Cloudflare - деплой на любую из платформ это смена одного пакета
• Skeleton, Bits UI, shadcn-svelte и Flowbite Svelte - зрелые библиотеки компонентов, многие из которых темизируются через CSS-переменные
• mdsvex позволяет писать Markdown с встроенными Svelte-компонентами - основа документационных сайтов и блогов на SvelteKit
• Paraglide (от Inlang) - типобезопасная i18n, которая компилирует переводы в дерево-шейкаемые функции, а не грузит словари в рантайме
• Экосистема Svelte меньше React по числу пакетов, но любой обычный браузерный npm-пакет (даты, графики, валидация) работает без обёртки под фреймворк

Предварительные знания

• Базовая структура проекта SvelteKit: маршруты, +page, +layout
• Понимание, что такое npm-пакет и зависимость проекта
• Идея о том, что приложение нужно куда-то деплоить и что разные платформы требуют разного формата сборки

Адаптеры: одна сборка под любую платформу

SvelteKit не привязан к одной среде выполнения. Приложение можно собрать как статический сайт, как Node-сервер, как функции на Vercel, Netlify или Cloudflare. За подгонку отвечает адаптер - пакет, который берёт результат сборки и упаковывает его в формат, который понимает конкретная платформа. Логика приложения при этом не меняется, меняется только адаптер в конфиге.

adapter-auto определяет платформу по окружению CI и подтягивает нужный адаптер сам - удобно для старта. Для предсказуемой продакшен-сборки команды обычно фиксируют конкретный адаптер явно, чтобы поведение не зависело от среды, где запускается сборка.

Библиотеки компонентов и обычные npm-пакеты

Готовые UI-библиотеки в Svelte есть, и зрелые. Bits UI даёт headless-компоненты (логика и доступность без навязанных стилей), shadcn-svelte - копируемые в проект компоненты поверх Bits UI, Skeleton и Flowbite Svelte - оформленные наборы. Их меньше по числу, чем в React, но для типичного приложения (формы, диалоги, меню, таблицы) выбор закрыт.

Ключевая мысль: дефицит специфичных Svelte-пакетов часто переоценивают. Огромная доля npm не привязана к фреймворку. Валидатор, библиотека дат, парсер, клиент API работают в Svelte ровно так же, как в любом JS-проекте. Фреймворк-специфичная обёртка нужна только тогда, когда пакет управляет DOM или собственным жизненным циклом (чарты, редакторы, drag-and-drop).

Перед поиском Svelte-специфичной библиотеки стоит проверить, не решается ли задача обычным браузерным пакетом. Часто фреймворк-обёртка не нужна вовсе, а прямое использование надёжнее: меньше слоёв, которые могут устареть или конфликтовать с версией Svelte.

mdsvex: Markdown со встроенными компонентами

Документация, блог и маркетинговые страницы удобнее писать в Markdown, чем размечать вручную. mdsvex - препроцессор, который делает .svx-файлы (или .md) полноценными компонентами Svelte: текст пишется как Markdown, но внутрь можно вставлять Svelte-компоненты, использовать переменные и фронтматтер. Содержательная часть отделена от вёрстки, а интерактив встраивается там, где он нужен.

Фронтматтер в начале файла (заголовок между тройными дефисами) становится доступен как переменные внутри. mdsvex подключается как препроцессор в конфиге SvelteKit, после чего .svx-файлы маршрутизируются и импортируются как любые компоненты. Это база типичного контентного сайта на SvelteKit: статьи в Markdown, общий layout в Svelte, точечный интерактив через компоненты.

Граница ответственности проста. mdsvex для контента, который по сути текст с редкими вкраплениями интерактива: статьи, гайды, changelog. Для приложения, где интерактив - основа, mdsvex не нужен, там пишут обычные компоненты. Смешивать имеет смысл на контентных страницах внутри приложения.

Paraglide: типобезопасная локализация и оценка экосистемы

Интернационализация в Svelte обычно делается через Paraglide от Inlang. Его подход отличается от классических i18n-библиотек: вместо загрузки словарей в рантайме Paraglide компилирует каждое сообщение в обычную функцию с проверкой типов. Неиспользуемые переводы вырезаются деревом-шейкингом, а опечатка в ключе превращается в ошибку компиляции, а не в пустую строку у пользователя.

Вызов m.welcome_title() возвращает строку на текущем языке. Поскольку это сгенерированная функция, редактор подсказывает доступные сообщения и их параметры, а сборщик включает в бандл только реально используемые переводы. Это контраст с подходом, где весь JSON-словарь грузится целиком и ключи проверяются только в рантайме.

Возвращаясь к главному вопросу урока: экосистема Svelte действительно меньше React по числу узкоспециализированных пакетов. Реалистичная стратегия не в отрицании этого, а в трёх приёмах. Первое: опираться на обычные браузерные npm-пакеты там, где привязка к фреймворку не нужна. Второе: для базовых нужд (UI, i18n, контент) брать зрелые решения, которые уже сложились. Третье: оценивать пакет не по популярности на фоне React, а по тому, поддерживается ли он и решает ли задачу.

Здравый критерий выбора пакета: дата последнего релиза, открытые issue, совместимость со Svelte 5 и руническим API. Маленькая, но живая и совместимая библиотека надёжнее большой, но заброшенной. Размер экосистемы вокруг другого фреймворка к этому решению отношения не имеет.

Связь с другими темами

Экосистема - мост между разработкой и поставкой. Связи:

• Деплой и окружения — Адаптеры - конкретный инструмент экосистемы для деплоя; выбор адаптера определяет формат сборки под платформу
• Стилизация — UI-библиотеки экосистемы настраиваются через CSS-переменные темы, разобранные в уроке о стилизации

Итог

• Адаптеры SvelteKit подгоняют одну сборку под платформу (Node, статика, Vercel, Netlify, Cloudflare) - смена цели это смена адаптера
• Библиотеки компонентов есть и зрелые (Skeleton, Bits UI, shadcn-svelte, Flowbite), просто их меньше по числу, чем в экосистеме React
• mdsvex добавляет Markdown со встроенными Svelte-компонентами - стандартный путь для блогов и документации на SvelteKit
• Paraglide компилирует переводы в дерево-шейкаемые функции с проверкой типов вместо загрузки словарей в рантайме
• Экосистема Svelte уже React по числу специфичных пакетов, но обычные браузерные npm-библиотеки работают без обёртки, и это закрывает большинство нужд

Связанные уроки

• sv-42-deployment-environments — Адаптеры из этого урока - точка входа в деплой: выбор адаптера определяет, как и куда собирается приложение
• sv-40-styling-scoped-css-variables — Библиотеки компонентов экосистемы темизируются через CSS-переменные, разобранные в уроке о стилизации