# 🔬 Выбор фреймворка для приложения

- **Тип:** research
- **Категория:** Очередь
- **Зачем:** Конвенция веб-UI написана под htmx, а решено делать SPA: до выбора фреймворка не заводится ни сборка, ни первый экран.
- **Теги:** goal:web-access

Конвенция [web-ui.md](../../docs/conventions/web-ui.md) описывала htmx с прямым
запретом на шаг сборки и реактивные фреймворки. Решение сменилось на SPA, и
теперь эта конвенция ждёт переписывания — но написать её не под что, пока
фреймворк не назван.

Разведка, а не задача: исход — знание и переписанная конвенция, а не работающий
экран.

## Вопрос

Какой фреймворк берём под приложение на четыре экрана, которое собирается в
статику, вшивается в бинарник Go и ставится на телефон как PWA.

## Куда ляжет ответ

`docs/research/spa-framework.md` — сравнение с числами: размер собранной статики,
время холодной сборки, число зависимостей. Выбор и причина отказа от остальных —
в `docs/adr/`, потому что переделка на другой фреймворк стоит дороже переписывания
одного файла. Следом переписывается `docs/conventions/web-ui.md`, и до тех пор
она стоит честной строкой «фреймворк не выбран».

## Рамки

Сравнение идёт на одном и том же пробном экране: список записей с опросом
состояния. Кандидаты названы человеком; сегодня в разговоре звучали Svelte, Vue
и React, все с Vite. Мера — размер статики, простота вшивания в `go:embed` и
цена шага сборки в гейте, а не популярность.