Почему не HTMX
Сегодня я, наконец, отвечу на этот вопрос.
(Внимание, спойлер: мне он не нравится).
Оглавление
- Что такое HTMX
- Мотивы
- Небольшой след
- Привязка к поставщику
- Доступность
- Верные вопросы
- Если не HTMX, то что
Что такое HTMX
HTMX предоставляет атрибуты, которые можно использовать для декларативного написания интерактивных HTML-компонентов в разметке, а не отдельно в JavaScript-файле.
Концептуально мне это нравится! Это большая часть того, что мне нравится в веб-компонентах, и почему я так сильно выступаю за них как за основу устойчивого, сопровождаемого фронтэнда.
Но в реализации, я думаю, HTMX сильно отстаёт.
У него те же проблемы, что и у других фреймворков: большой след, привязанность к поставщику и, похоже, никакого фокуса на доступности.
Мотивы
На сайте HTMX перечислены четыре "мотивации" проекта…
- Почему только
<a>
и<form>
могут выполнять HTTP-запросы?- Почему их должны вызывать только события
click
иsubmit
?- Почему должны быть доступны только методы
GET
иPOST
?- Почему вы должны иметь возможность заменять только весь экран?
Снимая эти условные ограничения, htmx завершает HTML как гипертекст.
Давайте обсудим эти вопросы, а также мои комментарии по поводу следа, привязки и доступности.
Небольшой след
На сайте HTMX говорится…
htmx маленький
Но, честно говоря, это неправда.
В то время как минифицированная и сжатая gzip версия составляет 15,7 Кб, реальный несжатый скрипт — 47,8. Меньше, чем у React, конечно, но не "маленький", на мой взгляд.
Preact весит менее 12 кб без gzip сжатия!
И за этот размер и абстракцию вы получаете то, что, скорее всего, не будете использовать. Это проблема Швейцарского Армейского Ножа, о которой я уже говорил.
Привязка к поставщику
Для меня это "большая проблема". HTMX использует синтаксис hx-*
для своих разнообразных атрибутов…
<button hx-post="/clicked"
hx-trigger="click"
hx-target="#parent-div"
hx-swap="outerHTML"
>
Click Me!
</button>
Это означает, что если однажды вы начнёте использовать HTMX, то вам придётся многое переписать, если вы захотите от него отказаться.
Конечно, это справедливо для любого скрипта или библиотеки! Но использование небольших, более узконаправленных веб-компонентов для выполнения тех же задач означает, что вы переносите или обновляете один компонент, не завися от более крупной библиотеки.
А если вы хотите, чтобы кнопка выполняла POST-запрос, как в примере с HTMX, вы можете обернуть её в форму и получить осмысленный HTML с серверным фолбэком!
<!-- Альтернативный веб-компонент -->
<ajax-form target="#parent-div" swap>
<form action="/clicked" method="post">
<button>Activate Me</button>
</form>
</dynamic-button>
Доступность
В документации есть такие примеры, как…
<div hx-get="/clicked" hx-trigger="click[ctrlKey]">
Control Click Me
</div>
Этот div
реагирует на событие click
. Но div
не фокусируется и не указывает пользователям программы чтения с экрана на то, что он интерактивен.
На домашней странице HTMX спрашивается…
- Почему только
<a>
и<form>
могут выполнять HTTP-запросы?- Почему только события
click
&submit
должны вызывать их?
Некоторые из этих вещей — унаследованные архитектурные решения, но часть из них обусловлена доступностью и тем, как люди и машины взаимодействуют друг с другом.
Вы не можете игнорировать эти вещи только потому, что они неудобны.
Снимая эти условные ограничения, htmx завершает HTML как гипертекст.
Это условность? Возможно, в некоторых случаях. Но это всё равно важно.
Верные вопросы
HTMX задаёт несколько верных вопросов…
- Почему должны быть доступны только методы
GET
иPOST
?- Почему вы должны иметь возможность заменять только весь экран?
Честно говоря, я бы хотел, чтобы элементам form
добавили поддержку методов PUT
и DELETE
.
Критично ли это? Нет! Вы всё равно можете делать всё то же самое, что делали бы с этими методами без них. Тем не менее это немного улучшило бы взаимодействие с API.
И нативный для браузера способ реализации архитектуры островов может быть интересным. Я не уверен, что это критическая необходимость для платформы, но думаю, что это потенциально полезное дополнение.
Если не HTMX, то что
Веб-компоненты.
Вы можете делать всё то же самое, но в небольшом, модульном и переносном виде. Веб-компоненты отлично работают сами по себе, а также могут сочетаться с другими библиотеками по вашему выбору.