Код, интерфейсы и трафик без воды
lawebbox

Specify: как декларативный YAML и компилятор заменяют визуальный редактор в веб-разработке

По описанию на Хабре, Specify переводит YAML-спецификацию интерфейса в код веб-приложения на Svelte.

Максим Воронцов, Хардкорный бэкендер и девопс · обновлено 15 октября 2026 г.

Specify: как декларативный YAML и компилятор заменяют визуальный редактор в веб-разработке

Это попытка убрать ручной перенос макета в верстку, не строя для этого отдельный визуальный редактор. Для команд, где дизайн и фронтенд регулярно расходятся, здесь важен не очередной генератор, а вопрос: можно ли сделать спецификацию рабочим источником правды, а не ещё одним файлом, который забыли обновить.

Вместо редактора — спецификация и компилятор

Автор Specify описывает проект как декларативную спецификацию и транслятор в код приложения. Визуального редактора внутри нет: интерфейс задаётся файлами YAML, а разработчик работает с ними через IDE. По замыслу, это сокращает петлю между изменением дизайна и обновлением кода. Магии нет. Есть новый формат, который команде придётся поддерживать.

Структура напоминает разложенный по файлам дизайн-системный слой: tokens.yaml хранит токены, отдельные YAML-файлы в components/ и screens/ описывают компоненты и экраны. В спецификации есть слои вроде frame, text и image, а стили включают fill, stroke, shadow и blur. Терминология, как сообщает автор, близка к Figma.

Состояния описываются стилями, включая вложенные hover, focus, pressed и disabled. Для экранов предусмотрены path и params, для навигации — navigate-to. Есть stores для глобальных реактивных переменных и run для пользовательского кода. На последнем пункте заканчивается удобная иллюзия, что YAML сам реализует приложение: часть компонентов всё равно требует логики. В примере со слайдером функцию createSlider нужно написать отдельно.

Что проверить до внедрения

Specify генерирует PWA, обозначенную в описании также как SPA, на Svelte. Автор заявляет автономную работу приложения, в том числе при отсутствии сервера. Это характеристика проекта из публикации, а не гарантия для любого приложения: реальное поведение зависит от того, какие данные и функции вынесены на бэкенд. В описании также упомянута интеграция с Appwrite.

Перед тем как тащить такой подход в командный процесс, стоит проверить три вещи:

  • как изменения спецификации попадают в генерируемый код и можно ли увидеть diff в обычном Git-review;
  • где заканчивается декларативная часть и начинается пользовательская логика;
  • кто и как синхронизирует YAML с исходным дизайном.

Последний пункт критичен. Specify связывает дизайн и фронтенд через собственное описание интерфейса, но из материала не следует, что он автоматически синхронизируется с Figma. Если спецификацию придётся обновлять вручную, сломанный телефон может просто переехать из чата в репозиторий.

Генерация не отменяет ревью

Спецификацию, по словам автора, можно попробовать генерировать с помощью AI; в проекте для этого есть Skill. Это ускоряет старт, но не снимает проверку результата. Нужно смотреть, какой код получился, как устроены состояния и навигация, где выполняется пользовательская логика. Иначе YAML станет ещё одним слоем абстракции, который никто не хочет дебажить.

Практический тест простой: взять один экран с компонентами и состояниями, описать его в Specify, сгенерировать Svelte-код и сравнить результат с тем, что команда готова поддерживать в проде. Если после генерации начинаются ручные правки кода, проверьте, не разъезжаются ли они с исходной спецификацией. Это не Framer без визуального редактора. Это другой контракт между дизайном и фронтендом, и его тоже придётся ревьюить.