Комментарии 15
В результате минимизируются ресурсы, затрачиваемые на веб-разработку.
А ресурсы, потребляемые такой системой, не минимизируются?
Вот везде, везде говорят про оптимизацию трудозатрат разработчика и очень редко про оптимизацию результирующего кода.
Мне кажется тут можно долго приводить полярные примеры, но в среднем, нормально написанный статичный сайт как минимум проще отдавать серверу. Со стороны клиента, когда нужно открыть одну-две страницы, нагрузка также будет меньше, чем при загрузке монолитной spa.
ИМХО: Нормально написанные статичные сайты кончились когда к любой страничке клиенту стало модно тащить сотню-другую килобайт яваскрипта, слепленный для всех систем/хуков/разрешений css, а потом все это рендерить через кучи вложенных элементов с десятками классов каждому. Ах да, еще нужно слушать каждое нажатие клавиши и движение мыши…
Вот и получаем ФБ, хабр или любой из сайтов майкрософта где можно повесится от обилия "упрощений" где сначала страдает сервер, потом сеть, а потом и сам клиент.
В моём понимании это не про статику. На статичном сайте может быть хоть десяток счетчиков, при желании можно ее и на react/vue/angular написать. Статичный он в первую очередь потому, что данные необходимые для отображения основного контента страницы находятся в файлах, а не запрашиваются через 17 рест запросов у трех разных бэкендов. Возможно мы про разное, я в первую очередь подразумеваю подходы типа hygo/jekyll
Я не совсем про конкретику, а про общее поле. Сайты стали перегруженные, и все новые подходы не дают простоты ни для разраба ни для клиента. Редко когда встретишь чистый html + сss. Чаще всего я вижу пару десяток обращений для всяких скриптов и хранение контента в JSON и сбор его на клиенте это уже считается нормой, но серверу легче, да, он не делает 1 запрос к БД для получения кешированной статической страницы в чистом html.
Касательно вуе/ангуляра/реакта и статики на них — все равно у нас остается тонна JS + CSS, которые будут слеплены в один пельмень лежавший в холодильнике в +10. Без них сейчас ни одна страница не обходится. Туда-же можно закинуть jekyll — мы избавились от обращения к БД, но добавили лишнего рендеринга клиенту.
PS: Можете рассматривать как скрип старого быдлокодера делающего в своей жизни только простенькие сайты.
Хочу добавить ко всему выше сказанному, что при богатом опытемверстки и скромном js. Мне было крайне интересно разобраться с keystonejs + nextjs + graphql, а так же познакомиться с vercel, docker… и еще кучкой всего интересного. Для решения банальной задачи(сайт каталог). На данный момент возвращаться к WordPress и.т. д не вижу никакого смысла. Это же оказывается так просто описать контент по типам и вывести все так как тебе угодно. Я был в восторге.
В WP есть возможность определить типы данных, а для удобного навешивания дополнительных полей можно взять всего один плагин — ACF. REST API там также есть из коробки.
Я встречал проекты где WP использовался в качестве Headless-CMS ;)
Также есть очень интересная Headless CMS — Cockpit
Handless CMS это любая CMS, которая имеет админку и только API для доступа к данным, она не занимается отображением сайта в классическом понимании. API такой CMS обычно REST. Все остальное это уже приплел маркетинг.
На самом деле изначально этот подход очень хороший, но известные CMS захотели быть в тренде и решили что они теперь тоже будут Handless CMS, т.к. у них тоже есть API. С технической точки зрения вроде даже верно, но идея Handless CMS исходила из того, чтобы сделать эти CMS-ки более легковесными и чтобы они не становились центром всей архитектуры, а были лишь небольшим сервисом.
2020 год, давайте изобретём CMS и MVC заново)
Что такое Headless CMS и почему за ними будущее