Процесс отправки формы очень похож на отправку якорного тега, за исключением того, что мы можем:

• выбрать, какой тип запроса мы хотим выполнить (GET или POST)
• прикрепите информацию о пользователе, такую как адрес электронной почты, пароль и т. д., которая будет передана вместе с запросом

Эти два тега являются единственными элементами в чистом HTML, которые могут взаимодействовать с сервером.

А потом появился Javascript.

Изначально JavaScript был создан для добавления простых функций взаимодействия на веб-страницы: проверки форм, получения данных и простой анимации. Но с появлением XMLHttpRequest (позже известного как AJAX) JavaScript превратился в нечто гораздо более мощное и сложное.

Благодаря Javascript разработчики теперь могут инициировать HTTP-запросы без этих двух тегов, используя технологию AJAX. AJAX позволяет извлекать данные с сервера, и хотя XHR может извлекать любые типы данных, включая необработанные HTML-фрагменты, текст или XML, JSON стал фактическим форматом обмена данными.

Это означает, что необходим дополнительный шаг преобразования JSON в HTML с помощью функции, которая визуализирует HTML из JSON. Как показано в примере ниже, мы действуем следующим образом:

• извлечение данных JSON из конечных точек /api/users (часть response => response.json())
• вставка этих данных в HTML-шаблоны (часть const html)
• который затем будет добавлен в DOM (часть document.getElementById())

// Способ JavaScript: преобразование JSON → HTML fetch('/api/users') .then(response => response.json()) .then(users => { const html = users.map(user => `

` ).join(''); document.getElementById('users').innerHTML = html; });

Этот рендеринг подразумевает тесную связь между форматом данных JSON и самой функцией: изменение формата данных JSON может привести к сбою функции рендеринга HTML. Вы уже видите здесь одну потенциальную проблему, и этот момент обычно является точкой трения между фронтенд- и бэкенд-разработчиками: фронтенд-разработчик создаёт пользовательский интерфейс на основе ожидаемого формата JSON, бэкенд-разработчик решает изменить формат, фронтенд-разработчику нужно обновить пользовательский интерфейс, бэкенд-разработчик снова меняет формат, фронтенд-разработчик снова меняет формат и т. д.

По какой-то причине веб-разработчики начали повсеместно использовать JSON и управлять всем с помощью JSON. Это привело к появлению так называемых одностраничных приложений (SPA): в отличие от традиционного HTML 2.0, нам больше не нужно перемещаться между страницами. Весь контент остаётся на одной странице и обновляется с помощью JS и рендеринга пользовательского интерфейса. Именно так работают такие фреймворки, как React, Angular и Vue.js.

«Становящаяся нормой в веб-разработке — создание одностраничных приложений на React с серверным рендерингом. Два ключевых элемента этой архитектуры:
– Основной пользовательский интерфейс создается и обновляется на JavaScript с использованием React или чего-то подобного.
– Бэкэнд — это API, к которому приложение обращается с запросами.
Эта идея буквально захлестнула интернет. Она началась с нескольких крупных популярных сайтов и распространилась на другие сайты, например, на маркетинговые площадки и блоги.

(Том Макрайт, https://macwright.com/2020/05/10/spa-fatigue)

Большинство современных архитектур одностраничных приложений (SPA) представляют собой «клиентские» приложения, где большая часть работы выполняется на стороне клиента, а бэкенд представляет собой лишь API, возвращающий JSON. Такая структура известна своей быстрой и плавной работой, но действительно ли нам нужна такая сложность каждый раз?

«(…) есть также множество задач, для которых я не вижу конкретных преимуществ использования React. Это, например, блоги, сайты с корзинами покупок, сайты, в основном, с CRUD-запросами и формами».

Усталость от Javascript реальна

«Усталость от Javascript» становится всё громче. Она относится к основным недостаткам разработки SPA:

• Растущая сложность : библиотеки и фреймворки становятся всё более громоздкими и сложными, требуя для управления ими больших команд. Некоторые узкоспециализированные фреймворки также подразумевают, что разработчикам JavaScript приходится специализироваться на одной технологии. Ни один разработчик Python не называл себя «разработчиком Tensorflow Python». Они просто разработчики Python, и переход с TF на Pytorch по-прежнему означает, что вы можете читать и использовать оба.
• Тесная связь : взаимосвязь между API данных и пользовательским интерфейсом создаёт напряжение внутри команд. Критические изменения происходят каждый день, и решить эту проблему невозможно, пока команды используют JSON в качестве интерфейса обмена данными.
• Распространение фреймворков : количество фреймворков продолжает расти, что приводит к реальному ощущению «усталости» среди разработчиков JS.
• Избыточная инженерия : в 90% случаев вам не нужны фреймворки с большим объёмом JS. А в некоторых случаях (например, для приложений с большим объёмом контента) это даже плохая идея.

За исключением высокоинтерактивных/совместных пользовательских интерфейсов, простого HTML с многостраничными приложениями часто бывает достаточно.

Так что же такое HTMX?

HTMX — это очень лёгкая JS-библиотека (14 КБ), предлагающая HTML-ориентированный подход к созданию динамических веб-приложений. Она расширяет возможности HTML, позволяя любому элементу отправлять AJAX-запросы и обновлять любую часть DOM. В отличие от JS-фреймворков, которые выполняют всю рендеринг на стороне клиента, сервер выполняет основную работу, возвращая HTML-фрагменты для вставки в DOM. Это также означает, что если вы уже знакомы с шаблонизаторами и HTML, обучение будет гораздо проще по сравнению с изучением React или Angular.

Вместо отказа от гипермедиа в пользу JSON API, HTMX расширяет возможности HTML за счет следующих возможностей: