Рендеринг веб-страниц на стороне сервера, как знают многие читатели, вышел из употребления уже лет 10 как. "Перезагрузка страниц занимает ощутимое время, при этом пользователю не показывается даже спиннер! Что об этом говорят наши UX гайдлайны?" - таким вопросом задавались IT компании, принимая решение немедленно переезжать на single-page application.

Долгие годы никто не решался идти против веяний эпохи, пока лет 5 назад затишье не нарушил популярный веб-фреймворк Phoenix для языка Elixir (курица в капле на моей картинке). Его авторы считали, что обладающая сверхспособностями Erlang VM сумеет развеять предрассудки о якобы тормознутом серверном рендеринге.

Что ж - они не ошиблись: Phoenix Live View получила популярность, и теперь является для поклонников языка Elixir свидетельством преимуществ их рантайма. Сервер с клиентом общаются исключительно по вебсокету, html генерируется на сервере, коэффициент полезной информации в передаваемом трафике близок к 100%. Видимо, у авторов Phoenix - не только вера в возможности рантайма, но ещё и прямые руки.

Возвращение к серверным шаблонам в Python сообществе стало для некоторых неожиданностью - я, конечно, про фреймворк htmx. Я смотрел их демо на DjangoCon - у них обычный сайт на django, они даже вебсокеты используют только в крайнем случае. Сайт, при этом, отзывчивый - перезагрузок страницы не происходит. (Как это работает? А что, так можно было?)

htmx - это вообще говоря, клиентский код - npm пакет. Он расширяет набор атрибутов в html тэгах для добавления логики (так же делают многие js-фреймворки). Каждый компонент - это такая псевдо-форма (иногда - настоящая форма). При определённых событиях, она шлёт на сервер запросы и - частый случай - перезаписывает своё содержимое на то, что пришло в ответе с сервера.

Вот пример простого компонента:

<div hx-target="this" hx-swap="outerHTML">
    <div><label>First Name</label>: Joe</div>
    <div><label>Last Name</label>: Blow</div>
    <div><label>Email</label>: joe@blow.com</div>
    <button hx-get="/contact/1/edit" class="btn btn-primary">
    Click To Edit
    </button>
</div>

Клик на кнопку заменяет поля на редактируемые, причём запрос на сервер, скорее всего, опять вернёт перезаписываемый компонент.

Почему эта магия работает? Потому что обычный reactive фреймворк делает, по сути, то же самое: при определённых событиях он вызывает логику, которая решает, изменится ли его состояние. Эта логика чаще всего предполагает запрос на сервер. А в htmx запрос на сервер делается всегда (и урл этого запроса явно прописан в соответствующем атрибуте).

<button hx-delete="/account">Соцсети не для меня</button>

В клиент-ориентированном фреймворке onclick был бы функцией, но без запроса на сервер всё равно бы не обошлось. А если нет разницы, зачем платить больше?

Ещё один пример: пусть у нас есть большая страничка, которую мы рендерим по серверному шаблону. Пусть она состоит из 5 визуальных компонентов. В результате действий пользователя, 2 компонента "сообразили", что информация в них больше не актуальна, и им нужен апдейт. Что они сделают? Конечно, гет-запрос на свой урл - и обновятся. Как компонент может сообразить, что ему нужен апдейт? По наступлению какого-то события. В htmx есть события на все случаи жизни - в том числе, можно заводить кастомные. Флаг наступления события может установить как предыдущий ответ с сервера - с помощью хедеров, так и нотификация по вебсокету, например.

Несмотря на простоту концепта, кроме htmx - такое впечатление, что никто до этого не додумался. (UPDATE: есть ещё Hotwire, который построен на похожих принципах)

В общем, если Вы сомневаетесь, использовать ли для django-админки SPA или серверные шаблоны - то не сомневайтесь и берите htmx. Если Вы адепт full-stack разработки на Python - тоже. Разделение труда - единственный весомый контраргумент для меня: серверные разработчики обычно не очень разбираются в вёрстке, вне зависимости от используемого языка.

А теперь - о самом интересном аспекте (на мой взгляд). Интересующиеся мобильной разработкой или читающие блог Яндекса, наверно, видели анонс о выходе в опен-сорс фреймворка divkit. Кроме хабра и ютуба , о нём не очень много можно найти за пределами Яндекса (сам я не из Яндекса). В демо на ютубе девушка несколько раз упоминает фреймворк как "дивный кит". Лично мне название нравится - осталось только кита на логотипе фреймворка изобразить.

divkit - это что-то вроде такого универсального html (точнее, json), который он (divkit) умеет отображать на Android, iOS и на вебе. Таким образом, клиентский код сводится к минимуму, а задача сервера - как раз, формировать этот самый json. Получается, в Яндексе тоже используют рендеринг на сервере - для мобилок! (замахнулись на их нативную природу, не иначе)

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

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