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

Ищем: как сделать фронтенд легко?

  • npm npx install tailwind nodejs install install react vue install
  • через час дебажим почему vite не резолвит алиасы
  • десятки непонятных конфигов в которых путаются LLMки потому что спецификации меняются оч часто
  • ???
  • сдаёмся

Это не тривиальные инструменты)) Надо +- понимать что происходит внутри билда итд. Возникает вопрос, ради чего мы тратим весь этот mental overhead? Нужны лишь таблички с CRUD операциями💀 Давайте явно посмотрим на путь данных, отраженный в коде:

SQL или ORM → backend сервис → REST handler → JSON → сеть → десериализация → state → props → компонент → HTML

Вот бы как-то что-то упростить) Глобально направления два: убрать часть бэкенда (BaaS) либо убрать часть фронтенда… и сегодняшний пост пропагандирует второе причем в наиболее радикальной форме — вообще отказаться от отдельного фронтенда. Возвращать из эндпоинтов не JSON, а сразу HTML. Путь данных превращается в:

SQL/ORM → бэкенд → HTML

Три звена вместо десяти. Пять этажей инфраструктуры испарились. Лучший фронтенд — это отсутствие фронтенда! Но вот нюанс. Каждое действие — запрос на сервер → белый экран → целая новая страница прилетает с нуля. Нажал “следующая страница” и опять — перезагрузка. Отправил форму — перезагрузка. Открыл профиль — перезагрузка. Всё состояние теряется(( скролл сбрасывается, введённый текст в другом поле исчезает.

Мы с вами наблюдаем классическую MPA (Multi-Page Application) — так работал весь веб до ~2010. И это было ок, пока люди не попробовали Gmail и Google Maps. Оказалось веб может работать как десктопная программа: нажал — результат мгновенно, без мерцания, без потери контекста. Подход назвали SPA — Single Page Application. Загружаем одну страницу, дальше JavaScript рулит всем. Нужны данные — JS тихо спрашивает сервер в фоне, получает JSON, сам обновляет нужный кусок экрана. Страница не перезагружается вообще.

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

Получается что возвращать HTML — просто для разработчика, но убивает UX. Тащить SPA — хорошо для пользователя, но сложный билд и стопка конфигов. А что если можно и то и другое? Серверный HTML, но без перезагрузки страницы?

Встречайте HTMX. Библиотека за авторством Carson Gross — профессора из Montana State University.

(Риторическое отступление: город Бозмен, штат Монтана это ~56 тысяч человек, горы, коровы и один университет. Когда ты не варишься в экосистеме где карьеры строятся на знании очередного фреймворка — проще увидеть что фреймворк был не нужен. Мы, селюки, просто иначе смотрим на вещи.)

Вернемся к HTMX. Основная идея: сервер по-прежнему возвращает HTML, но браузер не перезагружает страницу целиком — подменяет только нужный кусок DOM. По сути это AJAX, но вместо JSON прилетает готовый HTML-фрагмент. Для нас главное что мы получаем ощущение SPA и архитектуру MPA. Я не проводил социальных опросов, но я почти уверен что пользователю глубоко всё равно на то каким именно способом обновляется наше DOM дерево. А нам такой подход позволяет писать меньше кода и меньше думать.

Конкретный пример:

<button hx-get="/users"
        hx-target="#table"
        hx-swap="innerHTML">
  Загрузить
</button>

Переводится на русский язык как:

  • При нажатии на кнопку.
  • Браузер отправляет GET-запрос на /users. (hx-get="/users").
  • Сервер возвращает HTML.
  • Этот HTML вставляется внутрь элемента с id=”table” (hx-target="#table"),
  • полностью заменив его содержимое (hx-swap="innerHTML").

Подключение библиотеки тривиально тем что это так называемый 0-build. Никакого npm, vite, webpack. Один тег в <head>:

<script src="https://unpkg.com/htmx.org@1.9.12"></script>

Это обычный HTML-документ. Стоит ли тут что-то добавлять? Кода сильно меньше…

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

  • Админки, внутренние панели
  • Дашборды
  • MVP в которых важнее показать что продукт работает, а не то как он выглядит

А вот когда точно тащить его не стоит:

  • Сложный клиентский state
  • Реалтайм с тонкой синхронизацией (хотя htmx умеет в SSE)
  • Canvas, графические редакторы
  • Большие SPA с автономной логикой на клиенте
  • Когда фронтенд команда уже существует

Ни один профессиональный фронтендер не захочет поддерживать эту шляпу)) Им это не нужно в резюме, это не industry standard итд

И вот вы спросите… это что получается теперь… для создания любой логики в браузере придётся писать эндпоинт на бэкенде?? и ждать ответа от сервера даже если я захочу скрыть/показать какой-то элемент?? Абсолютная бесполезная руина.

А я вам отвечу, коллеги!!! Обязательно отвечу. Но в следующих постах. А пока я с вашей стороны ТРЕБУЮ лайков и распространения этих знаний. Отправьте этот пост друзьям и заставьте подписаться на этот канал. Здесь говорят правду.