У меня в ленте Mastodon уже третий день холиварили про HTMX 4 — мол, “зачем этот ретроград, если у нас есть AI агенты, генерирующие React-код”. Но когда я открыл официальный анонс, то понял, что тут всё сложнее.
HTMX — это не про “мы ненавидим JavaScript”, а про “давайте не будем делать SPA там, где хватит SSR с щепоткой динамики”. И в этом свете новый релиз выглядит логичным апдейтом, а не попыткой прыгнуть выше головы.
Что поменялось в HTMX 4
Основная философия осталась прежней: пишем декларативные атрибуты в HTML, а библиотека под капотом делает fetch-запросы и подставляет ответ в DOM. Но теперь это работает более предсказуемо:
- Полный переход на Fetch API вместо XMLHttpRequest — наконец-то нормальная работа с streaming-ответами.
- Явное наследование атрибутов через
:inherited— больше никаких “магических” пробросов поведения от родителя к детям. - Новые имена событий по схеме
htmx:phase:action— теперь в логах понятно, на каком этапе что сломалось.
Раньше можно было случайно получить inheritance:
<div hx-confirm="Удалить?">
<button hx-delete="/item/1">Delete</button>
</div>
Теперь нужно явно указать:
<div hx-confirm:inherited="Удалить?">
<button hx-delete="/item/1">Delete</button>
</div>
Почему это важно в эпоху AI
Когда я даю ChatGPT задачу “сделать форму с валидацией”, он выдаёт что-то такое:
function Form() {
const [errors, setErrors] = useState({});
const handleSubmit = async (e) => {
e.preventDefault();
const res = await fetch('/api/form', { /* ... */ });
if (res.status === 422) {
setErrors(await res.json());
}
};
return (
<form onSubmit={handleSubmit}>
{/* 50 строк контролов и условий */}
</form>
);
}
HTMX предлагает альтернативу:
<form hx-post="/api/form" hx-target="#form-result">
<input name="email" />
<div id="form-result"></div>
<button>Submit</button>
</form>
Сервер при 422 просто возвращает HTML с ошибками, который встаёт в #form-result. Никакого ручного управления состоянием.
Кому сейчас нужен HTMX
- Легаси-проекты, где SSR уже есть, но хочется добавить немного динамики без перехода на SPA.
- Микросервисы админок — когда нужно быстро накидать UI для внутреннего инструмента.
- Команды с бэкенд-экспертизой — если у вас сильные Ruby/Python/PHP-разработчики, но не хватает React-спецов.
При этом HTMX 4 не пытается конкурировать с Next.js или Svelte. Это инструмент для других сценариев — там, где важна простота и долгосрочная поддерживаемость.
Подводные камни
- Morph-swap (обновление DOM без потери состояния) жрёт CPU на больших страницах.
- Ручное обновление URL — если вам нужен сложный роутинг, проще взять традиционный фреймворк.
- Отсутствие типизации — TypeScript-разработчики будут недовольны.
Но главный вопрос не в возможностях библиотеки, а в том, насколько ваш кейс соответствует её идеологии. Если вы строите интерактивное веб-приложение уровня Figma — HTMX не ваш выбор. Но если вам нужно “оживить” традиционный SSR-сайт — возможно, это то, что вы искали.
Лично я постепенно ввожу HTMX в старом ларавель-проекте, где React казался избыточным. Пока что впечатления положительные — особенно в связке с Alpine.js для локального состояния. AI-ассистенты справляются с такой код-базой лучше, чем с переусложнёнными React-компонентами.
А вы пробовали HTMX в продакшене? Или считаете, что в 2026 году это уже анахронизм?