Комментарии 38
Автор, вы же забыли одну вещь. JAM stack нужен чтобы выдавать 100 очков в 4 параметрах в lighthouse. Статика нужна для скорости отдачи и факторов ранжирования и пользовательского удобства. Все остальное по мне вторично.
Как раз на днях изучал генераторы статических сайтов, чтобы уйти с wordpress, потому что он выдавал 300мс даже с кешем. Есть платные решения wp rocket типа прокси с кешем для wp. Но это другой подход. Ситуация вышла такой. Gatsby не рассматривал из-за реакта(эффект дмитри Карловски ), смотрел gridesome на vue. В качестве базы сначала strapi, а потом все таки накатил graphql плагин на wordpress чтобы не переносить контент. Да и работа с контентом у пресса удобнее. И что меня печалит во всей этой ситуации — натягивание на шаблонизатор.
У пресса он такой, у гатсби сякой.
Реакт или вью, одна шарманка, нужно встраивать. Я никак не могу отделаться от мысли, что в 2020 году верстка по прежнему натягивается на что то из-за требований движка сайта. Ведь есть же шаблонизатор pug, который используется при вёрстке, чтобы меньше писать. Есть gulp webpack. Зачем здесь ещё что-то? Ты сверстал, это одобрили, зачем куда-то это натягивать?
Можно же просто подключить в pug строчки для запроса по api чтобы выводить реальный контент. И все. Верстка практически не трогается. Почти исходник!
Не нужно этих вопросов в тостере — «мне нужно добавить на сайт блок, как вы верстаете? Сначала на исходнике и пепеносите или сразу на движке?» Именно по этому критерию Jam stack с оттенком шила на мыло для меня. А так… в принципе неплохо.
Как раз на днях изучал генераторы статических сайтов, чтобы уйти с wordpress, потому что он выдавал 300мс даже с кешем. Есть платные решения wp rocket типа прокси с кешем для wp. Но это другой подход. Ситуация вышла такой. Gatsby не рассматривал из-за реакта(эффект дмитри Карловски ), смотрел gridesome на vue. В качестве базы сначала strapi, а потом все таки накатил graphql плагин на wordpress чтобы не переносить контент. Да и работа с контентом у пресса удобнее. И что меня печалит во всей этой ситуации — натягивание на шаблонизатор.
У пресса он такой, у гатсби сякой.
Реакт или вью, одна шарманка, нужно встраивать. Я никак не могу отделаться от мысли, что в 2020 году верстка по прежнему натягивается на что то из-за требований движка сайта. Ведь есть же шаблонизатор pug, который используется при вёрстке, чтобы меньше писать. Есть gulp webpack. Зачем здесь ещё что-то? Ты сверстал, это одобрили, зачем куда-то это натягивать?
Можно же просто подключить в pug строчки для запроса по api чтобы выводить реальный контент. И все. Верстка практически не трогается. Почти исходник!
Не нужно этих вопросов в тостере — «мне нужно добавить на сайт блок, как вы верстаете? Сначала на исходнике и пепеносите или сразу на движке?» Именно по этому критерию Jam stack с оттенком шила на мыло для меня. А так… в принципе неплохо.
Можно же просто подключить в pug строчки для запроса по api чтобы выводить реальный контент. И все. Верстка практически не трогается. Почти исходник!
Это работает если вам нужно дернуть готовую CMS как библиотеку в паре мест. Но как только выясняется что нужно не взять пару записей из базы через CMS, а повторить ее функционал, то оказывается что проще натянуть верстку. Но в том же WP можно делать кастомные страницы хоть в стиле php4 дергая любые данные и пользуясь ACL. И когда вместо этого начинают сбоку городить еще страницы на базе JAM, учитывая кривизну решения самого WP, делая 2 стэка сразу, которые не получаются ни проще, ни дешевле в итоге, то хватаешься за голову.
а повторить ее функционал,
А какой? функционал wp, это пых, который выводит из бд через шаблоны инфу. Это компенсируется graphql. Вопрос с выводом галлереи внутри постов я еще не изучал.
Хотя бы менеджмент контента и его публикацию, если мы говорим о чем-то близком к статическим сайтам. Заканчивая wooCommerce c плагинами для платежных систем, если речь о чем-то сложнее.
Менеджмент в wp можно оставить, рендер в статику по кнопке из wp (запускает gulp по кнопке и генерит статику)
Но если у вас и так есть инсталляция WP, то в чем смысл прикручивать сбоку статику генерируемую через gulp?
согласен, на первый взгляд глупо, но:
1. Скорость отдачи 50-80 мс на любую страницу. При конкурентной выдаче в миллионниках ой как плюс.
2. Отказ от шаблонизатора пресса. не смотря на то, что я прекрасно разбираюсь в этой схеме.
Мне приходится ставить плагин, который показывает имя шаблона в момент отображения. Я забываю, чем выводится определенная страница.
Из этого вытекает, что ваш шаблон чистый. Если нужно внести изменения, верстаете прямо на живую, никакого переноса верстка -> шаблон. Верстка и есть шаблон. Из-за этого я в принципе перестал рассматривать преимущества php как шаблонизатора, к сожалению. Хотя. если найти интерпретатор php в ноде который будет делать аналогичное pug, то можно и так. Просто js то уже так и так встроен.
3. Для юзера никаких изменений.
1. Скорость отдачи 50-80 мс на любую страницу. При конкурентной выдаче в миллионниках ой как плюс.
2. Отказ от шаблонизатора пресса. не смотря на то, что я прекрасно разбираюсь в этой схеме.
Мне приходится ставить плагин, который показывает имя шаблона в момент отображения. Я забываю, чем выводится определенная страница.
Из этого вытекает, что ваш шаблон чистый. Если нужно внести изменения, верстаете прямо на живую, никакого переноса верстка -> шаблон. Верстка и есть шаблон. Из-за этого я в принципе перестал рассматривать преимущества php как шаблонизатора, к сожалению. Хотя. если найти интерпретатор php в ноде который будет делать аналогичное pug, то можно и так. Просто js то уже так и так встроен.
3. Для юзера никаких изменений.
Самостоятельно развиваемая года с 2005 CMS, которая тогда работала на PHP4. Сейчас доведена до PHP7. Рендер страницы 30-50 мс без кеша. В особо хреновых случаях (в админке таблица юзеров + куча связанных для них SQL-данных + неоптимизированные запросы) — 3000 мс.
Ощущения: *… мне 300 лет, я выполз из тьмы...*
Ощущения: *… мне 300 лет, я выполз из тьмы...*
Рендер страницы 30-50 мс без кеша.
за 30 и статика не отдается. Что-то тут не то.
М-м. Я про PHP-шный рендер. Сколько оно там идет до клиента, это отдельная песня.
Глянуть можно, например, здесь: chesskingdom.ru/docs/TermsOfUse — я даже временно включил показ времени рендера для всех (внизу страницы). По страницам можно походить.
Но там гуляет, да. 30 мс я сейчас не вытащил, а 40-60 вполне.
Глянуть можно, например, здесь: chesskingdom.ru/docs/TermsOfUse — я даже временно включил показ времени рендера для всех (внизу страницы). По страницам можно походить.
Но там гуляет, да. 30 мс я сейчас не вытащил, а 40-60 вполне.
у вас от 60 до 100 ответ роботу яндекса у этой страницы. Это хороший результат тоже. Статика от 50 до 70. Битрикс около 150 где-то выдает. Если это седьмой пых, он же умеет кешить свое выполнение. Это хорошо.
Но суть как раз в первом байте ответа страницы для поисковика. лайтхаус на производительность не ругается. Обновите jquery до 3. Будет легче и быстрее. Не думаю, что вам нужно 8 IE поддерживать.
Ха, я свой на wp проверил inna-lesovaya.com
Оказывается
Но это признак минимализма скорее и того, что я вел все от дизайна верстки и реализации. WP только из-за того что там хоть как-то сделана нормально заливка фотографий для пользователя, а они тут люди за 60. Правда мейнтейнеры-придурки своим реактом испоганили UX в админке так, что я сам теряюсь что где находится. От SVG анимации главной картинки пришлось отказаться, потому что на андройде UI ВИСЕЛ!!! скрол не работал пока анимация не закончится. На эпле такого не было но это убило всю идею анимации и пришлось отказаться от нее, до сих пор обидно!
Но суть как раз в первом байте ответа страницы для поисковика. лайтхаус на производительность не ругается. Обновите jquery до 3. Будет легче и быстрее. Не думаю, что вам нужно 8 IE поддерживать.
Ха, я свой на wp проверил inna-lesovaya.com
Оказывается
Но это признак минимализма скорее и того, что я вел все от дизайна верстки и реализации. WP только из-за того что там хоть как-то сделана нормально заливка фотографий для пользователя, а они тут люди за 60. Правда мейнтейнеры-придурки своим реактом испоганили UX в админке так, что я сам теряюсь что где находится. От SVG анимации главной картинки пришлось отказаться, потому что на андройде UI ВИСЕЛ!!! скрол не работал пока анимация не закончится. На эпле такого не было но это убило всю идею анимации и пришлось отказаться от нее, до сих пор обидно!
Очень однобокий анализ получился. Всё пришло к тому, что приравняли Gatsby и JAM и потом проблемы Gatsby сделали проблемами всего JAM-стэка, да еще и на GraphQL накинули. Концепция JAM не в использовании Netlify, Contentful или того же Gatsby, а в предварительном рендеринге контента и отдаче статики пользователю. Serverless концепция уже давно развивается и без JAM-стэка и во многих случаях отлично себя зарекомендовала.
Но, пожалуй, соглашусь с автором в том, что JAM-стэк зачастую это не лучшее решение для малого бизнеса.
Но, пожалуй, соглашусь с автором в том, что JAM-стэк зачастую это не лучшее решение для малого бизнеса.
Не могу с вами не согласиться, serverless концепция отлично себя зарекомендовала в днищесегменте. Зачем еще она нужна кроме перетаскивания клиентов на свой SAAS я затрудняюсь ответить.
И я рассмотрел на JAM на примере Gatsby, а не приравнял к нему. Решения на Vue для статических сайтов — это такой же трэш. А работает это потому что есть люди, которые умеют реакт и вью и больше не умеют ничего, а просят дешево. Да будет тупить на мобилках, да будут отваливаться куски сайта на мобильном канале из-за медленного соединения и динамической подгрузки черех вебпак. JAM-стэк взял все худшее от статических сайтов, ограничив возможности, и от обычных динамических страниц, взяв оттуда сложность разработки.
Опишите мне пожалуйста use case, где JAM отлично себя зарекомендовал, и если можно стоимость.
И я рассмотрел на JAM на примере Gatsby, а не приравнял к нему. Решения на Vue для статических сайтов — это такой же трэш. А работает это потому что есть люди, которые умеют реакт и вью и больше не умеют ничего, а просят дешево. Да будет тупить на мобилках, да будут отваливаться куски сайта на мобильном канале из-за медленного соединения и динамической подгрузки черех вебпак. JAM-стэк взял все худшее от статических сайтов, ограничив возможности, и от обычных динамических страниц, взяв оттуда сложность разработки.
Опишите мне пожалуйста use case, где JAM отлично себя зарекомендовал, и если можно стоимость.
Вы уверены что jamstack сейчас уже настолько популярен что пора начинать с ним борьбу. Из всех известных мне кейсов применения это сайты разработчиков и мотив один использование бесплатного движка github для хостинга.
damnerd писал про хороший кейс переноса на статику, жаль что нет аналогичного подхода оформленного в некий «движок» или хотя бы набор обговоренных практик, конкурентный JAM stack
И в том хорошем кейсе автору намекнули о проблемности такого подхода:
habr.com/ru/company/e-Legion/blog/440134/#comment_20004358
habr.com/ru/company/e-Legion/blog/440134/#comment_20007458
habr.com/ru/company/e-Legion/blog/440134/#comment_20012014
habr.com/ru/company/e-Legion/blog/440134/#comment_20004358
habr.com/ru/company/e-Legion/blog/440134/#comment_20007458
habr.com/ru/company/e-Legion/blog/440134/#comment_20012014
Не совсем понял что за проблемы на мобилках, мы точно об одном и том же говорим? По-вашему, в чем отличие обычного SPA, SSR и статического сайта с регидрацией, построенном на фреймворке типа Gatsby?
JAM отлично подходит для контентных сайтов aka корпоративные сайты, например сайт для Роснефти можно спокойно сделать на JAM-стэке. Или для документаций, тут вроде это уже стандарт. Взять тот же web.dev или доку React. Обе построены по принципу JAM, а второй на Gatsby в частности.
Стоимость таких проектов от 1 млн рублей.
JAM отлично подходит для контентных сайтов aka корпоративные сайты, например сайт для Роснефти можно спокойно сделать на JAM-стэке. Или для документаций, тут вроде это уже стандарт. Взять тот же web.dev или доку React. Обе построены по принципу JAM, а второй на Gatsby в частности.
Стоимость таких проектов от 1 млн рублей.
Не совсем понял что за проблемы на мобилках, мы точно об одном и том же говорим?
Мобилки все еще слабые, и лишний рендеринг на клиенте неприятно замедляет сайт. Да, можно вылизать, но не проще ли сразу использовать традиционные технологии? Мобильный интернет все еще плохой, дело даже не в скорости, а в стабильности, кусок сайта загрузился до того как вы заехали под мост или перскочили в радиус действия другой вышки и контент, а оставшиеся — нет. Можно конечно настроить чанкинг, заембеддить все что только можно, но не проще ли сразу использовать традиционные технологии?
По-вашему, в чем отличие обычного SPA, SSR и статического сайта с регидрацией, построенном на фреймворке типа Gatsby?
В назначении, в способе поддержки, в потоках данных, во всём. Общее у них только технологичесий стэк и только по причине, что уже есть программисты, которые умеют только это.
JAM отлично подходит для контентных сайтов aka корпоративные сайты, например сайт для Роснефти можно спокойно сделать на JAM-стэке.
В чем преимущество перед кучей готовых решений на базе WP, Drupal и кучи других CMS? Я вижу только излишние усложнения. Если речь о чисто статических сайтах, то в чем преимущество перед генераторами старой школы типа Jekyll, которые будут генерировать страницы которые не будут догенерировать сами себя на клиента?
Взять тот же web.dev или доку React. Обе построены по принципу JAM, а второй на Gatsby в частности.
Так почему бы не сделать документацию генерируемую один раз без догенерации на клиенте? Из плюсов — можно скачивать, быстрее смотреть на слабых устройствах.
Стоимость таких проектов от 1 млн рублей.
И мы вновь возвращаемся к вопросу, зачем нам этот цирк с JAM, если у нас есть нормальные деньги?
В чем преимущество перед кучей готовых решений на базе WP, Drupal и кучи других CMS?
Только безопасность! Никаких ЯП на проде. Сечин вас не покормит колбаской, если там разместят хукеры что нибудь из, естественно, Украины. Эта единственная причина, которая затирает все остальное.
в чем преимущество перед генераторами старой школы типа Jekyll
С таким рылом на собеседование не завалишься. Я тут чувак из старой школы, вы тут все просто хайпуете и даже если я на 100% прав это не является критерием. Новое хуже не значит хуже для всего. Лучше для вас, в качестве опыта, только из-за новизны.
И мы вновь возвращаемся к вопросу, зачем нам этот цирк с JAM, если у нас есть нормальные деньги?
Во первых, 20% вам… как в том анекдоте… а почемы бы и нет раз есть бабки? Чо толку то предыдущий опыт обсусоливать?
Только безопасность! Никаких ЯП на проде. Сечин вас не покормит колбаской, если там разместят хукеры что нибудь из, естественно, Украины. Эта единственная причина, которая затирает все остальное.
Это легко достигается решениями типа Jekyll.
С таким рылом на собеседование не завалишься. Я тут чувак из старой школы, вы тут все просто хайпуете и даже если я на 100% прав это не является критерием. Новое хуже не значит хуже для всего. Лучше для вас, в качестве опыта, только из-за новизны.
Это уже тема взаимоотношений при найме и на работе.
Во первых, 20% вам… как в том анекдоте… а почемы бы и нет раз есть бабки? Чо толку то предыдущий опыт обсусоливать?
Абырвалг?
Это уже тема взаимоотношений при найме и на работе.
Не согласен. Из-за этого и начинают новое пробовать. Чтобы быть актуальным. Никто не хочет не быть в спросе, поэтому такая хрень в js мире, 2mb скриптов на лендинге с формой. Я считаю это явление проявлением сильно недооцененной энергией в индустрии. Капитализьм!
А я знаю, на чём делали этот сайт, ха. Вы недалеко от истины, публичная часть там действительно вся статика.
Положение с cms сейчас такое нмв есть два лидера и они PHP wp и drupal. Есть nodejs коотрый пока не дал ни одной мощной общепризнанной cms. Это парадокс. Так как есть с чего брать пример можно просто портировать. И как бы фронт с бэком говорят на одном языке.
Вопрос нужно ли это бизнесу как бы к разработчикам мало относится. Наверное сайт свой должен быть у всех кто хочет иметь поток клиентов. И на чем там это все работает вопрос самый последний. Почему бы это не был просто html или pdf. Ах да у нас же есть еще разработчики которым не все равно.
А вот без чего точно не обойтись это без своего доменного имени. cvety.narod.ru как то не очень располагает к доверию. И дизайн. На что многие вообще особо не тратятся.
Что касается скорости работы если контент на столько статический что его можно генерировать и деплоить как статику. То по факту тот же эффект будет если просто закэшировать все nginx'ом.
То по факту тот же эффект будет если просто закэшировать все nginx'ом.
только для nginx нужна vps, своя система бекапов бд, файлов и прочее. Если это все есть, вероятно смысла нет. Но поднимать с нуля это мало имеет смысла. А так у тебя просто статика в папке и муллион хостингов, даже бесплатных.
Битрикс забыли, друпал какой-то… сейчас битрикс кормит 80% рынка. Правда там неттакого понятия, как галерея фотографий в середине текста как в wp, лендинги с конструктором сайтов не работают без активной лицензии… поддержка говорит невозможно в рамках текущей реализации, а в комментах исходников написано как и прочая ласковая любовь к недевелоперам)
Ощущение конструктивности критики начинает исчезать уже во втором абзаце, но я не мог пройти мимо
Наверное вы неправильно поняли весь смысл тех же 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 и так далее.
Наверное вы неправильно поняли весь смысл тех же 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 и так далее.
По своей сути они представляют собой фреймворк для создания всего 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 в том виде в котором он задумывался и тот ублюдок, что получился — это настолько разные вещи, что их грешно одним словом называть.
И разумно использовать или 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 на каждый чих
Не обязательно так радикально идти в какую-то сторону.
На данный момент 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 здорового человека.
Если технология появилась — значит она кому-то нужна. Технология не может быть абстрактно плохой — нужно знать, где эту технологию применять. Где-то она подойдёт лучше, а где-то — хуже, вот и все
НЛО прилетело и опубликовало эту надпись здесь
В начале статьи не хватает пары слов, что это вообще за JAM такой. Не все ведь так глубоко в теме, даже если эпизодически следят за миром JS.
Забавное наблюдение. Стоило мне заинтересоваться генераторами статических сайтов в личных целях, сразу кто-то запустил микрокурс по Hugo, у ютуберов, на которых я давно подписан, появились видео на эту тему, вот еще статья на Хабре про JAM-стэк, про который, помоему, вообще никто не вспоминает. И увидел я ее не в каких-то персонализированных подборках для меня, а в телеграм-боте, который ежедневные рандомные статейки дергает.
Я что, в шоу Трумана?
Я что, в шоу Трумана?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JAM-стэк — нищета на стероидах