HTMX в продакшене: где работает, где разваливается

HTMX появился ещё в 2020, но взрыв интереса случился в 2023-2024 на волне усталости от React. К 2026 эта волна осела до спокойного фона: библиотека стабильна, версия 2.x, поддерживается одной командой во главе с Карсоном Гроссом. У нас в студии три живых проекта на HTMX и ещё пара, где мы рассматривали и отказались. Этим опытом и поделюсь.

Чем HTMX отличается от обычного веба

Идея простая: на любой HTML-элемент вешаем атрибут вроде hx-get="/items", и при клике браузер отправляет запрос. Сервер возвращает не JSON, а готовый кусок HTML, и библиотека вставляет его в DOM в нужное место. То есть рендерим как раньше — на сервере, через шаблоны, — но без полной перезагрузки страницы.

Это не React и не Vue. Состояние живёт на сервере, JavaScript на клиенте минимальный. Чтобы добавить интерактивность, HTMX обычно идут в паре с Alpine.js или гипершрифтом (Hyperscript), а основной язык остаётся серверным — PHP, Python, Go, Ruby.

Кейс №1: личный кабинет для CRM (PHP + HTMX). Работает

Проект на месяц-полтора: личный кабинет клиента сети салонов красоты, поверх существующего PHP-бэкенда. Карточки услуг, история визитов, запись на повторную процедуру. Никакого оффлайна, всё двигается из админки.

HTMX подошёл идеально. Объём фронтового кода вышел ~120 строк JS на весь личный кабинет. Бэк работал по тем же шаблонам, что и админка. Время разработки — на треть меньше, чем если бы делали SPA. Время загрузки страницы — 200ms, потому что нет толстого бандла.

Что особенно сэкономило: формы. На HTMX форма отправляется через hx-post и возвращает обновлённый кусок страницы. Не нужно писать клиентскую валидацию, потом серверную, потом синхронизацию между ними — пишем один раз на сервере.

Кейс №2: дашборд логистики (Python + HTMX). Тут расходилось

Внутренний инструмент для диспетчеров. Карта, список заказов, фильтры, drag-and-drop между статусами, real-time обновления. Изначально хотели сделать на HTMX, чтобы не тащить React.

Через пару недель упёрлись:

• Drag-and-drop — HTMX тут бесполезен. Пришлось писать на чистом JS поверх библиотеки SortableJS, и потом синхронизировать с сервером через hx-put
• Сложные фильтры — несколько checkbox-ов, диапазон дат, поиск. В HTMX каждое изменение фильтра — отдельный запрос. Пользователь кликает по 5 чекбоксам — 5 запросов. Дебаунсить можно, но получается заметная задержка. На React с локальным состоянием это бы работало мгновенно
• Real-time через SSE — HTMX 2.0 поддерживает Server-Sent Events встроенно, и это работает. Но обновление 50+ карточек одновременно через server-rendered HTML — тяжело и для сервера, и для DOM

В итоге проект ушёл на смешанную архитектуру: HTMX для форм и навигации, React-островки для карты и списка с фильтрами. Получилось рабочее, но Frankenstein. На «чистом HTMX» этот кейс не вытянули бы.

Кейс №3: лендинг с конструктором заказа (Go + HTMX). Идеально

Сервис проката оборудования: пользователь выбирает товары, дни, доставку, считается цена. Весь интерактив — выбрать вариант, добавить позицию, изменить количество. Никакого state-а, который бы переживал перезагрузку.

HTMX закрыл всё. Серверный код ~600 строк на Go, фронт ~30 строк JS (только для маленьких UX-улучшений вроде автофокуса). TTFB меньше 100ms, потому что сервер просто рендерит шаблон. SEO работает из коробки — каждая страница это HTML, который видит и пользователь, и Яндекс/Google.

Когда HTMX уместен

• Админки, личные кабинеты, дашборды с табличными данными
• Лендинги с формой и пошаговым выбором
• CMS-like инструменты, где много форм и мало drag-and-drop
• Внутренние тулзы для команд до 50 человек, где скорость разработки важнее «вау»
• Проекты, где SEO критичен и редеплой бандла нежелателен

Когда стенка

• Сложный клиентский state, который меняется без обращений к серверу
• Высокоинтерактивные UI: drag-and-drop, редакторы, графика
• Оффлайн-first приложения, PWA с локальной БД
• Real-time с десятками одновременных обновлений
• Проекты, где фронтенд-команда сильнее бэкенд-команды и хочет работать в JS-экосистеме

Чему мы научились

Главный урок: HTMX не «новая Реакт-парадигма», это возврат к серверному рендерингу с минимальным JS-обвесом. Если ваш бэк уже хороший — выигрыш огромный. Если бэк слабый или его команда не любит сервер-сайд — будет больно.

Второй урок: не пытайтесь делать на HTMX всё. Смешанная архитектура (HTMX + Alpine + React-островки в сложных местах) на практике работает лучше, чем чистый HTMX, втыкаемый в задачи, на которые он не рассчитан.

Третий: команда. HTMX любят те, кто помнит PHP-шаблоны и серверный рендеринг 2010-х. Молодые фронтендеры, выросшие на React, часто пишут на HTMX как на «недо-React» и портят архитектуру. Если вы заходите в HTMX-проект, заложите неделю на смену образа мышления.

Прогноз на конец 2026

HTMX не станет «новым стандартом», и его никто и не позиционирует так. Это нишевый инструмент, который растёт примерно на 30-40% в год по упоминаниям в job postings и npm-зависимостях, и удобно ложится в проекты определённой формы. Хайп прошёл, осталась тихая работающая технология. Это, кажется, лучший возможный исход для нового веб-фреймворка.