Пересядь с иглы WordPress на Static Site Generator и Headless CMS #нивкакиестэки

    Что делать, если WordPress (WP) уже не вставляет, а сайт пилить надо? Кейс авторского блога на Static Site Generator (SSG) и Headless CMS (HCMS).

    Разбираем достоинства связки SSG + HCMS для программистов, диджитал номадов и современных контент-мейкеров.

    I. Я устал, я ухожу


    image

    Меня зовут Давид. Вот уже шесть лет я каждый день пользуюсь WordPress. Я устал от такой жизни. Дал себе обещание найти новые решения для создания авторского контента.

    Так я наткнулся на Static Site Generator (SSG) и Headless CMS (HCMS), потыкался и влюбился.

    О причинах моей влюбленности сегодня и хочу рассказать.

    Почему сравниваю с WordPress? Потому, что это платформа для контентных сайтов по умолчанию. Альтернатив с хорошей экосистемой плагинов практически нет. А те, что есть, абсолютно однотипные и имеют одинаковые проблемы/особенности: PHP, рендеринг на сервере, шаблоны, БД и т.д.

    А почему не облачные сервисы типа Medium? Главная причина — ограниченная кастомизация (невозможность добавлять код со своими функциями и плагинами).

    II. Что такое SSG?


    Static Site Generator — это (чаще всего) консольная утилита, которая при запуске специальной команды берет шаблоны вашего интерфейса, данные из источника данных и создает из них HTML, CSS и JS файлы с контентом.

    image

    Для шаблонов интерфейса вы можете использовать широкий инструментарий: от React.js, Vue.js до шаблонизаторов типа Pug, EJS, etc.

    Как источник данных для SSG вы можете использовать: любую Headless CMS (о которых чуть ниже), HTML или Markdown файлы, любой API, да даже WordPress!

    image

    Вот пример Markdown файла, вот пример шаблона на React.js, а вот пример страницы сайта, которая была из него сгенерирована.

    Представим ситуацию: у вас в блоге 99 постов.

    В случае с WordPress для написания 100-го поста вы создаете его контент в админке и сохраняете его в Базе Данных (БД).

    Когда к вам на сайт заходит посетитель, WordPress на каждый запрос берет шаблон, берет данные из БД, объединяет их и отдает клиенту.

    image

    В случае с SSG, вы пишете контент 100-той статьи в одном из удобных для вас форматов (от Markdown, до Headless CMS или того же WordPress), вручную или автоматически запускаете генерацию данной статьи, которая в итоге превращается в готовые HTML, CSS и JS файлы с контентом.

    image

    Таким образом у вас получается 100 HTML файлов, по одному на статью.

    Когда к вам на сайт заходит посетитель, сервер сразу же отдает ему уже заранее подготовленные файлы со статьей.

    Никакого серверного кода, походов в БД и подобного топтания.

    Вот здесь на staticgen.com можно посмотреть список разных SSG и их возможности.

    Сегодня в качестве примера SSG я буду упоминать Gatsby.js, потому что мне было быстрее и удобнее всего работать с React.js.

    III. Что такое Headless CMS?


    Headless это не всадник без головы. В данном случае headless значит не имеющий интерфейса.

    Но на деле, как минимум административная панель всегда идёт вместе с HCMS, а клиентскую можно сделать или купить, как Тему.

    Поэтому на практике headless означает, что весь функционал системы доступен в формате API. Чаще всего, HTTP REST или GraphQL.

    image

    Это также можно назвать API-first подходом.

    В остальном это самая обычная CMS: создавайте свои типы данных, посты, категории, тэги, блоги, интегрируйте плагины и так далее.

    Дисклеймер. SSG и HCMS по факту являются составляющими понятия JAM-stack, но для упрощения, я решил опустить этот термин.

    image

    IV. А теперь поженим SSG + HCMS и сравним этого минотавтра с WordPress-подобными CMS


    Чтобы рассмотреть достоинства SSG на фоне WordPress, поиграем в ролевую игру (гусары, молчать):

    Вы — современная команда разработки, которая пилит SaaS криптовалютный распределенный мессенджер. И пора начать вести свое комьюнити единомышленников, где вы будете устраивать холливары, мериться кармой/IPO и всячески деградировать. Поздравляю, вы созрели для своего корпоративного блога.

    Ваши девелоперы, оторвавшись от создания нового frontend фреймворка, предлагают воспользоваться SSG + HCMS, поскольку… да хрен его знает, они сами плохо понимают, но говорят, что это годная технология.

    Вы уже почти согласились, КАК ВДРУГ в дверь влетает бородатый, вонючий, пропитанный алкоголем седовласый мужчина. Все сразу понимают — это PHP разработчик по-умолчанию.

    image

    А что происходит, когда в комнату врывается PHP разработчик? Правильно, он начинает предлагать WordPress или 1С-Битрикс. Пропатченные версии кодеров кричат еще что-то невнятное про Ларавел, но там не разберешь.

    Делать нЕчего, придется вступить с ним в словесную перепалку и решить, кто победит: мудрость пердящих дедов или пыл новомодных нубов.

    P.S. Я одинаково ненавижу / люблю всех разработчиков, поэтому не воспринимайте близко к сердцу.

    P.P.S. Однако на месте рубистов я бы вышел из чата.

    V. Дизайн


    В первую очередь, вам, как уважающему себя стартапу, важно иметь крутой и полностью настраиваемый дизайн.

    В случае с WordPress у вас есть варианты:

    1) Скачать Тему и начать вставлять в каждый css !important-ы и править полуживой js код.

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

    2) Начать пилить Тему самому. Но для этого придется использовать PHP, CSS, HTML и рендеринг шаблонов на сервере.

    image

    Ваши разработчики — полноприводные Full-stack-JS-гуру, а значит в разработке они не более 2-х лет (кто выдержит это дольше?) и в жизни не видели голый HTML и CSS.

    Фрилансеров, которые будут разрабатывать тему, брать не хочется, потому что все знают: WordPress фрилансеры — самый подлое племя. В аду Данте для них кипит котел с примордиальным супом в бескислородной среде при температуре 660 градусов Цельсия. Чего это я? Да они хуже гоблинов. Не было ни одного случая, когда они не обманывали своего наниматели и не сбегали с награбленным золотом.

    И тут на вашу тусовку влетает SSG!

    SSG (Gatsby.js, VuePress, 11ty, etc.) позволяет писать клиентскую часть на современной Frontend экосистеме, например, React или Vue.js. В крайнем случае шаблонизаторы типа Pug, EJS.

    А значит можно забыть о голом HTML и писать на удобных современному разработчику инструментах.

    Кроме этого, можно купить Тему для SSG и она тоже будет использовать библиотеки последнего писка моды frontend-а.

    image

    Итоги по дизайну:

    WordPress: +2 балла — за разнообразие Тем, среди которых иногда можно найти достойные, а еще балл за плагины кастомизации (site-builder).

    SSG + HCMS: +4 балла — за темы и при этом современный стэк для создания своего дизайна. Поэтому в вопросах именно уникального дизайна SSG точно выигрывает.

    P.S. Да, WordPress можно затюнить и подключить webpack с шаблонизаторами, но это процесс болезненный и хрупкий в случае использования сторонних Тем. А SSG идет с современным стэком прямо из коробки.

    VI. Кастомизация


    Ок, кроме офигенного дизайна, мы хотим расширить наш функционал сервисами подписки, комментариями и даже магазином с продажей ИМБА ЭНЕРД… кхм… простите… продажей своего мерча.

    А еще к вам приходит задача добавить в блог чарты с графиком стоимости вашей компании на IPO, данные для которого лежат в вашей Cassandra и раздается все это богатство Serverless лямбдами с AWS.

    В случае с WordPress первые три задачи решаются подключением соответствующих плагинов (стандартные комментарии, WpForms и WooCommerce).

    Но я не могу не добавить ложечку Содома (потому что за последний год WP потрепал мне нервов):

    1. Чтобы дойти до WPForms пришлось перепробовать еще 2-3 плагина. Все имели или проблему с дизайном, или проблему с настройками.
    2. Если отваливается SMTP сервис, то вы никак и нигде не увидите об этом предупреждения. Вам придется самому время от времени лезть в логи и проверять в чем дело.
    3. Подключение сторонних сервисов вроде MailChimp обычно доступно только в платной версии плагинов форм.
    4. Чтобы сделать нотификацию с Telegram, приходится качать очень мутный плагин и надеяться, что он будет работать, поскольку алертов про отвалившийся VPN вам не видать (на 18.06.20 слава богу VPN не актуален).


    Задачи решаемые, но долгосрочно, даже при самых простых требованиях, вы потратите много времени на установку, настройку, пробу и удаление.

    Еще нужно не забывать про жертвоприношения богам святого Рандома, чтобы какой-нибудь из плагинов (например email и Telegram, как было у меня) не вступил в перепалку и не порушил всю систему при следующем обновлении.

    WooCommerce вообще считаю очень годным решением, поэтому шуршать кульком в его сторону не буду. Да, есть свои проблемы, но проблемы есть с любым eCommerce.

    Итак, все вопросики решаются… до момента с чартами.

    Чтобы решить его, придется что-то напиливать на PHP, HTML, CSS и какой-то библиотеке графиков, которая требует при этом еще JQuery…

    Это будет долго, тяжело и больно.

    image

    Ок, а как тут справится SSG + HCMS?

    Во-первых, SSG и HCMS устроены так, что их легко и удобно интегрировать с любой системой, которая имеет API.

    Во-вторых, существует куча готовых плагинов.

    image

    Нужны комментарии? Берете любой из существующих сервисов (Disqus, Isso, Commento), интегрируете его. Можно даже подключить готовый плагин комментариев, которые сохраняются в Git репозиторий.

    Нужна обратная связь/подписка? Берете любой MailChimp, SendGrid, TypeForm, пилите пару React форм, подключаете готовый API, та дааааам.

    Интернет магазин? SSG спокойно можно подключить к Stripe, Paypal, Shopify или более бушкрафтовые решения типа ReactionCommerce / Saleor.io.

    А еще всегда можно воспользоваться Redux или Firebase для написания более сложной логики корзины на фронте.

    Чарты? У нас с вами в руках React/Vue.js, мы просто берем под него библиотеку чартов, делаем обычный HTTP запрос и отображаем данные… easy.

    + Все эти плагины можно сделать статически сгенерированными, что будет огромным плюсом для SEO.

    Итоги кастомизации:

    WordPress: +3 балла — 1 балл за кучу готовых плагинов, которые позволяют собрать все в одном месте, если для вас это важно. 2 балла за WooCommerce, годную площадку для российского интернет-магазина.

    SSG + HCMS: +3 балла — балл за удобное подключение любого сервиса через SDK + балл за отсутствии попытки собрать все в одном месте, что уменьшает количество багов и несовместимостей + балл за большое количество плагинов под SSG.

    Тут я решил соблюсти равновесие, потому что подходы АБСОЛЮТНО разные и каждый решает задачу по-своему.

    VII. Размер имеет значение


    А здесь начинается несколько пунктов, где связка SSG + HCMS безоговорочно доминирует над WordPress-like решениями.

    С помощью SSG + HCMS мы можем полностью управлять дизайном на современном стеке; можем легко интегрировать дополнительные плагины без потребности вшивать их куда-то глубоко внутрь системы. На выходе получаем оооочень оптимизированный и легкий бандл HTML, CSS, JS и других ассетов.

    image

    Более того, у многих SSG есть встроенные плагины по автоматической оптимизации картинок, svg и другой статики (lazy-loading, обрезка, сжатие, etc.).

    В вебе размер имеет значение, я так думаю.

    Меряемся размерами:

    WordPress: -1 балл — просто никуда не годится —минификация и компиляция исходников на WP — это боль. И чем больше вы добавляете плагинов, тем больнее. Довести WP до нормы размера бандла очень сложная задача.

    SSG + HCMS: +2 балла — здесь все и сразу из коробки, вообще не надо ни о чем думать. Значит, размер будет самым минимальным из возможных.

    Важно: SSG на React.js или Vue.js дает больше гибкости с точки зрения написания кастомного функционала, но с ними бандл получается достаточно большой. Поэтому, если для вас критична именно скорость, лучше воспользоваться SSG на шаблонизаторах, например 11ty.

    VIII. Скорость


    А теперь просто киллер-фича: SSG позволяет выгрузить весь контент в заранее собранные HTML файлы минимального размера, что уже дает максимальную скорость показу сайта клиенту, так?

    Но ведь вы при этом можете выложить эти HTML на любой облачный распределенный CDN.

    А это означает, что ваш сайт будет загружаться практически моментально у любого человека, в любой точке мира, в любой момент времени.

    Такой скорости клиентским витринам WordPress и другим CMS вообще никогда и не как не добиться.

    Минимальный размер размер бандла и хорошая скорость: наш сайт будет невероятно технически SEO-оптимизирован.

    Итоги скорости:

    WordPress: -2 — поскольку эта паскуда очень медленно работает.

    image

    SSG: +10 — быстрее быть не может.

    Важно: Конечно, у нас есть wp-cache. Но кроме его настройки и проблем с инвалидацией, вы по-прежнему располагаете сайт на одном конкретном сервере, что вообще несравнимо с распределенным CDN.

    IX. Безопасность


    Есть у меня дядя из Армении (а любой знакомый мужчина старше тебя в Армении считается твоим дядей, если твои волосы тоже черны и лихо завиваются густыми прядями в труднодоступных местах), учредитель фирмы кибер безопасности. Однажды он рассказал, как продает услуги кибербезопасности:

    “Я захожу к владельцу престижного онлайн-издания в Армении. И задаю ему всего одни вопрос: «что будет, если ваш сайт взломают хакеры из {вставьте любую другую кавказскую страну, они там все питают такую личную неприязнь друг к другу…} и в одном из постов годом ранее поменяют текст на призыв напасть на своих соседей?”

    После такого питча, директор любого СМИ быстро достает мешок денег и заказывает его услуги.

    image

    В случае с нашим блогом ставки не такие большие, но мы точно не хотим, чтобы каким-либо образом нас взломали и выкрали данные из CMS.

    В случае WordPress о безопасности говорить практически бессмысленно. Давным давно известна куча методов взлома, и каждая новая версия версия рано или поздно ломается под натиском мамкиных хакеров.

    Но еще большая дыра в безопасности это эксплойты плагинов, которые авторы очень редко лечат.

    И так будет всегда.

    image

    Интересный факт: наиболее подвержены взлому системы, на которых административная панель/источник данных доступны из клиентской панели.

    Поскольку страницы WordPress формируются на лету и приходят к нам с сервера, злоумышленник всегда знает адрес, куда можно долбиться, пока не найдет способ проникнуть в систему.

    SSG же компилирует все заранее и готовым HTML страницам нет никакой нужды ходить на сервер.

    Выкладываем их в одном месте, нашу HCMS в другом, и все.

    Злоумышленник не имеет никакого способа узнать, где лежат наши данные/админка, а, значит, не знает откуда начинать ломать систему.

    Готовые плагины, чаще всего, связаны с API их поставщиков (MailChimp, TypeForm, Stripe). Это серьезные дядьки, взломать которых является задачей не для мамкиных хакеров, а для скандинавских пиратов, которым такие взломы уже не интересны.

    Итоги безопасности:

    WordPress: -10 — взлом сайта на WP это только вопрос времени. Садбатру.

    SSG + HCMS: +10 — злоумышленник не может узнать, где лежит ваша админка. Плагины сделаны на API серьезных фирм, которые гарантируют дополнительную безопасность.

    P.S. Безусловно, никто не защитит от социальной инженерии. Но это вопрос ваших личных практик соблюдения безопасности в сети.

    X. Контент не только для сайта


    Так, теперь вы решили, что новости из сайта должны дублироваться в вашем мобильном приложении. Смотрим:

    HCMS — это API-first системы. Значит, ВЕСЬ их функционал полностью заточен, чтобы быть доступным через API (хоть HTTP, хоть GraphQL). Ergo, плагины, которые под них делают, тоже будут заточены под API.

    Вы можете получить доступ к этому функционалу как на сайте, так и на мобильном, да хоть в терминале или умном утюге.

    image

    У WordPress есть плагины, которые позволяют раздавать API через HTTP и GraphQL.

    Но, вы понимаете насколько большая разница качества и удобства подобного функционала? Когда это не “дополнительная функция с плагином”, а основной механизм технологии?

    Итоги по доступности контента:

    WordPress: 0 баллов — REST API рабочий, это факт. Но иногда приходится нехило извернуться при работе с ним, поэтому я не накинул балл. Я суров и полон предубеждений.

    SSG + HCMS: +1 балл — удобный и полнофункциональный API.

    Вместо десерта


    XI. Условная бесплатность


    Поскольку ваш итоговый сайт представляет собой набор HTML, вы можете использовать GitHub, GitLab, Vercel, Netlify как бесплатный хостинг для своего сайта.

    И даже когда вам понадобиться что-то мощнее, подобного рода хостинги стоят копейки.

    Итоги хостинга:

    WordPress: 0 баллов — хостинг будет дешевый, но он всегда будет стоить денег.

    SSG + HCMS: +2 балла — за возможность хостить сайты абсолютно бесплатно и за минимальную стоимость хостинга при максимальной скорости.

    XII. Это еще не все


    Самое главное во всех CMS — это текстовый редактор, который мы используем для создания контента.

    WordPress Gutenberg — на мой взгляд замечательный редактор (post-ironic mode off). Он удобнее, чем у Medium и чуть хуже редактора Notion. Здесь кастомизация и общее количество возможностей на высоком уровне, поэтому я снимаю шляпу и пальто.

    Но SSG + HCMS не отстают:

    Во-первых, если использовать HCMS, то вы получите очень мощные и красивые редакторы, схожие с Gutenberg.

    Во-вторых, если вы можете писать контент в виде файлов (например, Markdown), а значит можете использовать хоть Linux терминал.

    В-третьих, можно подключить любой удобный визуальный редактор для ваших файлов, например, Editor.js.

    А в-четвертых, есть такие гибридные, крутые и специфичные инструменты, как TinaCMS, которая превращает статические страницы в Site builder.

    И подобных решений для SSG море. Это позволяет выбрать любой из интересующих вас подходов.

    Итоги по редактору:

    WordPress: +1 балл — правда хороший редактор.

    SSG + HCMS: +2 балла — 1 балл за редакторы, 1 балл за гибкость и возможности настройки.

    XIII. Известность


    SSG и HCMS — это уже зрелые, известные и широкоиспользуемые в узкой среде решения.

    Они существуют давно и никуда не денутся.

    WordPress: +10 баллов — тут без вопросов, WordPress известен гораздо сильнее и обыгрывает SSG + HCMS.

    SSG + HCMS: +3 балла — вундервафля для smooth operators, эту связку уже спокойно можно использовать в production + развитая экосистема + есть разработчики.

    XIV. WordPress + SSG


    Я это уже говорил выше, но повторюсь: вы можете использовать WordPress вместе с SSG!

    То есть, вы пишите контент на WordPress и выгружаете его через отдельный SSG.

    Есть даже возможность выгрузить статические HTML, без дополнительного SSG, используя специальный плагин! Например, этот (там еще прекрасное англоязычное видео о том же, о чем я сейчас говорю здесь).

    Но, в этом случае, нужно учитывать, что другие плагины могут с ним не работать (например WooCommerce) и по-прежнему вы не властны над своим бандлом.

    XV. Большие итоги


    Подсчитаем баллы? Нет. Все мы знаем, что бенчмарки очень субъективны, поэтому измерять разницу между технологиями «бально» тоже считаю некорректным. Они здесь в качестве промежуточных итогов.

    Лучше так: SSG + HCMS — убийца WordPress?

    Конечно, нет.

    image

    Если у вас среднего размера СМИ или у вас уже есть PHP разработчики, то вам подойдет WordPress.

    Вы хотите сделать небольшой, но функциональный интернет-магазин вместе с удобным блогом за минимальную плату? — вам нужен WordPress.

    Вам нужно прям сегодня взять конкретную Тему, немного поправить ее руками и запустить блог с кучей плагинов? — ваш удел снова WordPress.

    С фронтом вы никогда не работал или вы не разработчик, а вам нужно сделать сайт за полчаса, то WordPress будет верным выбором.

    image

    Широта возможностей WordPress впечатляет. Но даже такой универсальный инструмент подойдет не всем.

    Это как демократия — нравится всем, но у некоторых декадентов она вызывает только жалость об упущенных возможностях.

    Мне кажется, что сегодня WordPress будет оптимальным решением для большинства задач.

    Время от времени я и сам выбираю WordPress, когда ситуация требует этого.

    Но сейчас я делаю блог для себя, строю личный бренд, mea culpa. Поэтому мне важны:

    1. Полная кастомизация дизайна.
    2. Скорость отдачи контента.
    3. Свободное добавление кастомного функционала.
    4. Безопасность.
    5. Простота обсуживания и деплоя.
    6. Меня достало копаться в css и ставить везде !important.
    7. Меня достало возиться с полурабочими плагинами.
    8. Я не хочу бэкапить БД зная, что любой апдейт, плагин, да что угодно, могут развалить весь мой сайт.
    9. Я хочу использовать современные технологии и современную экосистему для удобной разработки.
    10. При этом я Full-stack, поэтому для меня нет никакой проблемы в самостоятельной кастомизации системы.


    И все это из коробки или с возможностью написать с нуля, а не бороться с CSS, JS, PHP и плагинами.

    Дисклеймер в конце, как вы любите


    Поэтому я выбираю SSG в его Gatsby.js инкарнации + Headless CMS на Ghost.io.

    Ведь пока мы поддерживаем WordPress, эта легаси машина будет продолжать покрываться новыми слоями некачественного функционала.

    (Отойдите от экранов, ща будет революционный лозунг!)

    Пора сделать Pull Request к чему-то новому! Плагины для всех CMS, объединяйтесь!

    Да, может сейчас количество плагинов для SSG + HCMS несравнимо с кучей шлака под WordPress (особенно, для русскоязычного сегмента), но почему бы не начать их пилить?

    Шаг за шагом вкладываясь в экосистему SSG этот инструмент имеет все шансы догнать WordPress.

    Вот например на создание Headless FAQ хватило всего 3-х дней и день, чтобы подключить его в SSG блоге и даже на WordPress блоге (форма внизу страницы).

    Короче, я хотел чего-то нового, оно меня нашло. Я его попробовал и теперь новое решение меня полностью устраивает.

    Англоязычный блог я уже веду на SSG. Русскоязычный, скорее всего мигрирую c WordPress на SSG. Тогда и напишу статью на тему переезда.

    Круто, если вы дочитали до конца, спасибо.

    Не могу не добавить стандартное окончание:

    Был ли у вас опыт работы с SSG + HCMS? Что понравилось, а что оставило неприятное послевкусие?

    Серебряных пуль не бывает. Бывают проблемы, которые вы готовы или не готовы проглотить.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    SSG + HCMS vs WordPress

    • 44,9%Пробовал WordPress35
    • 20,5%Пробовал HCMS + SSG16
    • 28,2%Предпочитаю WordPress22
    • 16,7%Предпочитаю HCMS + SSG13
    • 3,8%Стало интересно попробовать WordPress3
    • 9,0%Stonks7
    • 37,2%Стало интересно попробовать SSG + HCMS29

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 23

      +1

      Первая ссылка в гугле по запросу Headless CMS ведет на сайт со списком таких CMS.
      У вас есть опыт использования разных CMS? Что можно выбрать для наиболее гладкого перехода с Wordpress?


      Основной затык в SSG, и преимущество Wordpress, в том, что добавить новую статью на вордпрессе достаточно легко, затем ошибиться и подправить с десяток раз. В случае с SSG — это каждый раз деплой, или установка preview-mode, в котором надо разбираться. А человек, которые обычно ответственен за добавление новых статей в вордпрессе — не шибко хочет разбираться в нюансах SSG.
      При этом, стоимость Contenful CMS "для бизнеса" начинается от 879 долларов за месяц, довольно неподъемная сумма.

        +2
        Боюсь, что опыт перехода с WordPress у меня только начнет появляться в ближайшие пару месяцев, после того как допишу курс.

        Я попробую использовать Ghost.io для перехода с WordPress, потому что (1) он бесплатный, (2) разворачивается в 1 Docker контейнер, (3) любое событие в системе работает через hook, а значит можно встроиться в любой процесс, (4) куча инструкций на стыке Gatsby.js + Ghost.

        Полноценное удобство деплоя SSG, возможно только в случае использования современных систем типа Netlify / Vercel, потому что они берут на себя всю работу по CI / CD.

        Про preview-mode, да, придется применить свое решение: в случае с Ghost.io + Gatsby.js, можно запустить на сервере отдельный Gastby.js в режиме development, со своим доменом и прописать путь не до стандартного API, а до админского, который будет отдавать все draft («черновики»). Тогда редактор, при написании draft статьи сможет просматривать в режиме preview. Думаю, что существуют еще более простые пути решения вопроса, но это первое, что пришло в голову.

        Сейчас я использую Markdown + Github + Vercel, что позволяет в отдельно репозитории делать ветку со статьей, править ее сколько хочу прямо в интерфейсе Github, каждая правка сохраняется как Pull Request и автоматически деплоится через Vercel с отдельным URL. Так что всей командой можем спокойно редактировать.

        Про «человек, которые обычно ответственен за добавление новых статей в вордпрессе» – да, такая проблема имеется, потому что мало кто в рускоязычном сегменте использовал SSG + HCMS, поэтому придется дать людям время на привыкание.
          +1

          Я предпочитаю использовать strapi.io в связке с Gatsby.js. Strapi предоставляет возможность гибкого формирования контента в довольно удобном интерфейсе и управлять доступом к нему через GraphQL API. А у Gatsby есть плагин для интеграции (gatsby-source-strapi). Всё это можно публиковать на Vercel или Git(Hu|La)b Pages. У Vercel есть что-то типа AWS Lambda. И всё это бесплатно.

          +5
          У нас 10+ лет как работает самописная CMS, генерирующая статику (после того, как придя к клиенту в офис, мне потребовалось 20 минут на то, чтобы найти, как на тогдашней джумле подправить пару слов на главной странице). Но вот как-то с магазинами я совсем не понял, как статикой можно обойтись. Одно только ведение корзины уже обязывает делать обработку обращений на серваке.
            +4
            Побольше можно почитать, например, здесь.

            Cвоими словами скажу так: у вас есть SSG, например, Gatsby.js. Он дает вам возможность писать статический и динамический контент на React. То есть, все что может быть статическим (страницы товаров, каталоги и т.д), будет выгружаться статически, а логику и отображение динамической части (корзина, поиск и т.д) вы спокойно пишете на React.

            Соответственно, для реализации корзины вы можете:

            В самом простом случае, вы реализуете логику (как показано здесь) через React Context / Redux + любое хранилище на фронте (localstorage, indexdb, etc.), а оплату можно делать через Stripe и подобные сервисы, где для формирования счета достаточно отправить метаданные о цене и товарах прямо с фронта.

            Если нужно что-то сложнее, то подключаем Firebase / Hasura и имеем CRUD с фронта, с корзиной на backend.

            Если нужно еще сложнее, то добавляем к Firebase / Hasura облачные лямбды (FaaS).

            Если логика еще сложнее, то спокойно пишите свой серверный код и общаетесь с умным фронтом на React.

            Я правильно понял и ответил на вопрос?
              +1

              Ещё, как хороший вариант для бесплатного старта: Vercel Serverless Functions + MongoDB Atlas с бесплатными 500МБ.

              0

              В таком случае можно подключить еще одно *aaS решение с корзиной. С другой стороны, используя next.js никто не мешает создать отдельный раздел с таким же функционалом.
              Наверняка подобные CMS поддерживают возможность user-generated контента, типа комментариев.

              –4
              Зачем огород городить? Если нужна статика, учите HTML+CSS, пишите код в любом удобном «блокноте» и будет вам счастье. Я в недавно далёком 2004 году писал сайты на виндовском блокноте, таблицами, фреймами, картами изображений и прочими мастдаями той эпохи. CSS тогда был куц и скуден и дивами писать было в новинку. Хостились тогда у местных провов, у которых брали диалуп-интернет со скоростью 32 килобит/сек. Шла борьба за каждый байт веса странички — писали код без пробелов и скупо оставляли в нем краткие комментарии. И сайты работали.
              Так что, если вам нужна таки статика, то вам нужна старая школа верстки. Вместо CMS можете использовать Dreamweaver — визуальный HTML-редактор компании Adobe. Тот же блокнот, только с фичами и наворотами.
                0
                Зачем огород городить?

                писали код без пробелов и скупо оставляли в нем краткие комментарии.

                Кажется, вы сами же и ответили на свой вопрос.

                  –1
                  Это делалось для скорости загрузки страницы. С сегодняшними скоростями интернета, ничего не мешает писать какой угодно обширный код, пользуясь текстовым редактором. Всё это от лени писать код руками. Так и начинается вырождение мастеров.
                    +1

                    Лень писать код руками это плохо? Да вы сейчас выкинули последние 50 лет развития программирования

                  0

                  Да, я тоже там был и помню, когда Dreamweaver был какой-то магической штукой, которая за тебя много чего делала. Но сейчас всё немного по другому.


                  Предположим, есть сайт из 100 HTML файлов и везде нужно изменить какой-то блок. Сейчас этот блок — это один React компонент, который лежит в отдельном файле и включается в сборку с помощью описываемых инструментов. Кроме того они делают намного больше полезного чем просто сборка.


                  А вопрос скорости интернета актуален и сейчас. Доля мобильного трафика очень высока и местами его качество оставляет желать лучшего.

                  0
                  Вроде современно и круто, но всё равно остается какое-то послевкусие из нулевых, бесплатный nm.ru, ssi инклуды. Примерно такое же ощущение было в свое время от key-value бд, которые вдруг (после годов триумфального шествия сложных sql баз данных) стали популярными.
                    0

                    Для всего свой инструмент. Описываемые решения, как ни странно, больше нужны для удовлетворения требований поисковиков (SEO) и максимального улучшения пользовательского опыта, что в последнее время близко. Страницы статичны, быстро отдаются серверами, пользователи видят страницу мгновенно со всеми зависимостями в теле документа (разметка, critical CSS, минимизированные превьюшки изображений в виде base64). При навигации по сайту загружается тот минимум, который необходим для отображения следующей страницы. И даже при определенной настройке этот минимум загружается, когда пользователь только навел на ссылку. Похоже, что этот подход уже устаканился и его уже всё чаще и чаще используют большие компании.

                      0
                      Описываемые решения, как ни странно, больше нужны для удовлетворения требований поисковиков (SEO) и максимального улучшения пользовательского опыта, что в последнее время близко
                      Это, мягко говоря, спорно.
                      1) Поисковики сейчас хотя и видят подгружаемый контент, но все же учитывают в основном тот, что уже есть в хтмл странице. Поэтому подгружая часть контента позже — Вы не только лишаете сайт части контента с точки зрения поисковика, но и занимаетесь отчасти клоакингом.
                      2) Пользователь приходит не за каркасом, а за контентом. Но в такой системе каркас встраивается в тело (критикал цсс) что бы не тормозило и было сразу готово, а контент выкидывается за борт (подгружаясь потом как-нибудь) что бы… прямо противоположное:) И это умножается когда подобное реализует в нагруженных проектах, контент загружается мультизапросами, иногда грузится неадекватно долго или не прогружается вообще. При этом учитывая что размер контента не всегда можно спрогнозировать в критической верстке — по мере подгрузки контента страница начинает прыгать.

                      Похоже, что этот подход уже устаканился и его уже всё чаще и чаще используют большие компании.
                      Используют, несомненно. На многих сайтах приходится ждать прогрузки комментариев, допустим. Или боковых блоков. А иногда они не загружаются и приходится перезагружать всю страницу. Или вот интернет магазин — вроде ты залогинился и все ок, а корзина пустая. Не потому что пустая, а потому что не подгрузилась. Но юзеру думает что пустая.
                      А для поисковиков отдается пустая с точки зрения контента страница, поэтому в превью в гугле вместо прежних коротких текстов иногда видишь абсолютно пустую шнягу или кусок навигации с копирайтами. Удобно, чё.

                      На самом деле это подход это шаг назад сделанный как попытка замаскировать проблему быстрой загрузки, но не решить ее. Вместо добавления пары серверов и оптимизации кода, что бы все грузилось за 0.5 секунды вместо прежних 2… делают прогрузку каркаса за 0.1 секунды и радостно рапортуют об успехе, а то что контент потом еще 4 секунды будет весь грузиться таращя страницу и не всегда прогружаясь — да кого это волнует, ведь главное это использование модного подхода. Печально.
                        +2

                        Похоже вы описываете работу обычных SPA, упуская тот момент, что инструменты из статьи при первом запросе в теле документа возвращают всё, в том числе контент.

                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Ой… Ну, вы прям замудрили… Можете написать проще что вы имеете ввиду? Что значит «молчат»? Что значит «не станет React»? Почему его «не станет»? И о каком «дирижабле» идет речь?
                      0
                      довольно плотно занимаюсь разработкой на WP.
                      есть у WP много минусов, но плюсы (для меня и клиентов) пока перевешивают

                      все то, что указано в статье как «минусы WP» в равной мере подходит и для статики.

                      V. Дизайн

                      предложенный подход для кастомизации темы «понатыкать кучу !important» в корне не верен, несет кучу проблем. Как вы сами уже и заметили.

                      2) Начать пилить Тему самому. Но для этого придется использовать PHP, CSS, HTML и рендеринг шаблонов на сервере.

                      Не вижу проблемы в «начать пилить самому». Для SSG при таком подходе нужен будет ровно такой же объем работ. Разве что вместо пхп будет другой язык

                      Во-первых, SSG и HCMS устроены так, что их легко и удобно интегрировать с любой системой, которая имеет API.

                      Ну, ровно то же самое можно сказать при первом знакомстве с WP — он устроен так, что можно легко и удобно добавить нужные плагины.
                      На практике же все не так радужно. Список ваших багов вы в статье привели. С SSG, уверяю, проблемы тоже есть.

                      А теперь просто киллер-фича: SSG позволяет выгрузить весь контент в заранее собранные HTML файлы минимального размера, что уже дает максимальную скорость показу сайта клиенту, так?

                      Есть плагины, которые умеют перегонять WP в статику.
                      Можно сгенерированное позже класть куда угодно.

                      IX. Безопасность

                      тут да, взломать WP с старыми плагинами будет проще, чем облачный хостинг.

                      Но, вы понимаете насколько большая разница качества и удобства подобного функционала? Когда это не “дополнительная функция с плагином”, а основной механизм технологии?

                      нет, разницы не вижу. Если WP + плагин дает ровно тот же функционал, то в чем разница?
                      Стоит еще учитывать, что некоторые фичи WP вначале разрабатываются как отельные плагины, позже, если они востребованы, добавляются в ядро

                      XI. Условная бесплатность

                      выше писал, что в статику WP перегоняется на раз-два. Даже банально, без плагинов — wget + развернутый локально сайт.

                      Вообще, общее впечатление от статьи схоже с чтением отзыва только только приехавшего эмигранта — все вокруг нравится, минусы идут в плюсы и тп.
                      Не, технология отличная, но плюсов в переходе уже существующего проекта (так, чтоб они перевесили время на переход или чтоб время на переход вышло меньше, чем время на устранение проблем на текущей платформе) найти не смог.
                        0
                        предложенный подход для кастомизации темы «понатыкать кучу !important» в корне не верен, несет кучу проблем. Как вы сами уже и заметили.

                        Абсолютно согласен, но проблема в чем: я использую тему Salient и некоторые свойства, кастомизацию которых они сами не дали, мне приходится переписывать через !important, потому что внутри самой темы они написаны через !importnant

                        И можно сказать: «Не используй noname темы» – но это одна из самых знаменитых тем WP вот пруфы: 100 000 покупок по 60$ и 5 звезд рейтинга.

                        Можно сказать: «Так поищи другую, нормальную тему, где нет в коде !important» – но так можно искать вечность.

                        Короче, лично мне надо делать тему с нуля.

                        Не вижу проблемы в «начать пилить самому». Для SSG при таком подходе нужен будет ровно такой же объем работ. Разве что вместо пхп будет другой язык

                        Именно об этом я и говорю: вы – PHP разработчик со стажем на WordPress, я – НЕ PHP разработчик со стажем на WordPress, и не хочу тратить время на его глубокое изучение, как и вспоминать PHP.

                        Поэтому для меня я вижу проблему начать пилить тему самому.

                        Ну, ровно то же самое можно сказать при первом знакомстве с WP — он устроен так, что можно легко и удобно добавить нужные плагины.

                        Через PHP, а я его не хочу использовать.

                        С SSG, уверяю, проблемы тоже есть.

                        Абсолютно согласен.

                        Есть плагины, которые умеют перегонять WP в статику.
                        Можно сгенерированное позже класть куда угодно.

                        Об этом я написал в статье и привел ссылку (даже с видео). Но и описал, что с этим тоже есть проблемы (например, не все WP плагины нормально работают в статике).

                        нет, разницы не вижу. Если WP + плагин дает ровно тот же функционал, то в чем разница?

                        Этот абзац посвящен удобству использования API.

                        Все ли плагины WP адаптируются под API? Нет.
                        Все ли плагины HCMS адаптируются под API? Да.

                        Вот и основная разница.

                        выше писал, что в статику WP перегоняется на раз-два. Даже банально, без плагинов — wget + развернутый локально сайт.

                        В статье и выше написал в чем будут проблемы с этим.

                        Не, технология отличная, но плюсов в переходе уже существующего проекта (так, чтоб они перевесили время на переход или чтоб время на переход вышло меньше, чем время на устранение проблем на текущей платформе) найти не смог.

                        Да, я отлично это понимаю и рад, что вы делаете здравый и правильный для себя выбор. Думаю, что если бы у меня был большой опыт с WP, я бы тоже без ооочень серьезной причины не стал бы переезжать.
                          0
                          как вот это
                          если бы у меня был большой опыт с WP, я бы тоже без ооочень серьезной причины не стал бы переезжать

                          соотносится с вот этим?
                          Пересядь с иглы WordPress на Static Site Generator

                          Что делать, если WordPress (WP) уже не вставляет, а сайт пилить надо? Кейс авторского блога

                          что явно намекает — что статья для людей с опытом работы с WP

                          повторюсь, любой довод из статьи либо не верен, либо исходит из негативного/неправильного личного опыта автора, либо в равной мере относится к WP/JAM

                          я использую тему Salient

                          это проблема конкретно этой темы, к WP никак не относится
                          если взять готовую верстку с кучей !important и попробовать ее использовать на статическом сайте, попутно пытаясь что-то кастомизировать, — вылезут ровно те же проблемы.
                          к самой технологии/движку это вообще никаким боком

                          Именно об этом я и говорю: вы – PHP разработчик со стажем на WordPress, я – НЕ PHP разработчик со стажем на WordPress, и не хочу тратить время на его глубокое изучение, как и вспоминать PHP.

                          Если вы не знаете php, это не значит, что нужно автоматом всем уйти с php движка. В идеале, еще бы и перестать агитировать всех уходить с php, но это утопично.

                          PHP, а я его не хочу использовать.

                          может это и есть основная проблема?

                          например, не все WP плагины нормально работают в статике.

                          а, например, для jamstack этих плагинов вообще может не быть.

                          Все ли плагины WP адаптируются под API? Нет.

                          любой плагин, написанный по стандартам, можно «адаптировать под API»
                          если этот плагин работает только на фронте, вытащить эту часть для headless cms так же реализуемо

                          статья, к сожалению, ни о чем

                            0
                            что явно намекает — что статья для людей с опытом работы с WP

                            Правильно, но «опыт работы» не означает, что читатель – PHP разработчик, который способен написать для WP плагин или подобное.

                            Я, как разработчик, специализирующийся на Full-stack TS (JS) и Golang, из-за незнания альтернатив, использовал WordPress, но уже очень давно не хотел этого делать.

                            JAM – это качественно новый подход, который мне заходит лучше, чем WordPress.

                            Вот таким же людям, как я, которые не хотят в PHP и WP я советую JAM.

                            А WP разработчики, возможно, подчерпнут что-то интересное и в каком-то отдельном кейсе воспользуются связкой WP + SSG, например.

                            Я кстати начну перенос сайта с того, что просто соединю существующий WP блог, с версткой, которая у меня есть на SSG.

                            если взять готовую верстку с кучей !important и попробовать ее использовать на статическом сайте, попутно пытаясь что-то кастомизировать, — вылезут ровно те же проблемы.

                            Да, верно, только в хороших темах для SSG на данный момент такого нет, а в одной из самых популярных WP тем, есть, вот и все.

                            Если вы не знаете php, это не значит, что нужно автоматом всем уйти с php движка.

                            Так я и не говорю уходить) Еще раз: я — НЕ PHP разработчик и для таких же как я существует JAM, о котором я не знал, а о WP знал, поэтому приходилось его использовать.

                            В идеале, еще бы и перестать агитировать всех уходить с php, но это утопично.

                            Зачем уходить с PHP? Я люблю PHP в рыночном контексте: я раньше сам писал на нем, а сейчас очень часто, когда ко мне обращаются за разработкой крупных B2B сервисов я для ядра системы набираю людей на PHP + Symfony / Laravel, а вот более тонкую обвязку можно на NodeJS / Golang.

                            Поэтому желаю здравия всем PHP разработчикам (и вам тоже) и буду агитировать больше людей учить Symfony, как минимум, чтобы посмотреть как круто устроить модульный фреймворк по граммотным концепциям DDD.

                            Symfony вообще очень неплохо устроен внутри, поэтому я постепенно портирую его концепции (DDD Light) в свою библиотеку для NodeJS + TypeScript.

                            может это и есть основная проблема?

                            А вот навязывать PHP мне не нужно, спасибо) Я не полюбил сам писать на нем тогда, не полюблю и сейчас.

                            а, например, для jamstack этих плагинов вообще может не быть.

                            Несомненно

                            любой плагин, написанный по стандартам, можно «адаптировать под API»

                            Несомненно, но для этого нужно делать доп действия, а там это из коробки и это существуенно.

                            статья, к сожалению, ни о чем

                            Жаль, что у вас не получилось узнать что-то новое, может, в следующий раз)
                        +1

                        В опросе не хватает вариантов «пробовал и предпочитаю SSG без CMS». А пост отличный, спасибо!

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое