Astro: почему клиентский сайт собран не на том же стеке, что этот

Этот сайт — голый HTML/CSS/JS без сборки. Сайт клиента (InSystem, электромонтаж, Москва) — на Astro. Разница не случайная, и стоит честно объяснить, откуда она взялась.

Что реально стоит в проекте

В astro.config.mjs у InSystem: output: 'hybrid', адаптер @astrojs/vercel/serverless, интеграция @astrojs/sitemap. То есть не статическая генерация в чистом виде — часть страниц рендерится на сервере, потому что сайту нужны серверные функции (обработка форм, генерация статей через отдельный скрипт), а не только отдача готовых файлов.

В проекте есть npm-скрипт write-article, который запускает scripts/generate-article.mjs с локальным .env — то есть публикация SEO-статей у клиента частично автоматизирована через отдельный генератор, а не пишется вручную в HTML, как здесь, в «Лаборатории».

Почему не тот же стек, что тут

Мой сайт — это по сути одна лендинг-страница с canvas-анимацией и несколько статей. Никакой серверной логики, никаких форм с обработкой на бэкенде — голый HTML проще держать в голове и быстрее менять руками, без шага сборки между правкой и деплоем.

У InSystem другая ситуация: сайт должен регулярно пополняться SEO-статьями (генерируются через скрипт, не пишутся руками по одной), плюс есть смысл в компонентной структуре (layouts, content collections), потому что структура статей повторяется. Astro с hybrid-рендерингом и Vercel-адаптером даёт именно это — без переусложнения фреймворками уровня Next.js, которые для такой задачи избыточны.

Честно о цене решения

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