Да, у Eleventy сейчас есть флаг --incremental, но он не делает полноценную инкрементальную сборку страниц в CI/продакшене. Он ускоряет работу в режиме serve при разработке, пересобирая локально только изменённые файлы. Это действительно не то, о чем говорится в статье. Да, есть плагины которые улучают инкрементальное поведение в процессе разработки, но это всё тоже для прода не подходит. Действительно в этом моменте информация, которая может запутать. Спасибо, уберу это из статьи.
если тебе LAMP-стек с вордпрессом тяжело, то куда тебе в микросервисы?
Микросервисы — это возможность, а не обязательство. Речь не о замене WordPress собственной распределённой системой. Идея в том, что при SSG динамика может выноситься в готовые сервисы или API и использоваться по необходимости, а не жить внутри одной CMS и обслуживать каждый запрос. Это не про упрощение любой ценой. Мысль в ином распределении ответственности.
А некст не надо обновлять? У них каждые полгода критическая уязвимость.
Да, как и любые другие инструменты. Но WordPress работает в продакшене (PHP + БД), а Next.js при статической сборке — только на этапе билда. Уязвимость в рантайме и уязвимость в build-time — это разный класс риска.
А бэкенд с микросервисами уже куда делся? Понятно, что можно тот же некст поставить на локальную машину, билдить оттуда и пушить. Но что это значит для бизнеса? Плюс один комп со строго настроенным окружением.
Он никуда не делся. Но при SSG он не обязан постоянно работать вместе с сайтом. Если динамика нужна — её можно подключить отдельно, а не держать вместе с сайтом полноценный LAMP 24/7. Если не нужна — сайт остаётся статическим набором файлов, который можно разместить на любом хостинге или CDN
Специалист, который умеет обращаться с консолью, умеет чинить сборку, когда она падает. А если он уволится? Или платить за каждый билд вебстудии? Так и вебстудии не вечные. А тот же вордпресс залил и пользуйся себе админкой. Захотел поменять того, кто обслуживает сайт - пожалуйста, всё лежит в одном месте.
Современная сборка — это чаще CI, а не комп разработчика. Репозиторий и пайплайн остаются.
WordPress тоже не магия: плагины, бэкапы, обновления, взломы — всё это требует компетенции. Это проблема другого типа.
А вообще, что такое SSG? Сначала появились реактивные фреймворки, потом людям захотелось SEO, поэтому придумали SSR. Но на деле это получился дико тормознутый монстр, который годами пытались ускорить, и в итоге сдались, добавив SSG.
SSR и SSG — это разные инструменты для разных задач. И SSG существовал задолго до React (Jekyll, Hugo). Если страница одинакова для всех, её логично собрать заранее.
Но решили умолчать, что статика - это всего лишь фронтенд. А за этим ещё кроется огромный айсберг в виде инфраструктуры для сборки и хранения данных.
Да, инфраструктура есть. Вопрос в том, где она живёт: — в вашем сервере с PHP и БД, — или сборка + CDN/хостинг + внешних API.
Статья не говорит, что SSG лучше всегда. Сложность никуда не исчезает. Она меняет характер: вместо постоянно работающего бэкенда — этап сборки и внешние сервисы по потребности.
И ключевая мысль статьи именно в этом: если сайт — это в первую очередь контент, а не приложение с персонализацией и сложной логикой, то держать полноценную CMS бывает избыточно.
Я не утверждаю, что WordPress плох, SSG — серебряная пуля, всем срочно в Next.js. Мы слишком часто используем CMS как универсальный молоток.
Это не «враньё», а разный взгляд на допустимую сложность под конкретную задачу.
В целом у меня нет цели научить вас делать сайты или рассказать вам про «правильный» или «неправильный», я лишь делаю субъективный обзор на то, «Почему статические сайты возвращаются и чему они научились» 🙂
Спасибо за комментарий — действительно полезные замечания!
Спасибо! Поправил.
Да, у Eleventy сейчас есть флаг --incremental, но он не делает полноценную инкрементальную сборку страниц в CI/продакшене. Он ускоряет работу в режиме serve при разработке, пересобирая локально только изменённые файлы. Это действительно не то, о чем говорится в статье. Да, есть плагины которые улучают инкрементальное поведение в процессе разработки, но это всё тоже для прода не подходит. Действительно в этом моменте информация, которая может запутать. Спасибо, уберу это из статьи.
Микросервисы — это возможность, а не обязательство. Речь не о замене WordPress собственной распределённой системой. Идея в том, что при SSG динамика может выноситься в готовые сервисы или API и использоваться по необходимости, а не жить внутри одной CMS и обслуживать каждый запрос. Это не про упрощение любой ценой. Мысль в ином распределении ответственности.
Да, как и любые другие инструменты. Но WordPress работает в продакшене (PHP + БД), а Next.js при статической сборке — только на этапе билда. Уязвимость в рантайме и уязвимость в build-time — это разный класс риска.
Он никуда не делся. Но при SSG он не обязан постоянно работать вместе с сайтом. Если динамика нужна — её можно подключить отдельно, а не держать вместе с сайтом полноценный LAMP 24/7. Если не нужна — сайт остаётся статическим набором файлов, который можно разместить на любом хостинге или CDN
Современная сборка — это чаще CI, а не комп разработчика. Репозиторий и пайплайн остаются.
WordPress тоже не магия: плагины, бэкапы, обновления, взломы — всё это требует компетенции. Это проблема другого типа.
SSR и SSG — это разные инструменты для разных задач. И SSG существовал задолго до React (Jekyll, Hugo). Если страница одинакова для всех, её логично собрать заранее.
Да, инфраструктура есть. Вопрос в том, где она живёт:
— в вашем сервере с PHP и БД,
— или сборка + CDN/хостинг + внешних API.
Статья не говорит, что SSG лучше всегда. Сложность никуда не исчезает. Она меняет характер: вместо постоянно работающего бэкенда — этап сборки и внешние сервисы по потребности.
И ключевая мысль статьи именно в этом: если сайт — это в первую очередь контент, а не приложение с персонализацией и сложной логикой, то держать полноценную CMS бывает избыточно.
Я не утверждаю, что WordPress плох, SSG — серебряная пуля, всем срочно в Next.js. Мы слишком часто используем CMS как универсальный молоток.
Это не «враньё», а разный взгляд на допустимую сложность под конкретную задачу.
В целом у меня нет цели научить вас делать сайты или рассказать вам про «правильный» или «неправильный», я лишь делаю субъективный обзор на то, «Почему статические сайты возвращаются и чему они научились» 🙂
Спасибо за комментарий — действительно полезные замечания!
Спасибо за дополнение! Действительно, для личных кабинетов и случаев со сложной бизнес-логикой это не совсем уместно. Поправил статью.
Спасибо за внимательность, поправил оформление, теперь код читается лучше)