Говоря официально, JAM-stack — Javsacript, API, Markup, в общем случае статический шаблон наполняемый данными на клиенте через API при помощи Javascript. Говоря простым языком, JAM-стэк это куча костылей, использование которых выйдет боком всем, и прежде всего разработчику. Говоря техническим языком, JAM-стэк — это система интегрированных костылей для создания статических сайтов, с использованием SAAS для гидрации и персистенции данных, а также значительной долей рендеринга на клиенте. Как делали статические сайты деды во времена своей молодости? Они писали простые HTML и CSS файлы и выкладывали их на хостинг по FTP. Как делали статические сайты наши отцы во времена своей буйной молодости? Они использовали Jekyll/Octopress, или любой из сотни генераторов статических сайтов, а полученные HTML и CSS файлы заливали на github pages через коммит, цепляли нужный домен. Некоторые тогда еще устраивали игрища с Disqus, потому что никак кроме игрищ я это назвать не могу, ведь пользователь с учёткой Disqus для оставления комментариев на вашем сайте исчезающе редок.
По балансу цена/затраты времени/сложность поддержки/ограничения в разработке это все было хорошим вариантом. Когда это переставало быть хорошим вариантом, покупался хостинг с php за пару баксов в месяц. Статические страницы ошаблонивались и обзаводились солидным функционалом полноценного сайта. И все было хорошо, а Енисей был из светлого пива. Но наши великие предки нашли нормальную работу и больше не страдают такой фигней. Теперь ей страдаем мы, и что же нам, молодым, смешливым, которым все легко, может предложить индустрия? Она гордо кровохаркает нам в лицо JAM-стэком, и говорит: «Не дождетесь!».
JAM-стэк — это новейший подход к созданию статических сайтов, и Gatsby.JS как один из пророков его. Gatsby — это самый яркий представитель жанра, возводящий насмешку над идеей статических сайтов в абсолют, переводя ее таким образом уже в разряд постиронии. Начнем с того, что Gatsby построен поверх React. Того самого React, который создавался для сайтов, где нужен компонентный подход, т.е. есть какие-то пользовательские интерфейсы, т.е. есть манипуляция с данными. Но у нас ведь статический сайт? Нет? Ретрограда ответ! Теперь это не проблема, у нас ведь есть сервисы типа Netlify и Contentful. Они предоставляют вам возможность через API делать AJAX запросы на их сервера и получать или записывать контент. Т.е. обычная база данных доступная через тридесятую задницу. Зато бесплатно. Первые N запросов, или пользователей, плюс лимит на размер блобов. Акция: уложись во все ограничения и получи оплату от заказчика* (*количество попыток ограничено).
Почему же на первый взгляд это выглядит привлекательно для бизнеса? Потому что React у всех на слуху, а Reactо-макак, которые еще вчера смогли войти в АйТи и готовых работать за копейки очень много. Для Reactо-макак это привлекательно потому что хоть какой-то способ поднять денег и набить портфолио. А сидя у мамки на шее можно литералли не платить ни за хостинг, ни за базу. По этой же причине сумневающемуся заказчику можно, увидев результат, прикинуть нужно ли оно ему вообще, и перестать отвечать на сообщения горе-фрилансера. Также заказчика и исполнителя объединяет достаточно малая компетентность, где первый не понимает как вообще все это работает, а второй не понимает, что сайты можно делать и по-другому.
В итоге, за редким исключением, о котором позже, проигрывают все. React и его производные это сложный инструмент с большой экосистемой и огромными проблемами, которые часто под силу только программистам на React, а не Reactо-макакам. 10 лет назад существовал популярный цирковой номер под названием «вытащить меню со всеми вложенными подменю за один SQL запрос». Теперь у нас есть его идейный наследник — вытащить все данные из нужного сервиса через один GraphQL запрос. Gatsby тянет за собой больше 500 зависимостей, и зная скорость обновления JS экосистемы можно смело сказать — через полгода что-то сломается, если вам понадобится новый сторонний виджет. Через 2 года вы будете заниматься черрипикингом версий, чтобы просто пересобрать это чудо в новый релиз. Да шучу я, шучу! Оно может и в первый раз не собраться по инструкциям с сайта. Если роскомнадзор в очередном порыве заботы о гражданах заблокирует ваш serverless database server, или просто сменит тариф, то развлекаться со всем этим опять вам. Кстати в отличие от традиционных статических сайтов билд сайта на Gatsby !== исходникам сайта. Так что стратегия бэкапа и развертывания этого чуда включая базу данных, да даже без неё, весьма занятная. Но самая мякотка начнется, если уродец созданный школьниками на кривых технологиях понадобится развивать. Поверьте, у PHP верхний предел ублюдочности legacy-кода гораздо ниже, что бы там про него не рассказывали!
Вам, как начинающему разработчику, JAM-стэк для коммерческих проектов использовать невыгодно. Во-первых, статик-сайты с минимальным функционалам — это самое дно фриланса со всем вытекающим и дурнопахнущим. Во-вторых, JAM-стэк — это прямая экономия на разработчике. Вы будете перерасходом своего времени компенсировать кривизну инструментов и сервисов, которая от вас не зависит и для борьбы с которыми у вас пока мало опыта. Тот что вы получите тут вам дальше не пригодится, потому что платежеспособные клиенты смогут вам оплатить хотя бы нормальный хостинг.
Так что же тогда подходящий случай для использования JAM-стэка в его современном виде? На мой взгляд, это ситуация когда ваш достаточно адекватный знакомый или родственник просит вас, React-программиста имеющего нормальную высокооплачиваему работу по своему профилю, сделать относительно простой сайт в свободное время. И вы используя существующие навыки сможете это быстро сделать, объяснив при этом человеку все недостатки такого подхода. И если он согласен, то тогда вперед. Иначе просто расскажите ему про Wordpress и wp2static.
Критика и возражения приветствуются. Но будьте добры указать стоимость и количество проектов, которые вы сделали Gatsby, Next.
Alexufo
Автор, вы же забыли одну вещь. JAM stack нужен чтобы выдавать 100 очков в 4 параметрах в lighthouse. Статика нужна для скорости отдачи и факторов ранжирования и пользовательского удобства. Все остальное по мне вторично.
Как раз на днях изучал генераторы статических сайтов, чтобы уйти с wordpress, потому что он выдавал 300мс даже с кешем. Есть платные решения wp rocket типа прокси с кешем для wp. Но это другой подход. Ситуация вышла такой. Gatsby не рассматривал из-за реакта(эффект дмитри Карловски ), смотрел gridesome на vue. В качестве базы сначала strapi, а потом все таки накатил graphql плагин на wordpress чтобы не переносить контент. Да и работа с контентом у пресса удобнее. И что меня печалит во всей этой ситуации — натягивание на шаблонизатор.
У пресса он такой, у гатсби сякой.
Реакт или вью, одна шарманка, нужно встраивать. Я никак не могу отделаться от мысли, что в 2020 году верстка по прежнему натягивается на что то из-за требований движка сайта. Ведь есть же шаблонизатор pug, который используется при вёрстке, чтобы меньше писать. Есть gulp webpack. Зачем здесь ещё что-то? Ты сверстал, это одобрили, зачем куда-то это натягивать?
Можно же просто подключить в pug строчки для запроса по api чтобы выводить реальный контент. И все. Верстка практически не трогается. Почти исходник!
Не нужно этих вопросов в тостере — «мне нужно добавить на сайт блок, как вы верстаете? Сначала на исходнике и пепеносите или сразу на движке?» Именно по этому критерию Jam stack с оттенком шила на мыло для меня. А так… в принципе неплохо.
action52champion Автор
Это работает если вам нужно дернуть готовую CMS как библиотеку в паре мест. Но как только выясняется что нужно не взять пару записей из базы через CMS, а повторить ее функционал, то оказывается что проще натянуть верстку. Но в том же WP можно делать кастомные страницы хоть в стиле php4 дергая любые данные и пользуясь ACL. И когда вместо этого начинают сбоку городить еще страницы на базе JAM, учитывая кривизну решения самого WP, делая 2 стэка сразу, которые не получаются ни проще, ни дешевле в итоге, то хватаешься за голову.
Alexufo
А какой? функционал wp, это пых, который выводит из бд через шаблоны инфу. Это компенсируется graphql. Вопрос с выводом галлереи внутри постов я еще не изучал.
action52champion Автор
Хотя бы менеджмент контента и его публикацию, если мы говорим о чем-то близком к статическим сайтам. Заканчивая wooCommerce c плагинами для платежных систем, если речь о чем-то сложнее.
Alexufo
Менеджмент в wp можно оставить, рендер в статику по кнопке из wp (запускает gulp по кнопке и генерит статику)
action52champion Автор
Но если у вас и так есть инсталляция WP, то в чем смысл прикручивать сбоку статику генерируемую через gulp?
Alexufo
согласен, на первый взгляд глупо, но:
1. Скорость отдачи 50-80 мс на любую страницу. При конкурентной выдаче в миллионниках ой как плюс.
2. Отказ от шаблонизатора пресса. не смотря на то, что я прекрасно разбираюсь в этой схеме.
Мне приходится ставить плагин, который показывает имя шаблона в момент отображения. Я забываю, чем выводится определенная страница.
Из этого вытекает, что ваш шаблон чистый. Если нужно внести изменения, верстаете прямо на живую, никакого переноса верстка -> шаблон. Верстка и есть шаблон. Из-за этого я в принципе перестал рассматривать преимущества php как шаблонизатора, к сожалению. Хотя. если найти интерпретатор php в ноде который будет делать аналогичное pug, то можно и так. Просто js то уже так и так встроен.
3. Для юзера никаких изменений.
janvarev
Самостоятельно развиваемая года с 2005 CMS, которая тогда работала на PHP4. Сейчас доведена до PHP7. Рендер страницы 30-50 мс без кеша. В особо хреновых случаях (в админке таблица юзеров + куча связанных для них SQL-данных + неоптимизированные запросы) — 3000 мс.
Ощущения: *… мне 300 лет, я выполз из тьмы...*
Alexufo
за 30 и статика не отдается. Что-то тут не то.
janvarev
М-м. Я про PHP-шный рендер. Сколько оно там идет до клиента, это отдельная песня.
Глянуть можно, например, здесь: chesskingdom.ru/docs/TermsOfUse — я даже временно включил показ времени рендера для всех (внизу страницы). По страницам можно походить.
Но там гуляет, да. 30 мс я сейчас не вытащил, а 40-60 вполне.
Alexufo
у вас от 60 до 100 ответ роботу яндекса у этой страницы. Это хороший результат тоже. Статика от 50 до 70. Битрикс около 150 где-то выдает. Если это седьмой пых, он же умеет кешить свое выполнение. Это хорошо.
Но суть как раз в первом байте ответа страницы для поисковика. лайтхаус на производительность не ругается. Обновите jquery до 3. Будет легче и быстрее. Не думаю, что вам нужно 8 IE поддерживать.
Ха, я свой на wp проверил inna-lesovaya.com
Оказывается
Но это признак минимализма скорее и того, что я вел все от дизайна верстки и реализации. WP только из-за того что там хоть как-то сделана нормально заливка фотографий для пользователя, а они тут люди за 60. Правда мейнтейнеры-придурки своим реактом испоганили UX в админке так, что я сам теряюсь что где находится. От SVG анимации главной картинки пришлось отказаться, потому что на андройде UI ВИСЕЛ!!! скрол не работал пока анимация не закончится. На эпле такого не было но это убило всю идею анимации и пришлось отказаться от нее, до сих пор обидно!
janvarev
> От SVG анимации главной картинки пришлось отказаться, потому что на андройде UI ВИСЕЛ!!!
Да, народ иногда отжигает апдейтами…
> Обновите jquery до 3. Будет легче и быстрее.
Вопрос — не знаете, там плагины не слетят? Я просто не слежу за совместимостью, поэтому пока не обновляю старую версию.
Alexufo
думаю нет. Функции там не переименовывались. только дропалась поддержка совместммости со старыми браузерами. Сделайте себе if admin да проверьте