HMPL — лучшая альтернатива HTMX
Всем привет! В данной статье рассмотрим такой javascript модуль как HMPL и как он может заменить HTMX в проекте. Также, рассмотрим в чём их отличия, преимущества и недостатки.
При дальнейшем сравнение двух модулей стоит учесть, что один является языком шаблонов, когда как другой является набором инструментов для работы с HTML, реализуемых через атрибуты и не только.
Начнём с общей концепции для двух модулей.
Концепция сокращения javascript кода путём выноса компонентов пользовательского интерфейса на сервер
Модуль HMPL схож по концепции с HTMX. Мы также можем брать HTML с сервера по API, заменяя тем самым современные фреймворки и библиотеки для создания UI. Возьмём небольшой пример, иллюстрирующий работу HMPL и HTMX, а также такого фреймворка как Vue.js:
Vue.js пример:
createApp({
setup() {
const count = ref(0);
return {
count,
};
},
template: `
Clicks: {{ count }}
`,
}).mount("#app");Size: 226 bytes (4KB on disk)
HMPL пример:
document.querySelector("#app").append(
hmpl.compile(
`
Clicks: {{ "src": "/api/clicks", "after": "click:button" }}
`
)().response
);Size: 206 bytes (4KB on disk)
HTMX пример:
Clicks: 0
128 bytes (4 KB on disk)
На примере простого кликера можно увидеть (с небольшими оговорками по данным на стороне сервера и на стороне клиента, а также по html и js разметке, но не в это главная идея), что мы получаем одинаковый интерфейс, хотя размеры файлов на клиенте будут совершенно разными. В этом как раз и основное преимущество подхода создания уже готового, или шаблонного компонента UI на стороне сервера, чтобы пользователь сайта загружал его быстрее с сохранением результата.
Теперь, вспомним, насколько большие приложения сегодня, ну, или по крайней мере раньше (когда server-side rendering не был ещё настолько популярным), могли получаться при использовании фреймворков и библиотек. Тот же SPA (Single Page Application), генерирует весь контент через javascript, когда в html у нас буквально одна строчка, но в том и прикол, что при 10 килобайтном html мы получаем javascript файл размером в несколько десятков мегабайт. Такой сайт, первом заходе, пользователи могут грузить долго.
К примеру, если потенциальный клиент захочет по быстрому заказать себе цветы, то он не будет ждать 10–15 секунд, пока сайт магазина доставки прогрузится, он перейдёт на другой сайт, где сайт будет грузиться быстрее.
Есть ещё много прикладных примеров работы сайтов, которые могут влиять на воронку продаж. Но, суть в том, что главное — это скорость и удобство интерфейса, а вот тут уже есть различия в подходах. Но, лучше сделать это в отдельной статье. Тут же рассматривается сравнение HMPL и HTMX.
Зачем использовать HMPL и в чём его преимущества перед HTMX?
В данном разделе постараюсь рассказать про несколько основных причин, по которым вы можете выбрать, в некоторых случаях, HMPL вместо HTMX:
При схожей идее сокращения кода, два модуля отличаются в понятиях. В случае HTMX, с одной стороны, мы получаем удобный инструментарий работы с уже существующим DOM, но с другой, всё это происходит через HTML и обновляется буквально в режиме реального времени. Мы с большим трудом, через нетипичиные решения, можем работать более ли менее через javascript, а по сути, работа с javascript почти полностью отсутствует. В случае HMPL, с одной стороны, мы без труда можем работать с javascript; генерировать кастомный RequestInit, создавать тысячи отдельных DOM узлов с той же поддержкой серверного UI, что и на HTMX, но с другой — всё таки работа происходит с кодом, что не всегда удобно, когда хочется создавать проекты быстрее. Возьмём пример кода:
HMPL пример:
import { compile ) from "hmpl-js";
const templateFn = compile(
`
Email {
{
"src":"/api/register",
"after":"submit:#form",
}
} successfully registered!
`
);
const initFn = (ctx) => {
const event = ctx.request.event;
return {
body: new FormData(event.target, event.submitter),
credentials: "same-origin"
};
};
const obj = templateFn(initFn);
wrapper.appendChild(obj.response);HTMX пример:
Email successfully registered!
На данном примере чётко видно, что HTMX — это больше про максимальное убыстрение и укорачивание кода, когда как HMPL — это нечто комбинированное между HTMX и современным фреймворком или библиотекой для создания UI. Можно сказать, что мы получаем несколько похожий результат, но с учётом того, что мы можем кастомизировать запрос на сервер.
Синтаксис HMPL тоже является в своём роде преимуществом, потому что объекты запроса не привязаны к какому-либо тегу. При рендеринге они заменяются на коментарии, которые не засоряют DOM ненужными тегами. Пример синтаксиса:
HMPL полностью построен на fetch заросах, которые ввели как стандарт в 2015 году. HTMX для поддержки IE13 по дефолту использует XMLHTTPRequest, который был введён в 2000 году. Функция fetch позволяет использовать современные возможности javascript в браузерах, такие как AbortController, signals и другое
И, есть ещё достаточное количество преимуществ, по типу отдельного расширения файла .hmpl при работе с вебпаком и другие, но, на мой взгляд, те, которые я выделил, являются наиболее важными. Вебпак конфиг:
Недостатки HMPL
Также, у hmpl есть ряд недостатков, о которых мне бы хотелось рассказать:
У HMPL пока нету поддержки WebSocket, что может усложнить внедерение кода в проект. В HTMX данная поддержка присутствует.
Так как происходит использование fetch, то в некоторых старых версиях браузера вёрстка поддерживаться не будет.
HTMX — это годами протестированная технология, когда как HMPL — это новый модуль.
Вывод
Язык шаблонов HMPL может заменить HTMX в тех случаях, когда требуется гибкая настройка запроса, а также непосредственная работа с узлами через javascript; Если вы, допустим, хотите создать цикл из 1000 одинаковых узлов, и при этом иметь преимущества серверо-ориентированного UI, то он также подойдёт для задачи. Если же цель стоит в полной минимизации работы с javascript, либо же в использовании устоявшегося протестированного модуля и простым подключением к серверу с минимальным количеством HTML кода, то тут HTMX хорош.
Ссылки:
https://hmpl-lang.github.io
https://htmx.org
