<b>Astro удобно брать не за «модность», а за режим сборки и доставки страниц</b>

<b>Astro удобно брать не за «модность», а за режим сборки и доставки страниц</b>

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

Что обычно выигрывает:
— меньше клиентского кода;
— проще контролировать метрики загрузки;
— удобно смешивать компоненты из Vue, Svelte, Solid и других источников;
— можно держать интерактивные острова отдельно от статической базы.

Но есть и типовая ошибка: пытаться строить на Astro приложение, где почти всё живёт в состоянии, частых переходах и сложной клиентской логике. Тогда архитектура начинает спорить сама с собой. Astro хорош там, где страница — это в первую очередь документ, а не экран приложения.

Перед стартом полезно проверить:
— сколько страниц реально должны быть интерактивными;
— где можно оставить серверный рендер;
— не тащите ли вы JS «на всякий случай»;
— понятно ли, кто владеет контентом: CMS, файлы, API или всё вместе.

Если проект контентный, начните с Astro и добавляйте интерактивность точечно. Если приложение живёт в браузере, лучше честно выбрать другой стек.