Значения термина Jamstack

Разработчики создавали статические сайты задолго до того, как появился термин Jamstack. Это был простой способ для разработчиков разместить свой блог или документацию с открытым исходным кодом на страницах GitHub, он же был наиболее распространенным вариантом использования таких сайтов. Некоторые энтузиасты продвигали более крупные коммерческие проекты на статических сайтах, но это, конечно, было не так распространено, как сегодня.

Статические сайты воспринимались как ограниченная, старая технология из 90-х годов. Зачем компаниям, ориентированным на будущее, использовать этот древний способ создания веб-сайтов?

Двусмысленность термина "статический" невероятно сбивает с толку, особенно людей, не являющихся разработчиками. Статические сайты 90-х - это не то же самое, что современные статические сайты. Существуют новые технологии, которые позволяют по-новому взглянуть на статические сайты:

• JavaScript превратился в мощный язык для создания приложений в браузере. Gmail был запущен в 2004 году и был первым массовым приложением, интенсивно использующим Ajax.
• Генераторы статических сайтов (SSG) принесли множество преимуществ для динамических сайтов, таких как лейауты и отделение контента от кода. Jekyll был первым широко популярным SSG, запущенным в 2008 году.
• CDN раньше были технологией, которую могли себе позволить только крупные компании. Когда в 2008 году был запущен AWS Cloudfront, стало возможно настроить CDN за считанные минуты, а при небольшом масштабе это обходится всего в несколько долларов.
• Рабочие процессы Git и построенные на его основе инструменты CI / CD оставили подверженное ошибкам развертывание через FTP в прошлом.
• Экосистема - растет число автономных инструментов, которые можно разместить на статическом сайте, чтобы включить дополнительные функции, от поиска и e-commerce до баз данных, комментариев и т. д.

Jamstack помог изменить представление людей о статических веб-сайтах. А в 2016 году Мэтт Бильманн создал сам термин Jamstack. Внезапно появилось слово, отражающее преимущества современных статических сайтов без старого статического багажа.

Jamstack вызвал особенно сильный отклик у многих разработчиков WordPress. Приходя из мира сложных API для плагинов и выбора из множества тем, они находили простоту и уровень контроля, которые дает SSG, живительным. Вокруг независимого подхода Jamstack сформировалось сообщество и началось его развитие.

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

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

Это сложная проблема, с которой столкнулось сообщество Jamstack, потому что между первоначальным значением слова «Jamstack» и новым, эволюционировавшим вариантом, описывающим более динамические сценарии использования, очень много точек пересечения. Я сам в смятении, потому что мне нравится идея применения принципов Jamstack к более динамичным подходам. Я даже рассматривал использование термина «Jamstack» для описания статического продукта, а «Jamstack++» - для чего-то более динамического. Но быстро понял, что это, вероятно, создаст больше путаницы.

Мэтт Билманн подтвердил эту мысль, когда Netlify анонсировала технологию DPR:

Для любой технологии самое сложное - не быть простой на старте, а сохранять простоту с течением времени.

Это прекрасно отражает и мои мысли. Приятно знать, что я ничем не ограничен, создавая новый проект с использованием подхода Jamstack. Если мой сайт становится слишком большим или мне нужно динамическое поведение, у меня есть варианты. Без этих вариантов Jamstack можно было бы рассматривать как ограниченную технологию для небольших компаний.

DPR - многообещающая новая технология. Это элегантное решение для снятия неприятного ограничения при предварительном рендеринге больших сайтов. Если у меня сайт на 100 тыс. страниц, пойду ли я на компромисс в виде предварительной сборки подмножества этих страниц и построения остальных по первому запросу, что значительно сократит время сборки? Черт возьми, конечно! Это разумный компромисс.

Я много думал о том, как DPR вписывается в мир Jamstack, в основном потому, что эта технология находится уже на грани возможностей Jamstack.

У Шона Дэвиса есть определение Jamstack, которое мне очень нравится:

Jamstack - это передовая архитектура для атомарного развертывания и отображения предварительно скомпилированных интерфейсных веб-проектов с разделенным кодом.

Это определение перекликается с тем, чем считаю Jamstack лично я. Если мы хотим включить DPR в это определение, нужно его немного доработать:

Jamstack - это передовая архитектура для атомарного развертывания и отображения предварительно скомпилированных (или созданных по запросу веб-страниц, но только если это первый запрос, а затем созданные страницы сохраняются) интерфейсных веб-проектов с разделенным кодом

Официальное определение Jamstack лучше подходит для DPR:

Jamstack - это новая стандартная архитектура для веб. Используя рабочие процессы Git и современные инструменты сборки, предварительно обработанный контент передается в CDN и становится динамическим с помощью API и бессерверных функций.

DPR поставляет контент, либо используя бессерверную функцию, либо как статический файл через CDN, так что технология соответствует определению.

Интересно посмотреть, как определение менялось с течением времени. До конца 2020 года официальное определение Jamstack, размещенное в то время непосредственно на Jamstack.org, было следующим:

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

Технологии развиваются со временем, как и язык, поэтому здорово видеть, как определение меняется, чтобы идти в ногу со временем. Включение слова «бессерверный» в определение, с одной стороны, имеет смысл, поскольку технология становится все более доступной для интерфейсных разработчиков, которые составляют преобладающую аудиторию Jamstack. С другой стороны, это противоречит основным принципам Jamstack: предварительного рендеринга и разделения кода. Нужно ли нам обновлять и эти основные принципы?

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

Забегая вперед, я вижу пять направлений, по которым может пойти развитие Jamstack:

• Jamstack остается в своем первоначальном значении, то есть основывается на пререндеринге и разделении кода. Более динамичные подходы, вдохновленные Jamstack, получают собственные названия.
• Jamstack развивается, а определение и принципы расширяются. В результате значение, вероятно, становится более неоднозначным.
• Jamstack - это название сообщества. Это набор указаний, а не жестких правил.
• Jamstack подбирает статический "багаж", и тогда мы сможем говорить о статических, гибридных и динамических веб-сайтах.
• Jamstack становится настолько популярным, что можно назвать его просто современной веб-разработкой.
  

Существуют сторонники каждого из вариантов, все они тянут Jamstack в разных направлениях, что приводит к путанице и спорам в сообществе. Ясно одно: это сообщество людей глубоко увлечено этим подходом к созданию веб-сайтов. Честно говоря, меня очень радуют инновации, происходящие в этой сфере. Что нам действительно нужно, так это достичь соглашения и выработать путь развития. Плохо это или хорошо, не знаю, но полагаю, что без этого соглашения, мы получим сочетание вариантов 3, 4 и 5.