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: `<div>         <button @click="count++">Click!</button>         <div>Clicks: {{ count }}</div>     </div>`, }).mount("#app");

Size: 226 bytes (4KB on disk)

HMPL пример:

document.querySelector("#app").append(   hmpl.compile(     `<div>         <button>Click!</button>         <div>Clicks: {{ "src": "/api/clicks", "after": "click:button" }}</div>     </div>`   )().response );

Size: 206 bytes (4KB on disk)

HTMX пример:

<div>   <button hx-post="/api/increment" hx-target="#counter" hx-swap="outerHTML">Click!</button>   <div id="counter">Clicks: 0</div> </div>

140 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(   `<div>   <form onsubmit="function prevent(e){e.preventDefault();};return prevent(event);" id="form">     <div class="form-example">       <label for="name">Enter your email: </label>       <input type="text" name="email" id="email" required />     </div>     <div class="form-example">       <input type="submit" value="Register!" />     </div>   </form>   <p>Email {     {       "src":"/api/register",       "after":"submit:#form",     }   } successfully registered!</p> </div>` ); 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 пример:

<script src="/path/to/htmx.min.js"></script> <div>   <form hx-post="/api/register" hx-target="#notification" hx-swap="outerHTML">     <div class="form-row">       <label for="name">Enter your email: </label>       <input type="text" name="email" id="email" required />     </div>     <div class="form-row">       <input type="submit" value="Register!" />     </div>   </form>   <p id="notification"></p> </div>

На данном примере чётко видно, что 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


ссылка на оригинал статьи https://habr.com/ru/articles/851042/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *