JAM-стэк — нищета на стероидах

    Создавая сайты для малого бизнеса я сталкиваюсь с двумя крайностями. Но только я, как программист. Пользователи не сталкиваются, ведь нельзя столкнуться с тем чего для тебя не существует. Первая крайность — это когда клиент покупает за 50$ в месяц очередной хостинг для Wordpress. Человек не знает, что для Wordpress не нужен специальный хостинг, что такой специальный хостинг как правило хуже чем обычный хостинг и содержит кучу ограничений и стоит дороже. Вторая крайность — это когда используется JAM-стэк ради экономии. Но это экономия в плохом смысле этого слова, когда вы экономите на спичках, используя генератор для питания паяльника, от которого вы прикуриваете.

    Говоря официально, 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.

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

    Ваше мнение о JAM-стэке

    • 17,2%На самом деле отличная технология, за ней будущее23
    • 8,2%Это какой-то… позор11
    • 22,4%Просто распиаренная технология от «serverless» SAAS провайдеров30
    • 3,0%Технология дрянь, но за счет кучи программистов выстрелит4
    • 2,2%Технология уже выстрелила мне в ногу, подробности в комментариях3
    • 47,0%Первый раз слышу про JAM-стэк63

    Средняя зарплата в IT

    110 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 8 431 анкеты, за 2-ое пол. 2020 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +2
      Автор, вы же забыли одну вещь. JAM stack нужен чтобы выдавать 100 очков в 4 параметрах в lighthouse. Статика нужна для скорости отдачи и факторов ранжирования и пользовательского удобства. Все остальное по мне вторично.

      Как раз на днях изучал генераторы статических сайтов, чтобы уйти с wordpress, потому что он выдавал 300мс даже с кешем. Есть платные решения wp rocket типа прокси с кешем для wp. Но это другой подход. Ситуация вышла такой. Gatsby не рассматривал из-за реакта(эффект дмитри Карловски ), смотрел gridesome на vue. В качестве базы сначала strapi, а потом все таки накатил graphql плагин на wordpress чтобы не переносить контент. Да и работа с контентом у пресса удобнее. И что меня печалит во всей этой ситуации — натягивание на шаблонизатор.
      У пресса он такой, у гатсби сякой.

      Реакт или вью, одна шарманка, нужно встраивать. Я никак не могу отделаться от мысли, что в 2020 году верстка по прежнему натягивается на что то из-за требований движка сайта. Ведь есть же шаблонизатор pug, который используется при вёрстке, чтобы меньше писать. Есть gulp webpack. Зачем здесь ещё что-то? Ты сверстал, это одобрили, зачем куда-то это натягивать?

      Можно же просто подключить в pug строчки для запроса по api чтобы выводить реальный контент. И все. Верстка практически не трогается. Почти исходник!

      Не нужно этих вопросов в тостере — «мне нужно добавить на сайт блок, как вы верстаете? Сначала на исходнике и пепеносите или сразу на движке?» Именно по этому критерию Jam stack с оттенком шила на мыло для меня. А так… в принципе неплохо.
        0
        Можно же просто подключить в pug строчки для запроса по api чтобы выводить реальный контент. И все. Верстка практически не трогается. Почти исходник!


        Это работает если вам нужно дернуть готовую CMS как библиотеку в паре мест. Но как только выясняется что нужно не взять пару записей из базы через CMS, а повторить ее функционал, то оказывается что проще натянуть верстку. Но в том же WP можно делать кастомные страницы хоть в стиле php4 дергая любые данные и пользуясь ACL. И когда вместо этого начинают сбоку городить еще страницы на базе JAM, учитывая кривизну решения самого WP, делая 2 стэка сразу, которые не получаются ни проще, ни дешевле в итоге, то хватаешься за голову.
          +1
          а повторить ее функционал,

          А какой? функционал wp, это пых, который выводит из бд через шаблоны инфу. Это компенсируется graphql. Вопрос с выводом галлереи внутри постов я еще не изучал.
            0
            Хотя бы менеджмент контента и его публикацию, если мы говорим о чем-то близком к статическим сайтам. Заканчивая wooCommerce c плагинами для платежных систем, если речь о чем-то сложнее.
              0
              Менеджмент в wp можно оставить, рендер в статику по кнопке из wp (запускает gulp по кнопке и генерит статику)
                0
                Но если у вас и так есть инсталляция WP, то в чем смысл прикручивать сбоку статику генерируемую через gulp?
                  +1
                  согласен, на первый взгляд глупо, но:

                  1. Скорость отдачи 50-80 мс на любую страницу. При конкурентной выдаче в миллионниках ой как плюс.

                  2. Отказ от шаблонизатора пресса. не смотря на то, что я прекрасно разбираюсь в этой схеме.
                  Мне приходится ставить плагин, который показывает имя шаблона в момент отображения. Я забываю, чем выводится определенная страница.

                  Из этого вытекает, что ваш шаблон чистый. Если нужно внести изменения, верстаете прямо на живую, никакого переноса верстка -> шаблон. Верстка и есть шаблон. Из-за этого я в принципе перестал рассматривать преимущества php как шаблонизатора, к сожалению. Хотя. если найти интерпретатор php в ноде который будет делать аналогичное pug, то можно и так. Просто js то уже так и так встроен.

                  3. Для юзера никаких изменений.
          +1
          Самостоятельно развиваемая года с 2005 CMS, которая тогда работала на PHP4. Сейчас доведена до PHP7. Рендер страницы 30-50 мс без кеша. В особо хреновых случаях (в админке таблица юзеров + куча связанных для них SQL-данных + неоптимизированные запросы) — 3000 мс.

          Ощущения: *… мне 300 лет, я выполз из тьмы...*
            0
            Рендер страницы 30-50 мс без кеша.

            за 30 и статика не отдается. Что-то тут не то.
              0
              М-м. Я про PHP-шный рендер. Сколько оно там идет до клиента, это отдельная песня.
              Глянуть можно, например, здесь: chesskingdom.ru/docs/TermsOfUse — я даже временно включил показ времени рендера для всех (внизу страницы). По страницам можно походить.

              Но там гуляет, да. 30 мс я сейчас не вытащил, а 40-60 вполне.
                0
                у вас от 60 до 100 ответ роботу яндекса у этой страницы. Это хороший результат тоже. Статика от 50 до 70. Битрикс около 150 где-то выдает. Если это седьмой пых, он же умеет кешить свое выполнение. Это хорошо.
                Но суть как раз в первом байте ответа страницы для поисковика. лайтхаус на производительность не ругается. Обновите jquery до 3. Будет легче и быстрее. Не думаю, что вам нужно 8 IE поддерживать.

                Ха, я свой на wp проверил inna-lesovaya.com
                Оказывается

                image

                Но это признак минимализма скорее и того, что я вел все от дизайна верстки и реализации. WP только из-за того что там хоть как-то сделана нормально заливка фотографий для пользователя, а они тут люди за 60. Правда мейнтейнеры-придурки своим реактом испоганили UX в админке так, что я сам теряюсь что где находится. От SVG анимации главной картинки пришлось отказаться, потому что на андройде UI ВИСЕЛ!!! скрол не работал пока анимация не закончится. На эпле такого не было но это убило всю идею анимации и пришлось отказаться от нее, до сих пор обидно!
                  0
                  > От SVG анимации главной картинки пришлось отказаться, потому что на андройде UI ВИСЕЛ!!!

                  Да, народ иногда отжигает апдейтами…

                  > Обновите jquery до 3. Будет легче и быстрее.

                  Вопрос — не знаете, там плагины не слетят? Я просто не слежу за совместимостью, поэтому пока не обновляю старую версию.
                    0
                    думаю нет. Функции там не переименовывались. только дропалась поддержка совместммости со старыми браузерами. Сделайте себе if admin да проверьте
          +1
          Очень однобокий анализ получился. Всё пришло к тому, что приравняли Gatsby и JAM и потом проблемы Gatsby сделали проблемами всего JAM-стэка, да еще и на GraphQL накинули. Концепция JAM не в использовании Netlify, Contentful или того же Gatsby, а в предварительном рендеринге контента и отдаче статики пользователю. Serverless концепция уже давно развивается и без JAM-стэка и во многих случаях отлично себя зарекомендовала.

          Но, пожалуй, соглашусь с автором в том, что JAM-стэк зачастую это не лучшее решение для малого бизнеса.
            +1
            Не могу с вами не согласиться, serverless концепция отлично себя зарекомендовала в днищесегменте. Зачем еще она нужна кроме перетаскивания клиентов на свой SAAS я затрудняюсь ответить.

            И я рассмотрел на JAM на примере Gatsby, а не приравнял к нему. Решения на Vue для статических сайтов — это такой же трэш. А работает это потому что есть люди, которые умеют реакт и вью и больше не умеют ничего, а просят дешево. Да будет тупить на мобилках, да будут отваливаться куски сайта на мобильном канале из-за медленного соединения и динамической подгрузки черех вебпак. JAM-стэк взял все худшее от статических сайтов, ограничив возможности, и от обычных динамических страниц, взяв оттуда сложность разработки.

            Опишите мне пожалуйста use case, где JAM отлично себя зарекомендовал, и если можно стоимость.
              +1

              Вы уверены что jamstack сейчас уже настолько популярен что пора начинать с ним борьбу. Из всех известных мне кейсов применения это сайты разработчиков и мотив один использование бесплатного движка github для хостинга.

              +1
              Не совсем понял что за проблемы на мобилках, мы точно об одном и том же говорим? По-вашему, в чем отличие обычного SPA, SSR и статического сайта с регидрацией, построенном на фреймворке типа Gatsby?
              JAM отлично подходит для контентных сайтов aka корпоративные сайты, например сайт для Роснефти можно спокойно сделать на JAM-стэке. Или для документаций, тут вроде это уже стандарт. Взять тот же web.dev или доку React. Обе построены по принципу JAM, а второй на Gatsby в частности.
              Стоимость таких проектов от 1 млн рублей.
                +2
                Не совсем понял что за проблемы на мобилках, мы точно об одном и том же говорим?


                Мобилки все еще слабые, и лишний рендеринг на клиенте неприятно замедляет сайт. Да, можно вылизать, но не проще ли сразу использовать традиционные технологии? Мобильный интернет все еще плохой, дело даже не в скорости, а в стабильности, кусок сайта загрузился до того как вы заехали под мост или перскочили в радиус действия другой вышки и контент, а оставшиеся — нет. Можно конечно настроить чанкинг, заембеддить все что только можно, но не проще ли сразу использовать традиционные технологии?

                По-вашему, в чем отличие обычного SPA, SSR и статического сайта с регидрацией, построенном на фреймворке типа Gatsby?


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

                JAM отлично подходит для контентных сайтов aka корпоративные сайты, например сайт для Роснефти можно спокойно сделать на JAM-стэке.


                В чем преимущество перед кучей готовых решений на базе WP, Drupal и кучи других CMS? Я вижу только излишние усложнения. Если речь о чисто статических сайтах, то в чем преимущество перед генераторами старой школы типа Jekyll, которые будут генерировать страницы которые не будут догенерировать сами себя на клиента?

                Взять тот же web.dev или доку React. Обе построены по принципу JAM, а второй на Gatsby в частности.


                Так почему бы не сделать документацию генерируемую один раз без догенерации на клиенте? Из плюсов — можно скачивать, быстрее смотреть на слабых устройствах.

                Стоимость таких проектов от 1 млн рублей.


                И мы вновь возвращаемся к вопросу, зачем нам этот цирк с JAM, если у нас есть нормальные деньги?
                  0
                  В чем преимущество перед кучей готовых решений на базе WP, Drupal и кучи других CMS?

                  Только безопасность! Никаких ЯП на проде. Сечин вас не покормит колбаской, если там разместят хукеры что нибудь из, естественно, Украины. Эта единственная причина, которая затирает все остальное.

                  в чем преимущество перед генераторами старой школы типа Jekyll


                  С таким рылом на собеседование не завалишься. Я тут чувак из старой школы, вы тут все просто хайпуете и даже если я на 100% прав это не является критерием. Новое хуже не значит хуже для всего. Лучше для вас, в качестве опыта, только из-за новизны.

                  И мы вновь возвращаемся к вопросу, зачем нам этот цирк с JAM, если у нас есть нормальные деньги?


                  Во первых, 20% вам… как в том анекдоте… а почемы бы и нет раз есть бабки? Чо толку то предыдущий опыт обсусоливать?
                    0
                    Только безопасность! Никаких ЯП на проде. Сечин вас не покормит колбаской, если там разместят хукеры что нибудь из, естественно, Украины. Эта единственная причина, которая затирает все остальное.


                    Это легко достигается решениями типа Jekyll.

                    С таким рылом на собеседование не завалишься. Я тут чувак из старой школы, вы тут все просто хайпуете и даже если я на 100% прав это не является критерием. Новое хуже не значит хуже для всего. Лучше для вас, в качестве опыта, только из-за новизны.


                    Это уже тема взаимоотношений при найме и на работе.

                    Во первых, 20% вам… как в том анекдоте… а почемы бы и нет раз есть бабки? Чо толку то предыдущий опыт обсусоливать?


                    Абырвалг?
                      0
                      Это уже тема взаимоотношений при найме и на работе.

                      Не согласен. Из-за этого и начинают новое пробовать. Чтобы быть актуальным. Никто не хочет не быть в спросе, поэтому такая хрень в js мире, 2mb скриптов на лендинге с формой. Я считаю это явление проявлением сильно недооцененной энергией в индустрии. Капитализьм!
                  0
                  А я знаю, на чём делали этот сайт, ха. Вы недалеко от истины, публичная часть там действительно вся статика.
              0

              Положение с cms сейчас такое нмв есть два лидера и они PHP wp и drupal. Есть nodejs коотрый пока не дал ни одной мощной общепризнанной cms. Это парадокс. Так как есть с чего брать пример можно просто портировать. И как бы фронт с бэком говорят на одном языке.
              Вопрос нужно ли это бизнесу как бы к разработчикам мало относится. Наверное сайт свой должен быть у всех кто хочет иметь поток клиентов. И на чем там это все работает вопрос самый последний. Почему бы это не был просто html или pdf. Ах да у нас же есть еще разработчики которым не все равно.
              А вот без чего точно не обойтись это без своего доменного имени. cvety.narod.ru как то не очень располагает к доверию. И дизайн. На что многие вообще особо не тратятся.
              Что касается скорости работы если контент на столько статический что его можно генерировать и деплоить как статику. То по факту тот же эффект будет если просто закэшировать все nginx'ом.

                0
                То по факту тот же эффект будет если просто закэшировать все nginx'ом.

                только для nginx нужна vps, своя система бекапов бд, файлов и прочее. Если это все есть, вероятно смысла нет. Но поднимать с нуля это мало имеет смысла. А так у тебя просто статика в папке и муллион хостингов, даже бесплатных.

                Битрикс забыли, друпал какой-то… сейчас битрикс кормит 80% рынка. Правда там неттакого понятия, как галерея фотографий в середине текста как в wp, лендинги с конструктором сайтов не работают без активной лицензии… поддержка говорит невозможно в рамках текущей реализации, а в комментах исходников написано как и прочая ласковая любовь к недевелоперам)
                +1
                Ощущение конструктивности критики начинает исчезать уже во втором абзаце, но я не мог пройти мимо

                Наверное вы неправильно поняли весь смысл тех же Next, nuxt, gatsby и прочих. По своей сути они представляют собой фреймворк для создания всего frontend'а для проекта с уже решенными проблемами навигации, server-side rendering'а, сборки и прочего. При этом использование любого бэкэнда, хоть того же php, это вполне нормальная практика, которая объединяет компонентный подход клиента и server-side render для быстрой загрузки и SEO с аккуратным API со стороны бэкэнда, где нет необходимости мучаться с шаблонами и можно отдавать обычный json из любой cms.

                Возможность создания статических страниц из набора даннных это просто одна из побочных функций SSR. «Эй, мы же и так рендерим страницу полностью на сервере, почему бы нам не срендерить сразу несколько страниц?». Кардинальное отличие этих инструментов от ого же wp2satic это возможность гидрации динамического контента (объединение результата server-side рендера с клиентскими данными), что избавляет от пустых страниц с появляющимся контеном и от дополнительных запросов на сервер.

                Само понятие JAM не привязывается ни к Netlify, ни к Contentfull. Это просто идея использования микросервисов напрямую из клиентского приложения, убирая лиший сервер в инфраструктуре. Тот же Firebase это хорошо демонстрирует, а вместе с realtime функциональностью firestore это становится просто сказкой для чего-то вроде комментариев/сообщений или совместной работы над документом. Разумеется в этом подходе можно как использовть сторонние SaaS решения, так и свои собственные, со всеми вытекающими последствиями vendor lock-in'а / необходимости поддержки, просто нужно выбирать подходящие решения под задачу, а простой запрос в managed базу не важно из чего писать: хоть php, хоть js.

                Про поддержку можно много чего написать, но я вкратце поясню: уже давно прошли времена jquery, когда нужно было рукми подбирать специфические версии UI компонентов друг под друга. С приходом общего и стабильного API этого стало в разы меньше, но как и в любой другой экосистеме можно найти примеры обратного. Есть способы зафиксировать версии зависимостей (это уже стало поведением по умолчанию, если мы говорим про npm) и запустить проект хоть через полгода, хоть через два. Тут уже все на совести разработчика, а сделать плохо ни один язык не может запретить, хоть и очень сильно стараются.

                Как я понял, вам очень комфортно работать с Wordpress CMS и вы противопоставляете его тем же gatsby и next. Но на самом деле они могут работать в связке: Wordpress CMS может работать как headless cms для клиента на gatsby и обеспечивать доступ в базу, интеграции со сторонними сервисами, и так далее, но со всеми преимуществами nuxt, такими как server side rendering, быстрая загрузка контента, отсутствие мигающего контента, счет в 100 баллов от lighthouse и так далее.
                  +1
                  По своей сути они представляют собой фреймворк для создания всего frontend'а для проекта с уже решенными проблемами навигации, server-side rendering'а, сборки и прочего. При этом использование любого бэкэнда, хоть того же php, это вполне нормальная практика, которая объединяет компонентный подход клиента и server-side render для быстрой загрузки и SEO с аккуратным API со стороны бэкэнда, где нет необходимости мучаться с шаблонами и можно отдавать обычный json из любой cms.


                  Полностью с вами согласен. Но все это есть и для условного Wordpress. И разумно использовать или WP или полный кастом, потому что возможностей больше а костылей меньше. Есть только одно исключение — у вас уже есть команда фронтедщиков, а бэкенд делается по остаточному принципу. Это фронтенд головного мозга или попытки использовать то что есть в наличии, невзирая на кривизну.

                  Возможность создания статических страниц из набора даннных это просто одна из побочных функций SSR. «Эй, мы же и так рендерим страницу полностью на сервере, почему бы нам не срендерить сразу несколько страниц?». Кардинальное отличие этих инструментов от ого же wp2satic это возможность гидрации динамического контента (объединение результата server-side рендера с клиентскими данными), что избавляет от пустых страниц с появляющимся контеном и от дополнительных запросов на сервер.


                  Складывается впечатление, что вы создаете проблему и тут же мужественно ее решаете. В чем преимущество гидрации перед традиционным подходом?

                  Само понятие JAM не привязывается ни к Netlify, ни к Contentfull. Это просто идея использования микросервисов напрямую из клиентского приложения, убирая лиший сервер в инфраструктуре. Тот же Firebase это хорошо демонстрирует, а вместе с realtime функциональностью firestore это становится просто сказкой для чего-то вроде комментариев/сообщений или совместной работы над документом. Разумеется в этом подходе можно как использовть сторонние SaaS решения, так и свои собственные, со всеми вытекающими последствиями vendor lock-in'а / необходимости поддержки, просто нужно выбирать подходящие решения под задачу, а простой запрос в managed базу не важно из чего писать: хоть php, хоть js.


                  К сожалению эта идея встречается мне чаще всего именно в такой реализации.

                  Про поддержку можно много чего написать, но я вкратце поясню: уже давно прошли времена jquery, когда нужно было рукми подбирать специфические версии UI компонентов друг под друга. С приходом общего и стабильного API этого стало в разы меньше, но как и в любой другой экосистеме можно найти примеры обратного.


                  Вы очень сильно лукавите, особенно если речь о сайтах постарше, где половина фронтенда jQuery и несколько страниц на Vue/React.

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


                  А можно и не запустить, особенно если часть пакетов была на гитхабе. Или просто вам попадется неудачная комбинация nodejs + npm на текущем сервере, который проблематично обновить. Конечно это все тоже на совести разработчика, но так ведь про все можно сказать.

                  Как я понял, вам очень комфортно работать с Wordpress CMS и вы противопоставляете его тем же gatsby и next. Но на самом деле они могут работать в связке: Wordpress CMS может работать как headless cms для клиента на gatsby и обеспечивать доступ в базу, интеграции со сторонними сервисами, и так далее, но со всеми преимуществами nuxt, такими как server side rendering, быстрая загрузка контента, отсутствие мигающего контента, счет в 100 баллов от lighthouse и так далее.


                  Вы меня абсолютно неправильно поняли. Мне грустно от вкатывальщиков во фронтенд, которые в принципе не понимают, что можно делать по-другому. Напрягает идея использовать связку костылей чтобы гугл поставил 100 баллов, вместо того чтобы изначально не использовать инструменты, где нужны эти костыли. И это используется в конкурентной тематике, где решающее значение имеет сколько денег ты влив в рекламу. И при этом JAM поют дифирамбы, ссылаясь на блоги хипстеров-затейников, которые рассматривают кейзы, что нашему вкатывальщику в жизни не попадутся. JAM здорового человека — это когда команда фронтедщиков и бэкэндщиков работают отдельно, и им нужен GraphQL, чтобы был какой-то универсальный способ общения. Это когда у вас огромная инфраструктура, и вам нужен ВНУТРЕННИЙ сервис, который будет дергать данные с других сервисов. А ИРЛ я вижу JAM в 95% случаев только на днищепроектах на фрилансе. Где весь serverless заключается в том, что на сервер денег нет. В общем JAM в том виде в котором он задумывался и тот ублюдок, что получился — это настолько разные вещи, что их грешно одним словом называть.
                    +1
                    И разумно использовать или WP или полный кастом, потому что возможностей больше а костылей меньше. Есть только одно исключение — у вас уже есть команда фронтедщиков, а бэкенд делается по остаточному принципу. Это фронтенд головного мозга или попытки использовать то что есть в наличии, невзирая на кривизну.

                    Не обязательно так радикально идти в какую-то сторону. Например можно взять несколько решений и объединить в одно, напрмер cms + сторонний сервис для медиа контента, или сторонний полнотекстовый поиск. А бэкэнд в любом случае делается под фронт. Например если для открытия домашней страницы нужно сделать 20 JOIN операций, то это точно ни к чему хорошему не приведет. Но в JAM подходе мы можем разбить один большой монолит бэкэнда на отдельные сервисы

                    Складывается впечатление, что вы создаете проблему и тут же мужественно ее решаете. В чем преимущество гидрации перед традиционным подходом?

                    А эта проблема была изначально: представим что нам нужно передать состояние с бэка на фронт. Это будет либо через глобальные JS переменные записанные в script тэги, либо через data-* атрибуты прямо в DOM элементы. Тогда придется работать с одной и той же логикой в темплейте, записывая туда данные с бэка, а затем на фронте. Это очень плохо масштабируется и поддерживается, а при использовании UI фреймворков становится совсем тяжело из-за того что они берут на себя рендер страницы. В случае server-side rendering этот процесс происходит автоматически, и DOM дерево построенное на сервере совпадает с DOM деревом которое построит клиент, а значит с ним можно работать без дополнительных обработок глобальных переменных и data-* атрибутов, а самое главное что это происходит автоматически.

                    Вы очень сильно лукавите, особенно если речь о сайтах постарше, где половина фронтенда jQuery и несколько страниц на Vue/React.

                    Тут уже вопрос поддержки legacy кода: фиксировать версии плагинов jQuery или скачивать их на свой хостинг. Новые же страницы на Vue/React не будут страдать от таких проблем с поддержкой.

                    А можно и не запустить, особенно если часть пакетов была на гитхабе. Или просто вам попадется неудачная комбинация nodejs + npm на текущем сервере

                    Это опять вопрос к работе с legacy на jQuery, сейчас все компоненты для react/Vue/angular ставятся через npm, где можно зафиксировать версии и где есть уверенность в том что версия не будет удалена. Версия npm не влияет на сборку (кроме версий <5, из-за package-lock), но его можно обновить через него самого. У того же gatsby версии node поддерживаются все корторые обозначены как lts, и бинарные зависимости скорее всего для них уже будут собраны.

                    Ну и последнее: любую новую технологию пытаются продать, и многие будут ее представлять как серебрянную пулю, что не есть правильно. На своем опыте «JAM» (название появилось уже после того как он был применен, до этого я не знал что пишу на JAM) стэк хорошо себя показал как внутренняя система для сотрудников (nuxt + firebase для realtime), как быстрый способ создать документацию (такую как сейчас делают многие opensource проекты, прямо из readme файла с редактируемыми примерами, поиском и локализацией) и как способ создавать дополнительные страницы в уже существующем проекте, без больших migration скриптов и создания сущностей в cms на каждый чих
                      0
                      Не обязательно так радикально идти в какую-то сторону.


                      На данный момент JAM и является достаточно радикальным решением при наличии традиционных и технически более удачных.

                      Например можно взять несколько решений и объединить в одно, напрмер cms + сторонний сервис для медиа контента, или сторонний полнотекстовый поиск.


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

                      А бэкэнд в любом случае делается под фронт. Например если для открытия домашней страницы нужно сделать 20 JOIN операций, то это точно ни к чему хорошему не приведет. Но в JAM подходе мы можем разбить один большой монолит бэкэнда на отдельные сервисы


                      В JAM подходе вы никуда не денетесь от алгоритмической сложности 20 джойнов, если они нужны. Задолго до JAM существовали WSDL и RPC, даже задолго до того как все стали носиться с микросервисами. Кто хотел, тот пользовался.

                      А эта проблема была изначально: представим что нам нужно передать состояние с бэка на фронт. Это будет либо через глобальные JS переменные записанные в script тэги, либо через data-* атрибуты прямо в DOM элементы. Тогда придется работать с одной и той же логикой в темплейте, записывая туда данные с бэка, а затем на фронте. Это очень плохо масштабируется и поддерживается, а при использовании UI фреймворков становится совсем тяжело из-за того что они берут на себя рендер страницы. В случае server-side rendering этот процесс происходит автоматически, и DOM дерево построенное на сервере совпадает с DOM деревом которое построит клиент, а значит с ним можно работать без дополнительных обработок глобальных переменных и data-* атрибутов, а самое главное что это происходит автоматически.


                      Описанное вами — скорее проблема роста сайта, который изначально не был рассчитан на сложный фронтенд. У нее нет хорошего решения, потому что либо вы оставляете минимальный фронтенд, либо вы переделываете все в угоду фронтенду. Если изначально у нас есть бэкенд, который только отдает данные, но не рендерит, то проблемы нет. Но вот вопрос, в каком проценте случаев, особенно если речь о нижнем сегменте фриланса, куда пихают JAM, нужен этот серьезный фронтенд?

                      Тут уже вопрос поддержки legacy кода: фиксировать версии плагинов jQuery или скачивать их на свой хостинг. Новые же страницы на Vue/React не будут страдать от таких проблем с поддержкой.

                      Это опять вопрос к работе с legacy на jQuery, сейчас все компоненты для react/Vue/angular ставятся через npm, где можно зафиксировать версии и где есть уверенность в том что версия не будет удалена. Версия npm не влияет на сборку (кроме версий <5, из-за package-lock), но его можно обновить через него самого. У того же gatsby версии node поддерживаются все корторые обозначены как lts, и бинарные зависимости скорее всего для них уже будут собраны.


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

                      Ну и последнее: любую новую технологию пытаются продать, и многие будут ее представлять как серебрянную пулю, что не есть правильно. На своем опыте «JAM» (название появилось уже после того как он был применен, до этого я не знал что пишу на JAM) стэк хорошо себя показал как внутренняя система для сотрудников (nuxt + firebase для realtime), как быстрый способ создать документацию (такую как сейчас делают многие opensource проекты, прямо из readme файла с редактируемыми примерами, поиском и локализацией) и как способ создавать дополнительные страницы в уже существующем проекте, без больших migration скриптов и создания сущностей в cms на каждый чих


                      Так у вас был JAM здорового человека.
                  +1

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

                    0
                    Так весь вопрос в том, кому именно она нужна, разработчику, заказчику, или тому парню, которые продает первым двум свой serverless SAAS.
                    0
                    Замечательно, про реактомакак пишет вордпресс-хомячек.
                      0

                      Все технологии и еют свое применение. Мне сложно представить ситуацию когда бы мега программисты на cpp или rust зависали на форумах и гнобили разработчиков на PHP или js или 1с.

                      +1
                      В начале статьи не хватает пары слов, что это вообще за JAM такой. Не все ведь так глубоко в теме, даже если эпизодически следят за миром JS.
                        0

                        Сто пудов сам гуглил но и гугл не знает если не задать уточняющих слов

                        +1
                        Забавное наблюдение. Стоило мне заинтересоваться генераторами статических сайтов в личных целях, сразу кто-то запустил микрокурс по Hugo, у ютуберов, на которых я давно подписан, появились видео на эту тему, вот еще статья на Хабре про JAM-стэк, про который, помоему, вообще никто не вспоминает. И увидел я ее не в каких-то персонализированных подборках для меня, а в телеграм-боте, который ежедневные рандомные статейки дергает.
                        Я что, в шоу Трумана?

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

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