Современная ситуация с разработкой веб-приложений
Сегодня пользователи ожидают от веб-приложений плавной работы без перезагрузок страниц. К сожалению, эти ожидания обычно реализуются в виде одностраничных приложений (single-page application, SPA), использующих библиотеки и фреймворки наподобие React и Angular. Эти фреймворки очень специализированы и с ними может быть трудно работать.
Новый подход заключается в том, чтобы вернуть возможность реализации этого UX в руки инженеров, разрабатывавших веб-сайты до возникновения безумия SPA, используя готовые наборы инструментов и знания. HTMX — лучший пример такого подхода из тех, что я видел.
Цена SPA
SPA позволяют инженерам создавать отличные веб-приложения, но за это приходится платить свою цену:
- Сильный рост сложности с точки зрения архитектуры и процесса разработки. Нужно много времени тратить на изучение фреймворков.
- Инструментарий для сборки и упаковки кода постоянно меняется.
- Управление состоянием и в клиенте, и на сервере.
- Фреймворки поверх библиотек поверх других библиотек поверх полифилов. Разработчики React даже рекомендуют использовать поверх их технологии фреймворк:
React — это библиотека. Она позволяет соединять компоненты друг с другом, но не определяет способы маршрутизации и получения данных. Для сборки целого приложения на React мы рекомендуем фулстек-фреймворк React.
- По своей природе толстый клиент требует исполнения большого объёма JavaScript. Если вы работаете с современным оборудованием, то это приемлемо, но этими приложениями невозможно будет пользоваться на старом оборудовании или в местах с ненадёжным подключением к Интернету.
- Очень легко реализовать SPA некорректно, поэтому необходимо использовать правильный подход с хуками, чтобы производительность на стороне клиента не была ужасной.
- Некоторые реализации SPA отказываются от progressive enhancement (примечательным исключением является Remix). Поэтому для большинства SPA обязательно нужно включить JavaScript.
- Если вы хотите использовать не JavaScript или TypeScript, то придётся пойти по опасному пути транспиляции.
- Во многих компаниях это привело к созданию больших отделов бэкенда и фронтента, несущих за собой высокие затраты на координацию.
До появления SPA разработчики выбирали удобный им язык и передавали HTML в браузер пользователя в ответ на HTTP-запросы. Это нормально, но обеспечивает низкий уровень интерактивности, а в некоторых случаях создаёт раздражающий UI, особенно из-за того, что при каждом взаимодействии страница полностью перезагружается. Чтобы обойти эту проблему, разработчики обычно добавляли JS по своему вкусу.
Хотя такой подход кому-то кажется устаревшим, именно им вдохновлялись разработчики статьи о REST, особенно что касается гипермедиа. Гипермедийный подход к созданию веб-сайтов привёл к невероятному успеху WWW.
▍ Гипермедиа?
Ниже показан ответ от API данных, не гипермедиа.
{
"sort": "12-34-56",
"number": "87654321",
"balance": "123.45"
}Чтобы сделать эти данные полезными в SPA, клиентский код должен понимать структуру и решить, что рендерить, и какие элементы управления сделать доступными.
REST описывает использование гипермедиа. Гипермедиа — это когда твои ответы не просто являются сырыми данными, а полезной нагрузкой, описывающей медиа (вспомните тэги HTML наподобие
<p>, заголовки и так далее) и способ манипуляций с ними (например, form, input).Пример гипермедиа — это сервер, возвращающий HTML с описанием банковского счёта с какими-нибудь видами элементов управления для работы с ресурсом. Теперь сервер отвечает за описание способа рендеринга данных (с небольшим вмешательством CSS) и того, какие элементы управления должны отображаться.
<dl>
<dt>Sort</dt><dd>12-34-56</dd>
<dt>Number</dt><dd>87654321</dd>
<dt>Balance</dt><dd>£123.45</dd>
</dl>
<form method="POST" action="/transfer-funds">
<label>Amount <input type="text" /></label>
<!-- etc -->
<input type="submit" value="Do transfer" />
</form>Такой подход означает, что у нас есть один универсальный клиент — веб-браузер; он понимает, как отображать гипермедиа-ответы и позволяет пользователю работать с «элементами управления» для выполнения нужных действий.
Карсон Гросс в подкасте Go Time:
… когда только появились браузеры, идея одного универсального сетевого клиента, общающегося с любым приложением через эту безумную технологию гипермедиа, была абсолютно новаторской. Такой она и остаётся.
Если бы вы сказали кому-нибудь в 1980 году «знаешь, ты сможешь использовать одно и то же приложение для доступа к новостям, банковскому счёту, календарю, штуке под названием „электронная почта“ и многому другому», то на тебя бы посмотрели искоса и не поняли, о чём ты говоришь, если собеседник не был членом одной из мелких исследовательских групп, изучавших подобные вещи.
До появления World Wide Web, до веб-браузеров превалирующими паттернами приложений были уникальные и часто «толстые» клиенты.
Хотя создающие SPA люди говорят об использовании «RESTful» API для реализации обмена данными в их коде на стороне клиента, в своей чистейшей форме такой подход не является RESTful, потому что в нём не применяется гипермедиа.
Вместо одного универсального клиента куча разработчиков создаёт уникальные клиенты, которые должны понимать, какие сырые данные они получают от веб-серверов, а затем рендерить элементы управления согласно этим данным. При таком подходе браузер больше походит на среду исполнения JavaScript, HTML и CSS.
Толстый клиент по определению требует больше усилий и затрат, чем тонкий. Однако «первоначальный» подход с гипермедиа недостаточно хорош для всех современных нужд; элементы управления, с которыми может работать браузер, и то, что он требует полного обновления страницы для их использования, делают такой UX неудобным для многих типов веб-приложений.
▍ HTMX и гипермедиа
В отличие от SPA, HTMX не отказывается от архитектурного подхода REST; он дополняет браузер, расширяя его гипермедиа-возможности и упрощая реализацию функционального клиента без особо большого объёма JavaScript, а то и совсем без него.
Для передачи HTML можно использовать любой язык программирования, как мы и привыкли. Это значит, что мы можем использовать проверенный временем надёжный инструментарий с «истинным подходом RESTful», что существенно упрощает разработку и снижает сложность.
HTMX позволяет проектировать страницы, получающие с сервера фрагменты HTML для обновления страницы пользователя и без необходимости перезагрузки всей страницы.
Мы можем рассмотреть это на практике при помощи примера с классическим приложением TODO.
Clojure HTMX TODO
Во-первых, не стоит волноваться о том, что приложение пишется на Clojure. Я выбрал Clojure ради интереса, но красота такого подхода в том, что можно использовать любой подходящий вам язык, если он отвечает на HTTP-запросы отправкой гипермедиа.
Здесь нет ничего особенного, но приложение ощущается как SPA. Нет никаких полных перезагрузок страницы, всё работает очень плавно, как во всех демо SPA, которые вы могли видеть.
Разница заключается в следующем:
- Я не писал ни строки на JavaScript.
- Я не жульничал, транспилировав Clojure в JavaScript. (См. ClojureScript)
Я создал веб-сервер, отвечающий на HTTP-запросы отправкой гипермедиа.
HTMX добавляет возможность задания расширенного гипермедиа, позволяя аннотировать любой HTML-элемент, чтобы просить браузер делать HTTP-запросы для получения фрагментов HTML, которые помещаются на страницу.
▍ Функция редактирования
Самая удивительная и впечатляющая часть этого демо — функция редактирования. Поле ввода появляется мгновенно, пользователь может отредактировать и страница сразу же обновится. Кажется, как будто для этого требуется много ванильного JS или подход в стиле React, но ниже вы увидите, что всё до абсурда просто.
Давайте начнём с изучения разметки элемента TODO. Ради понятности я вырезал всю разметку, не относящуюся к редактированию.
<li hx-target="closest li">
<form action="/todos/2a5e549c-c07e-4ed5-b7d4-731318987e05"
method="GET">
<button
hx-get="/todos/2a5e549c-c07e-4ed5-b7d4-731318987e05"
hx-swap="outerHTML">
????</button>
</form>
</li>Возможно, вам покажется, что тут много кода, но на самом деле в первую очередь нужно сосредоточиться на понимании функции редактирования:
- Атрибут
hx-targetтега<li>говорит браузеру: «Когда ты получишь фрагмент для рендеринга, я хочу, чтобы ты заменил этот элемент». Дочерние элементы наследуют этот атрибут, поэтому для любых действий HTMX внутри этого тега<li>возвращаемыйHTMLбудет заменять содержимое<li>. -
hx-getна кнопке редактирования означает, что при нажатии на неёHTMXприкажет браузеру выполнитьHTTP GETкURLи получить новую разметку для рендеринга в<li>вместо того, что там находится. - Форма в этом примере необязательна, однако она позволяет нам поддерживать функциональность для пользователей с отключенным JavaScript, о которых мы поговорим ниже.
Когда начинаешь работать с HTMX, проще всего разобраться в происходящем, изучив вкладку Network в инструментах разработчика в браузере.
Когда пользователь нажимает на кнопку редактирования, браузер выполняет
HTTP GET к указанному ресурсу todo. Сервер возвращает гипермедиа-ответ, который является описанием этого ресурса с элементами управления гипермедиа.<form action="/todos/45850279-bf54-4e2e-a95c-c8c25866a744/edit"
hx-patch="/todos/45850279-bf54-4e2e-a95c-c8c25866a744"
hx-swap="outerHTML" method="POST">
<input name="done" type="hidden" value="false"/>
<input name="name" type="text" value="Learn Rust"/>
<input type="submit"/>
</form>Затем HTMX берёт этот HTML и заменяет им то, что мы определили как
hx-target. Поэтому пользователь теперь видит эти элементы управления гипермедиа, позволяющие ему манипулировать ресурсом, а не строку, которую мы видели на изображении выше.Можно заметить, что форма имеет атрибут
hx-patch, то есть при её отправке браузер отправит PATCH с данными для обновления ресурса. Затем сервер отвечает обновлённым элементом для рендеринга.Применение в вебе
В HTMX есть гораздо больше всего, но это сама суть подхода, который полностью идентичен подходу, который использовался на веб-сайтах до того, как стали популярны SPA.
- Пользователь переходит на
URL - Сервер возвращает гипермедиа (HTML), то есть контент с элементами управления.
- Браузер рендерит гипермедиа
- Пользователи могут использовать элементы управления для выполнения работы, что приводит к отправке HTTP-запроса из браузера на сервер.
- Сервер выполняет бизнес-логику, а затем возвращает новое гипермедиа, с которым может работать пользователь.
Всё, что делает HTMX — это позволяет браузеру лучше справляться с гипермедиа, давая нам больше вариантов того, что может привести к исполнению HTTP-запроса и позволяя нам обновлять часть страницы, а не перезагружать её полностью.
Благодаря использованию гипермедиа и тому, что мы не относимся к браузеру просто как к среде исполнения JavaScript, мы получаем множество упрощающих жизнь преимуществ:
- На стороне сервера можно использовать любой язык программирования.
- Нам не требуется куча библиотек и другого хлама для поддержки базовых возможностей веб-разработки.
- Кэширования
- Дружелюбности к SEO
- Ожидаемой работы кнопки «назад»
- И так далее
- Очень легко поддерживать пользователей, которые не могут или не желают использовать JavaScript
Последний пункт критически важен для меня и моего работодателя. Я работаю в компании, создающей продукты, используемые по всему миру, и наш контент и инструменты должны подходить для максимального количества людей. Мы не можем ограничивать возможности людей неудачными техническими решениями.
Именно поэтому мы пользуемся progressive enhancement.
Progressive enhancement — это философия проектирования, предоставляющая обязательные контент и функциональность максимально возможному количеству пользователей, а максимальную функциональность давая только тем пользователям, которые используют современные браузеры, способные выполнять весь нужный код.
Все функции приложения TODO (поиск, добавление, редактирование, удаление, пометка пункта как завершённого) работают с отключенным JavaScript. HTMX не делает всего этого «бесплатно», усилия разработчиков всё равно требуются, но благодаря такому подходу задачи решаются гораздо проще. Чтобы написать приложение, мне понадобилось около часа, и при этом не потребовалось существенных изменений.
▍ Как эта система поддерживает отсутствие JavaScript
Когда браузер отправляет запрос, заданный HTMX, он добавляет заголовок
HX-Request: true; для сервера это означает, что мы можем отправлять разные ответы; это во многом похоже на content negotiation.Стандартная структура для обработчика выглядит примерно так:
parseAndValidateRequest()
myBusinessLogic()
если запрос в htmx то
вернуть фрагмент гипермедиа
иначе
вернуть полную страницу
конецВот конкретный пример HTTP-обработчика для работы с новым TODO:
(defn handle-new-todo [get-todos, add-todo]
(fn [req] (let [new-todo (-> req :params :todo-name)]
(add-todo new-todo)
(htmx-or-vanilla req
(view/todos-fragment (get-todos))
(redirect "/todos")))))Третья строка «бизнес-логики» вызывает функцию для добавления нового TODO в наш список.
Четвёртая строка — это некий код для определения того, с каким типом запроса мы имеем дело, а последующие строки или рендерят фрагмент для возврата, или перенаправляют на страницу.
По моему опыту разработки гипермедия-приложений с HTMX, такой паттерн встречается очень часто. По самой природе такой архитектуры, если мы можем поддерживать обновление части страницы, то возвращаем фрагмент; в противном случае браузер обязан выполнить полное обновление страницы, то есть или выполнить перенаправление, или просто вернуть весь HTML целиком.
Шаблонизация HTML на сервере — это невероятно развитая область. Существует множество вариантов и превосходных руководств по тому, как структурировать и добавлять для них автоматизированные тесты. Важно то, что все они предоставляют возможности композитинга, поэтому можно чрезвычайно просто вернуть фрагмент или целую страницу.
Почему же это будущее?
Конечно, я не могу предсказать будущее, но я считаю, что HTMX (или нечто подобное) в ближайшем будущем станет всё более популярным подходом к созданию веб-приложений.
Недавно было заявлено о том, что HTMX стал одним из двадцати проектов в GitHub Accelerator.
▍ Он делает «фронтенд» более доступным
Изучение React само по себе является целой отраслью знаний. Он быстро развивается и меняется, и нужно многому учиться. Я симпатизирую разработчикам, которые когда-то делали полнофункциональные приложения и которых современная фронтенд-разработка заставила стать «бэкенд»-разработчиками.
Я создавал на React довольно сложные системы, и хотя в чём-то это было довольно интересно, объём необходимых знаний для большинства приложений несопоставим. У React есть своя ниша, но для многих веб-приложений он чрезмерно мощен.
Подход с гипермедиа на основе HTMX несложно понять, особенно если ты знаком с фундаментом REST (который у «бэкенд»-разработчиков должен быть). Он позволяет создавать функциональные веб-сайты более широкой аудитории разработчиков, не желающих изучать работу с фреймворком и постоянно гнаться за его постоянно меняющейся структурой.
▍ Меньше возни
Даже спустя более десятка лет после появления React он не кажется устоявшимся и зрелым. Несколько лет назад хуки стали новинкой, которой должен был научиться каждый и переписать на них все компоненты. А в последние полгода в моей ленте Twitter куча споров и туториалов о новых "RSC" — react server component. Неописуемое удовольствие.
Работа с HTMX позволила мне использовать то, что я изучил 15-20 лет назад и что до сих пор работает, как мой сайт. Этот подход понятен и хорошо задокументирован, а накопленный опыт не зависит от языков программирования и фреймворков.
Я без малейших проблем создал пример приложения на Go и на Clojure, а ведь в Clojure я совершенный новичок. Как только вы разберётесь с основным синтаксисом языка и узнаете, как отвечать на HTTP-запросы отправкой гипермедиа, то сможете приступить к работе; и можно использовать рекомендации по архитектуре и дизайну без необходимости снова и снова изучать новые подходы.
Какой объём навыков вам удастся перенести из React на работу с Angular? Легко ли перейти с одного фреймворка react на другой? Что вы подумаете, когда классовые компоненты станут «плохими» и от вас потребуют использовать вместо них хуки?
▍ Дешевле
Он просто требует меньше усилий!
Hotwire — это библиотека, имеющая схожие с HTMX цели, развитием которой занимается сообщество Ruby on Rails. DHH твитнул следующее.
Hotwiring Rails выражает желание подарить одинокому фулстек-разработчику все инструменты, которые необходимы ему для создания нового Basecamp, GitHub или Shopify. Того, что может создать команда из десятков или сотен людей при наличии миллионов долларов венчурного капитала. Технологии Возрождения для людей эпохи Возрождения.
Поэтому так печально слышать, когда «фулстек» считают уничижительным термином или невыполнимой миссией. Считается, что для создания крутых проектов мы ДОЛЖНЫ быть разрозненным коллективом из фронтенда, бэкенда, сервисов и любых других групп специалистов. А это совершенно не так.
Без когнитивной перегрузки обучения огромному фреймворку из мира SPA и сложностей создания толстого клиента вполне можно создавать функциональные веб-приложения усилиями гораздо меньшего количества разработчиков.
▍ Повышенная надёжность
Как говорилось ранее, при использовании подхода с гипермедиа создавать веб-приложения, работающие без JavaScript, достаточно просто.
Важно помнить, что браузер находится в ненадёжном окружении, поэтому при создании SPA необходимо обеспечивать невероятный уровень защиты. Приходится реализовывать большую часть бизнес-логики на стороне клиента; но из-за архитектуры ту же самую логику необходимо воссоздать и на сервере.
Допустим, нам нужно правило, гласящее, что после того, как список помечен выполненным, его нельзя было редактировать. В мире SPA мы бы взяли сырой JSON и вынуждены были создавать бизнес-логику, определяющую, нужно ли рендерить кнопку редактирования в клиентском коде. Однако, если бы мы хотели, чтобы пользователь каким-то образом не обошёл это правило, ту же защиту нужно было реализовать на сервере. Это кажется несерьёзным и простым, но повышает сложность, а вероятность несогласованности повышается.
При подходе с гипермедиа браузер «туп» и ему не нужно об этом волноваться. Разработчик может реализовать это правило в одном месте — на сервере.
▍ Снижение сложности координации
Сложность SPA привела к созданию больших отделов бэкенда и фронтенда, что привносит дополнительные затраты.
Типичное разделение команды на фронтенд и бэкенд приводит к большой неэффективности командной работы из-за передачи ответственности и недопонимания, что усложняет выполнение работы. Многие ошибочно считают самой критически важной метрикой личную эффективность, используя её как оправдание такому разделению. Они видят, как сливаются вместе множество PR, и прикладывается много усилий, но игнорируют затраты на координацию.
Например, предположим, что вам нужно добавить на страницу новый элемент данных или новую кнопку. Для многих команд это значит необходимость проведения совещаний по согласованию нового API, создание заглушек для команды фронтенда и координирование релизов.
При подходе с гипермедиа эта сложность полностью отсутствует. Если вам нужно добавить на страницу кнопку, координировать усилия не нужно. Не требуется сильно беспокоиться о структуре API. Вы можете менять разметку и контент так, как вам это нужно.
Команды, обменивающиеся данными в JSON, могут быть крайне неустойчивыми без поддержки и всегда требуют затрат на координацию. Вам могут помочь такие инструменты, как consumer-driven contract, но это всего лишь ещё один инструмент, ещё один аспект, в котором нужно разбираться, и ещё один элемент, который может сломаться. При использовании гипермедиа лишняя трата ресурсов, поддержка и сложность управления версиями API по природе своей не является проблемой; вы можете менять разметку, как вам нужно.
При этом я не хочу сказать, что при таком подходе нет места для разделения ролей. Я работал в командах, где разработчики создавали веб-приложение «от и до», но при этом у нас были люди, специализирующиеся на семантической, доступной разметке, помогавшие нам обеспечивать хорошее качество результата. Невероятно удобно, когда для создания веб-сайта вам не приходится обсуждать API и передавать задачи.
▍ Больше возможностей
Рендеринг HTML на сервере — это хорошо исследованный путь. В любом популярном языке программирования и в большинстве нишевых существует множество проверенных практикой и совершенных инструментов и библиотек для генерации HTML на сервере.
Подведём итог
Я призываю разработчиков, стремящихся к снижению затрат и сложности разработки веб-приложений, попробовать HTMX. Если вы отказывались от создания веб-сайтов из-за справедливого мнения о сложности фронтенд-разработки, то HTMX может стать для вас отличным вариантом.
Я не заявляю, что SPA стали излишними; в них по-прежнему существует реальная потребность, когда требуются очень сложные и быстрые взаимодействия, когда требования к проекту не позволяют тратить время на обращение к серверу для получения разметки.
В 2018 году я заявил, что большое количество веб-приложений можно написать с гораздо более простым технологическим подходом, чем SPA. Теперь благодаря технологиям наподобие HTMX моё заявление имеет ещё больший вес. В мире фронтенда разработчики постоянно ждут, что новый фреймворк решит проблемы предыдущего фреймворка, который они используют. Подход с SPA по природе своей более сложен, чем подход с гипермедиа и если наслоение ещё большего количества технологий не может решить проблему, то попробуйте гипермедиа.
Дополнительную информацию можно изучить по ссылкам ниже.
Дополнительное чтение и источники
- Автор HTMX написал превосходную бесплатную книгу с описанием гипермедиа. Её легко читать; возможно, она заставит вас подвергнуть сомнениям свои мысли о том, как правильно создавать веб-приложения. Если вы всегда создавали только SPA, то она обязательна к прочтению.
- HTMX. В частности, раздел с примерами очень хорошо показывает возможности технологии. Эссе тоже написаны качественно.
- Мне повезло быть приглашённым на подкаст GoTime с создателем HTMX Карсоном Гроссом! Хотя этот подкаст посвящён Go, основная часть беседы касалась гипермедиа.
- Версия на Go стала моим приключением в мире HTMX; я создал то самое приложение со списком todo, которое описано в этом посте
- Мы с моим коллегой Ники работали над версией на Clojure
- DHH о Hotwire
- Progressive enhancement
- Пять лет назад я написал статью The Web I Want, в которой жаловался на разрастающиеся затраты на SPA. Первоначальной причиной её написания стало наблюдение за тем, как двухлетний ChromeBook моей подруги тормозил на популярном веб-сайте, который вполне мог быть статичным HTML. В статье я говорю о том, что мне бы хотелось, чтобы больше веб-сайтов придерживалось подхода с гипермедиа, рендерило HTML на сервере и использовало progressive enhancement для повышения удобства. Перечитывая эту статью, я очень порадовался появлению HTMX и подобных ему технологий.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️
Комментарии (102)
gmtd
22.05.2023 13:21+11За что же SPA так...
Чувствуется фрустрации бэкендера, не въехавшего в современный фронт
Simipa
22.05.2023 13:21-1Я сам не с веба вообще, но по общим настроениям в Твиттере и вообще в тусовке, я вижу что от SPA стараются уйти вообще все, теперь современный фронт это Remix и его клоны.
AcckiyGerman
22.05.2023 13:21+2Remix is an edge-first server-side rendering JavaScript framework built on React that allows us to build full-stack web applications thanks to its frontend and server-side capabilities...
Теперь фронтэнд фреймворк лезет еще и на бекенд... звучит как еще один уровень усложнения, вместо решения проблемы по существу, как пытается описываемый HTMX.
illia-ivanou
22.05.2023 13:21+13Чувствуется фрустрации фронтендера, не осознавшего бесполезность большинства современного фронта
rzakirovt
22.05.2023 13:21+3Вводная часть статьи и описание минусов SPA очень неполное. Проблема с SPA в том, что он используется надо-не надо. Для формочек без сложной логики вполне подходит серверный рендеринг, не надо там два раза логику дублировать (фронт-бек).
И идея не нова, в свое время еще баловался pjax, где заменяется только часть html. Правда были проблемы с биндингами к элементам.
В современном вебе можно использовать серверную обработку + vue/react в местах, где это необходимо.
vassabi
22.05.2023 13:21+5когда требования к проекту не позволяют тратить время на обращение к серверу для получения разметки
:)
вспоминается, как мы перенесли логику сжатия (из картинок любого размера в миниатюры 640*480) картинок при загрузке из бека на фронт - так сразу стало веселее.
и ведь это не только на ресурсах сервера отразилось, но и на скорости соединения.
AcckiyGerman
22.05.2023 13:21+1Странно, почему гугл не транскодирует загружаемое видео на фронте... логично же сэкономить на серверах за счёт клиентов?
</Sarkasm>
Я к тому, что требования к проектам могут отличатся.
citius
22.05.2023 13:21-1Я не понял, вы чтобы отобразить у клиента условные 640*480 передаете ему условные 2560*1920, и говорите что это оптимизация?
Или наоборот когда пользователю нужно что-то зааплоадить, превьюшка генерится у него локально? Такой кейс более понятен конечно.
kotan-11
22.05.2023 13:21+6Автор преувеличивает сложность одностраничных приложений. Вот, например, колхозный одностраничник latis.cc на голом JS без использования каких-либо фреймворков. Вся логика одностраничности помещается в 20 срок (функция goTo + updateState).
Не надо на сервере гонять логику UI/UX, пусть он сервает бизнес-логику и модель данных через API и возвращает JSONы.
mvv-rus
22.05.2023 13:21+2Не надо на сервере гонять логику UI/UX, пусть он сервает бизнес-логику и модель данных через API и возвращает JSONы.
Да. Но статья — скорее о том, что не надо в браузере гонять (точнее, дублировать) бизнес-логику. С одной стороны это так. Но с другой — а куда отнести логику проверки введенных пользователем данных? Эта логика имеет двойственную природу: с одной стороны это — часть бизнес-логики, проверяющая пригодность данных для обработки, а с другой — часть логики пользовательского интерфейса, показывающая пользователю его ошибки, желательно — как можно раньше.
laatoo
22.05.2023 13:21+2куда отнести логику проверки введенных пользователем данных
валидация "техническая" - на клиенте, никуда от нее не деться
валидация "доменная"/"смысловая":
а) в сервис, который ходит на бэк с вопросами, и получает ответы
SomethingAvailabilityService.isAvailableAt(...)б) в сервис, который уже получил в каком-то формате constraints от сервера, и сгенерировал правила для проверки (ConstraintBuilder+ConstraintValidator)
kspshnik
22.05.2023 13:21Техническую пригодность (валидность) данных проверяем сразу и онлайн, при вводе, а правильность/пригодность/применимость - уже там, где бизнес-логика.
Например: логин (емейл)/пароль (минимум 6 символов), валидность ввода (введён именно емейл, проверяем регуляркой, введены минимум шесть символов в поле пароля) проверяем на фронте сразу при вводе и сразу показываем ошибку пользователю, удовлетворяющее техническим ограничениям (валидные) данные отправляем на сервер, а там уже проверяем есть ли юзверь в базе и тот ли у него пароль.mvv-rus
22.05.2023 13:21+1Это все так, но…
Формальную правильность данных ("техническую пригодность") все равно придется проверять и на сервере — потому что данные на сервер может передать не только клиент: канал передачи данных на сервер не защищен от посылки на него поддельных запросов.kspshnik
22.05.2023 13:21Да, безусловно. Акцент был на том, что валидация на фронте (проверка технической пригодности и формального соответствия вводимых данных схеме данных на бэке) - это не бизнес-логика, и валидация на фронте *ну никак* не ведёт к протеканию туда бизнес-логики.
NickyX3
22.05.2023 13:21Для валидации такого уровня даже кастом JS на клиенте особо не нужен, это всё валидируется через HTML5 input types + built-in form validation (атрибуты required, minlength, maxlength, min, max, type, pattern)
kspshnik
22.05.2023 13:21Нууу... Онлайн-валидацию (сразу показывая клиенту неверный ввод, до отправки формы) без JS Вы не сделаете.
NickyX3
22.05.2023 13:21Вы точно прочитали про что я написал? HTML5 Input Attributes + built-in form validation через атрибуты не требует НИ СТРОЧКИ JS кода в минимальном виде (да, если вы хотите кастомизировать поведение браузера и сообщения - то тут Validation API все ж понадобится и более того, хорошим тоном даже при валидных для браузера данных и серверной валидации будет обернуть ответ об ошибке через Validation API).
до отправки формы
Не валидная, с точки зрения браузера, форма вообще не отправится.
https://nickyx3.ru/f.html - можете развлечься с отправкой неверных данных
SensDj
22.05.2023 13:21+1а мне нравится uniGUI - страничка выглядит как windows-приложение, и работает так же, да и пишется такой сайт теми же средствами что и приложение (Embarcadero RAD Studio)
Wesha
22.05.2023 13:21+6страничка выглядит как windows-приложение
Ви так говорите, как будто это что-то хорошее...
laatoo
22.05.2023 13:21+44замечательная технология.
а теперь напишите на ней форму брони 4-8 мест в 16 ряду кинотеатра на сеанс с 13:00 до 15:30.
6 место уже продано. при покупке 3+ мест скидка 5%. это постоянный клиент, поэтому ему положен бесплатный попкорн. таймзона браузера - москва, кинотеатр в хабаровске. сервер отвечает 502 через раз.
вот этим занимаются во фронтенде, а не тудушками с гипермедиями
laatoo
22.05.2023 13:21+7Когда пользователь нажимает на кнопку редактирования, браузер выполняет
HTTP GETк указанному ресурсу todo. Сервер возвращает гипермедиа-ответ, который является описанием этого ресурса с элементами управления гипермедиа.и про темную тему не забудьте, в москве еще ночь.
htmx-патчами с сервера весь интерфейс перекрасить надо :)
ris58h
22.05.2023 13:21htmx-патчами с сервера весь интерфейс перекрасить надо :)
Зачем для этого какие-то патчи, если есть
prefers-color-scheme?laatoo
22.05.2023 13:21где-то возможно и так.
а) с prefers-color-scheme по кнопочке не поменяешь (а если надо менять по кнопочке - см пункт б )
<div class="article article_theme_auto"> ... </div>.article_theme_auto @media (prefers-color-scheme: dark) background black color white @media (prefers-color-scheme: light) background white color blackб) потому что тема блока может быть реализована через БЭМ модификатор, и чтобы сменить её нужно сменить модификатор блока, а этого без патчей в htmx не сделать, как я понимаю
<div class="article article_theme_light"> ... </div>
Wesha
22.05.2023 13:21...И чтобы автоматически заказывало клинету
авиабилеттелепорт из Москвы в Хабаровск!
ogost
22.05.2023 13:21+7я бэкендер, причём ненастоящий, объясните пожалуйста почему:
6 место уже продано. при покупке 3+ мест скидка 5%. это постоянный клиент, поэтому ему положен бесплатный попкорн.
сервер не может отобразить 6 место как недоступное, а логику постоянного клиента и скидки 3+ в любом случае сервер должен обработать, нет? ну разве что пока клиент думал 6ое место выкупили, а страница не умеет обновляться.
таймзона браузера - москва, кинотеатр в хабаровске.
а фронт это как решает? бэк может при желании время и без часового пояса отдавать, и с поясом.
сервер отвечает 502 через раз.
ну за это бэка бить надо.
Вопросы искренние, прошу посвятить.
laatoo
22.05.2023 13:21+2сервер не может отобразить 6 место как недоступное, а логику постоянного клиента и скидки 3+ в любом случае сервер должен обработать, нет?
сложность в управлении сложностью.
сегодня вы управляете сложностью, нарезая интерфейс на компоненты, изолируя внутри каждого отдельного компонента его сложность. у вас будет компонент SeatPicker, который проверит доступность мест (сходив на сервер), выведет ошибку.
когда вы сядете рисовать форму брони в терминах htmx'а (с его "hx-trigger", "hx-target", "hx-swap", итп), вы всю сложность компонента (потому что его нет) обязаны хранить у себя в голове. большая часть вашей головы будет занята конвертированием hx-* терминов в бизнес и обратно. это сложно. форма брони превратится в мешанину из спутанных hx-* штук ещё до того, как вы закончите работать над ней
ну за это бэка бить надо.
хабаровские бэки вам сами наваляют ) чья вина в 502 - это не проблема фронтендера, вам важно эту ошибку обнаружить, обработать, и уведомить пользователя о том что он с этим может сделать
а фронт это как решает? бэк может при желании время и без часового пояса отдавать, и с поясом.
it depends, но в любом случае фронт должен обнаружить что часовой пояс юзера не совпадает с ЧП кинотеатра, и что то с этим сделать.
в простом случае - вывести предупреждение что время местное.
в сложном - брать конвертацию на себя.
в адовом - конвертировать из серверного в местное при выводе (на сервере utc, кинотеатр в хабаровске), из пользовательского в местное при вводе в форму (потому что модели работают с местным временем), из местного в серверное при отправке на сервер (потому что модели работают с местным временем, а на сервере utc)
mvv-rus
22.05.2023 13:21+2когда вы сядете рисовать форму брони в терминах htmx'а (с его «hx-trigger», «hx-target», «hx-swap», итп), вы всю сложность компонента (потому что его нет) обязаны хранить у себя в голове. большая часть вашей головы будет занята конвертированием hx-* терминов в бизнес и обратно. это сложно. форма брони превратится в мешанину из спутанных hx-* штук ещё до того, как вы закончите работать над ней
Компонент может быть и на стороне сервера — и с тем же успехом заниматься конвертированием в бизнес и обратно всех этих «hx-trigger», «hx-target», «hx-swap». Более того, ему не потребуется для этого делать лишний запрос на сервер — он уже там выполняется.
hardtop
22.05.2023 13:21+1Да можно и на беке всё решить, конечно. Будет кусок html с расставленными креслами в зале(зелеными и красными), кол-вом билетов и общей ценой с учётом скидки, попкорна и пр.
Есть несколько actions /add-booking-number?params=, /cancel-booking-number?params= и так далее. Но всегда возвращается целый кусок html с залом, ценой и т.д. Получается, что на любой запрос вы замещаете условный <div id="hall">...</div> - этот div и будет являться target-ом всегда.
Конечно, трафика будет больше, чем получить короткий json. На сервере будет сессия, time-zone, вычисления стоимости и рендер html. Будет ли работать? - Да. Изящно ли это? - Ну, это зависит...
Но если стоит задача сделать трейдинг-клиента, то тут, конечно, лучше сразу взять условный vue.
hardtop
22.05.2023 13:21Да кто ж спорит - даже конвертор валют с двух-сторонним по валютам связыванием удобнее писать на vue.
Htmx удобен не для приложений, а для сайтов, где обратная связь, квиз, форма опроса и прочие несложные вещи.
mvv-rus
22.05.2023 13:21+1Да, HTMX предназначен для написания страниц ввода для веб-приложений, выполняющихся на сервере. Страницы эти, по своей сути, несложные: вся сложность остается на сервере.
Автор оригинальной статьи считает, что таких приложений много, а потому HTMX будет востребован. Про это я ничего не скажу — статистики у меня нет.
Shavadrius
22.05.2023 13:21+1Так и не понял в чем сложность написать это на предложенном тут HTMX. Технология же не запрещает пользоваться CSS.
ilitaiksperta
22.05.2023 13:21+5Рендеринг на сервере и HTMX
Не особо вникал, но звучит как будто пориджи переизобрели php
rsmike
22.05.2023 13:21к слову, php за последние 5 лет развился куда сильнее, чем люди, тиражирующие о нем шутки из 2007 года. Тот же Livewire способен легко заменить и обсуждаемый htmx, и "сложную" логику фронтендера выше (ибо компоненты и биндинг)
Lexicon
22.05.2023 13:21+2Такую статью надо доверять писать фронтендеру
Кроме того, что бекендеру писавшему фронт 20 лет назад "ближе такой код" преимущества непонятны, подходы обеспечивающие изоморфность кода, серверный рендеринг, стриминг html, пуш ресурсов из http2 и тп существуют добрые 5 лет и пользуются хорошей нишевой популярностью.
ibnteo
22.05.2023 13:21Автор переписал своё приложение с React+Django на HTMX+Django, уменьшив количество кода на треть, заодно ещё и перетащив всю логику на Backend.
Мне тоже такой подход понравился, хоть и не всё можно решить через HTMX, JS код ещё приходится писать, но от рутины избавляет.
Helltraitor
22.05.2023 13:21Увиденное меня не впечатлило. Сложно работать с React, используйте что-то попроще или наймите специалиста.
HTMX напоминает мне SQL в смысле декларативного подхода к решению задачи
Кстати, где код
Add Note, неужели там настолько все плохо ;DКакие-то элементы и идеи, возможно, и пригодятся, но выкидывать SPA ради этого никто не будет.
P.S. В статье автора чуствуется негодование и разочарование в React. *Питер Паркер говорит: "Ну, давай, заплачь"*
ImagineTables
22.05.2023 13:21+1Глядя на эту очередную странную идею о том, как избавиться от необходимости синхронизировать фронт/бэк, я в который раз думаю: когда уже приложения будут целиком и полностью исполняться на сервере, а клиенту тупо стримить картинку. Зачем эти полумеры, какие-то «гипермедиа»? Сделать так — и синхронизировать станет нечего, безопасность станет максимальной, а нагрузка на клиент — O(1). Серверные инстансы приложений можно пускать по модели десктопных ОС, которая давно отлажена и заоптимизирована — шарится всё, что только можно без ущерба для безопасности. И никаких больше стресс-тестов на разрыв соединения — он ведь ничего не может испортить!
Newbilius
22.05.2023 13:21+2Требования к пингу и толщине канала при таком подходе сильно вырастут. Нужно же гнать, по сути, не картинку, а видео.
Mad__Max
22.05.2023 13:21По пингу(латенси) нет, не вырастут, может даже и наоборот сократится немного в некоторых случаях. Как посмотришь как современные даже вроде несложные странички сотни запросов к Х разных серверов в процессе загрузки гененируют… А так это будет локально большей частью на сервере бегать(или к соседним в датацентре), а не через половину мира — туда-сюда-обратно между клиентом и серверами по каналам связи бегать.
По толщине (пропускной способности) канала конечно да, намного...
Да, по сути это будет видео, но с переменной частотой кадров (вплоть до нуля fps если на странице ничего не меняется в данный момент — например клиент сидит что-то читает из открытого, или вообще свернул браузер/отошел от компа). И с очень хорошим коэффициентм сжатия (даже если совсем без потерь качества/lossless) у современных алгоритмов определяющих неизменные части (или передвигающиеся — простейший случай скроллинг) и кодирующих и пересылающих только изменения от предыдущих кадров.
Ближайший аналог — софт "удаленного рабочего стола", где многое из этого уже реализовано.
Я открывая статью по заголовку тоже думал, что будет что-то в этом роде описываться, а не просто очередной подход к разбивке фронт/бэк.
ris58h
22.05.2023 13:21например клиент сидит что-то читает из открытого
А читает он в пределах одного экрана? Чтоб говорить предметно: как мне в таком случае прочитать в поездке в метро лонгрид на Хабре?
ImagineTables
22.05.2023 13:21Ближайший аналог — софт "удаленного рабочего стола", где многое из этого уже реализовано.
Когда я писал комментарий, я и держал в голове весьма позитивный опыт, полученный при многолетнем доступе через RDP к компьютеру, в т.ч. с очень слабых устройств (256 метров памяти, 1 ГГц процессора) и очень слабом интернете (3G ещё, а может и EDGE, не помню уже). Всё там прекрасно работает, но это доступ к ОС, а платформы, которая давала бы писать и разворачивать отдельные приложения, всё нет.
ris58h
22.05.2023 13:21+1когда уже приложения будут целиком и полностью исполняться на сервере, а клиенту тупо стримить картинку
Когда у всех клиентов будет постоянное и стабильное подключение, т.е. не скоро.
ImagineTables
22.05.2023 13:21Я десять лет назад работал через RDP в метро с такого вот девайса: https://www.gsmarena.com/lg_fathom_vs750-3356.php и никаких проблем не было.
bbc_69
22.05.2023 13:21+1Вот смотрю я на твой комментарий и ощущение, что ты полностью повторил мысль автора. Ведь гипермедия - это и есть данные вместе со способом их отрисовки. Браузеру нужно лишь знать, как рендерить параграфы, инпуты и т.д. Также, как и с видео: браузеру нужно всего лишь иметь нужный кодек.
ImagineTables
22.05.2023 13:21Неправильное ощущение.
Возьмём только одно отличие. DOM для всей этой гипермудии строить надо? Какой там у него оверхед? Это во времена OLE_VARIANT и юнионов оверхед на переменную был 26 байт минус sizeof() от нативного размера. А сейчас, во времена DOM'ов — сам понимаешь. Возьми реальный документ, как мохнатые юзеры любят — упихать стопицот строк безо всякой нормализации в одну таблицу. Возьми недорогой мобильный аппарат, который конторе своим работникам купить не жалко. И засекай время, через сколько минут с таким подходом браузер у тебя просто молча закроется под пальцами.
Однако, я ещё на очень старых девайсах, с 256 мегабайт, ещё под WM со стилусом, гонял через RDP гигантские проекты в студии, в метро, в условиях крайне нестабильной связи! И проблем не знал!
Конечно, RDP это не для массы юзеров. Там надо админить машину. Доступ будет ко всей ОС. Разграничение прав между юзерами надо вводить. В общем, не хватает какой-то платформы, которая бы решала это всё, давая то же самое удобство, что и раньше, а не этот ваш HTMX.
P.S. И при рендеринге на сервере HTML (а не X) вполне бы пригодился, т.к. HTML (со всеми добавками в виде CSS и JS) это отличный набор языков для GUI, неважно, кто, где и как его рендерит.
bbc_69
22.05.2023 13:21Я говорил про концептуальный уровень. Большой разницы между правкой ДОМа и декодированием кадра я не вижу. Что в памяти больше места занимает: полноценный кадр (попиксельно) или ДОМ - думаю, вопрос риторический.
Касаемо бедных юзеров с сотовыми. То, как относятся современные программисты к оптимизации, мы оба хорошо знаем. Я видел и див внутри дива внутри дива внутри дива. И реакт, насколько я помню, создаёт виртуальный ДОМ. У Вас решений в том же духе: клиенту тяжело всё это тянуть, пусть сервер отдувается, он всегда может ещё плашек памяти докупить.
Вот сейчас читаю статью The web I want и там как раз о том, о чём Вы говорите:
Every day I am frustrated at my phone as it chugs along trying to
display a blog post. The post is there behind a sea of JavaScript and
autoplaying videos.Т.е. по мнению автора, htmx здорово всё упросит. Хотя бы по причине ненадобности JS.
Ну и добавлю, что автор говорит о том, что если клиент не поддерживает htmx, то сервер должен уметь рендерить html полностью в таком случае. В общем, сотовым должно стать полегче. Кстати, большой плюс технологии - возможность отката.
ПС я тут подумал. Может быть чем хуже, тем лучше. Если рендер перенести на сервер, то когда хозява сайтов увидят (а они увидят) экспоненциальный рост потреления ресурсов, а за ним соответсвующий рост расходов, то перестанут рассуждать в стиле "докупить плашку памяти дешевле, чем время программиста" и таки заставят программистов заниматься оптимизацией серьёзно. Так что может быть не такая уж и плохая идея.
theonevolodya
22.05.2023 13:21+4Я работаю в небольшой компании. У нас есть заказ. Разработать веб- и мобильную версию приложения. HTMX вышел из чата.
Но допустим даже заказ на чисто веб-приложение. В первой версии. А потом заказчик придёт и попросит ещё и мобильную версию. И выйдет уже не HTMX, а разработчик, и не из чата, а в окно.
Плюс все эти элементы должен кто-то сверстать. Плюс сделать навигациюю по сайту. Gлюс друге украшательства.
Кординация не упрощается в случае с HTMX, а усложняется. У вас специалисты банально становятся более тесно связаны. Так что, на мой взляд, HTMX - очередная фриковская технологияris58h
22.05.2023 13:21А потом заказчик придёт и попросит ещё и мобильную версию. И выйдет уже не HTMX, а разработчик, и не из чата, а в окно.
Не понял, в чём тут проблема именно связанная с HTMX - это ж просто статичный HTML, который подменяют. Можете объяснить?
Layan
22.05.2023 13:21HTMX - это ж просто статичный HTML, который подменяют
А мобильному приложению нужно API. И вот у вас уже два разных бекенда с идентичным функционалом.
mvv-rus
22.05.2023 13:21Я работаю в небольшой компании. У нас есть заказ. Разработать веб- и мобильную версию приложения. HTMX вышел из чата.
Зависит от архитектуры приложения.
Если приложение — "дикорастущее", т.е. без заранее продуманной архитектуры, с равномерной смесью логики отображения и бизнес-логики по всему коду, где что выросло при реализации очередной функции — как принято было писать лет пятнадцать-двадцать назад, хоть на ПК (Delphi, .NET Windows Forms и т.д.), хоть в вебе (ASP.NET Web Forms) — то так оно и случится.
Но если сразу использовать архитектурные шаблоны (типа недавно раскритикованных MVx), то слой отображения и анализа ввода будет изначально отделен от слоя бизнес-логики. И тогда добавить новую реализацию слоя отбражения — для серверной части это будет простейший переходник между API и вызовами бизнес-логики — будет сравнительно несложно. Ну, а часть слоя отображения, работающую непосредственно на устройстве через API, если я правильно понимаю, по-любому надо будет писать заново.Что в API действительно хорошо — так это то, что его использование навязывает разделение архитектуры на слои. Впрочем — навязывает условно, не всегда правильно: я тут даже где-то на Хабре видел пример, в котором бизнес-логика реализована прямо в SPA, которое через API лезет напрямую в хранилище данных. И, в любом случае, ничто не мешает написать SPA именно так. Только вот, полагаю, что для таких случаев высок риск выхода из чата в окно безопасника (или, за неимением такового — директора).
NickyX3
22.05.2023 13:21Но допустим даже заказ на чисто веб-приложение. В первой версии. А потом заказчик придёт и попросит ещё и мобильную версию.
И в чем проблема? Из кода выдаете данные. Если клиент браузер - накидываете на них шаблон, если нет - отдаете данные.
MIKEk8
22.05.2023 13:21До последнего места работы использовал только сервер сайд рендринг. Разделение на фронт и бэк очень порадовало.
1) Меньше народу кто лезет в репозиторий бэка (меньше координации).
2) Паттерн MVC превращается в MC. Что избавило вообще от взаимодействия с js, css, html
3) Не заморачиваешься над тем как использовать виджет в хедере который зависит от контента страницы.
4) Нет проблем в интеграция для партнёров (просто используют ту же api что и наш фронт)
5) Фронт может получать меньше данных, и переиспользовать их.
6) Проще тестировать т.к. форматирование не мешает
6ap
22.05.2023 13:21И клиент серверные приложения автор тоже отправляет гулять? Неужели не понятно, что браузер это не программа просмотра страниц, это фэрймворк для построения приложений на языке JS. Собственно браузер это тот-же .NET WPF. И при этом он решает главную задачу - простоту доставки приложения (обновлений) клиенту. Более того с приходом WebAssembly фактически решена проблема разнообразия языков разработки фронта.
ris58h
22.05.2023 13:21Неужели не понятно, что браузер это не программа просмотра страниц
Зашёл на Википедию - там всё ещё устаревшее определение "прикладное программное обеспечение для просмотра страниц".
mvv-rus
22.05.2023 13:21Я про это написал выше: habr.com/ru/companies/ruvds/articles/736754/#comment_25575986
Вкартце:- есть разные типы содержимого, которые требуют от программы просмотра разных возможностей;
- увеличение возможностей программы просмотра достается не бесплатно: оно увеличивает поверхность атаки на нее.
ildarin
22.05.2023 13:21+3Зумеры изобрели ASP.NET и Razor.
Cheriksoft
22.05.2023 13:21Ровно такая же мысль была при прочтении. Еще в середине 10-х поддерживал по работе здоровый проект на MVC с фронтовой частью на Razor + jQuery, где значительная часть "динамики" на формах была реализована по типу
$.get("Edit/" + documentId, function(data) { $("#formContainer").html(data); });Ну а на серверной части экшены возвращали банальный PartialView();
Чаще всего таким образом делали какие-то табличные части с динамическим редактированием и добавлением строк - один экшн, который при клике на "добавить" - возвращал вьюху с пустыми полями, другой при клике на существующую строку - возвращал эту же строку с инпутами и так далее.
Единственное отличие от предлагаемого подхода - логика заполнения элементов прописывалась для каждой формы "руками", какого-то единого правила, стандарта и общей библиотеки по селекторам элементов, которые надо было перезаписывать, не было, для каждой сущности (контроллера), которых было за сотню, городились каждый раз свои собственные "велосипеды".
belkin_ai
22.05.2023 13:21+1SPA - это ведь не только рендеринг тэгов и отправка форм. А как же сложный роутинг, управление состояниями, предметная область каких-нибудь не-серверных фич, аутентификация, работа с разными источниками ресурсов? Фреймворки не просто так разрослись по размеру и сложности. Каким бы простым ни был шаблонизатор, к нему придется дописать много чего.
Как бэкендер, я еще и приветствую единый API ресурсов для разных клиентов. А тут - что? И рендеринг пилить, и апи пилить? И всё равно учить как там какая-то новая приблуда работает. Ну уже нет, не взлетит.
event1
22.05.2023 13:21HTML содержит некоторые базовые элементы интерфейса которые можно декларативно скомпоновать в страницы удовлетворяющие потребности, допустим, 1% пользователей. Добавим базовых элементов и сможем удовлетворить 2%. Ну бог с ним, 5%. Так себе выигрыш. Понятно, что большинство современных ситуаций требует полного контроля для программиста, чтобы запрограммировать всё что угодно. По-этому, эта и подобные попытки обречены на провал. Лучше бы придумали для броузера режим с канвасом и автоматическим управлением зависимостями, чтобы каждый чёртов сайт не скачивал чёртов реакт в каждую вкладку.
aimer1988
22.05.2023 13:21+2Очень легко поддерживать пользователей, которые не могут или не желают использовать JavaScript
Могу ошибаться, но мне кажется, что таких пользователей - исчезающее меньшинство. Эта проблема была актуальна быть может 10+ лет назад, но сомневаюсь, что она актуальна сейчас.
laatoo
22.05.2023 13:21+1любопытна доля пользователей, которая в принципе знает что такое javascript, и что оно есть у них в браузере.
больше 0.5%, или меньше?
powerbroker
22.05.2023 13:21про то еще в 1813 году Крылов писал:
Беда, коль пироги начнет печи сапожник,
А сапоги тачать пирожник,
И дело не пойдет на лад...вместо того, чтобы научиться для десктопа писать десктопный гуй, в к вэбу с завидной регулярностью прикручиваются костыль за костылем и протез за протезом в потугах сделать из него подобие десктопа...)))
raven_sp
22.05.2023 13:21+2Использовал htmx в связке с Django. Для небольших проектов, где нет возможности привлечь специального человека под написание фронта - очень даже ничего. Я думаю что не стоит идеализировать как и не стоит уничижать данное решение. Для небольших pet-проектов и небольших команд - вполне себе выход. Когда нужна реально сложная логика поведения интерфейса - будет гораздо сложней. Но ИМХО, свою нишу она займет. Лично в моем инструментарии htmx заняла достойное место.
esisl
22.05.2023 13:21"Серебряной пули не существует" (с)
Современное SPA это, конечно, трэш угар и содомия :(
Откуда такие уши растут, тащем-то, понятно - язык исполнения, априори императивный(во что не ряди), язык описания визуального изображения - декларативный.
И любая попытка скрестить ужа и ежа порождает тааааких мутантов, что мы готовы со сколопендрами обниматься.HTMX... ну... такое. ИМХО, может помочь с проблемами SEO
Теоретически.
В принципе.
Наверное :)
Mox
22.05.2023 13:21Все это уже нескольк раз написано - Stimulus, Hotware, и это - просто библиотеки, а не какой-то стандарт или будущее.
koshi
В статье почему-то не написан важный момент (либо я плохо читал):
технически HTMX реализован в виде небольшой библиотеки на JS.
mvv-rus
Да. Однако я не вижу технических причин, почему HTMX не может быть реализован внутри самого браузера — раз уж большая часть необходимого для этого кода уже есть в движке JS.
laatoo
jquery тоже можно, дальше то что
mvv-rus
Не понял, причем тут jquery.
jquery AFAIK — это реликт эпохи войны бараузеров, средство для того, чтобы делать единообразно действия, которые в разных браузерах на чистом JS делались по-разному.
А HTMX предлагается как стандарт, который реализуют все браузеры (что вполне реально, т.к. войны браузеров теперь ушли в прошлое).
mclander
Вы таки пользовались jquery или только поговорить?
Изначально идея была в кроссбраузерности (но это не точно), а дальше туда влетело столько свистелок и переделок, что знающие люди умели таки в симфонический оркестр) Это потом для рукожопов, хотя стоит признаться, что изначально не только для них, наваяли всякие ангуляры, реакты, вуи и прочее.
И до сих пор, в 2023 году, знающий человек, когда надо сделать что-то мелкое, но интерактивное для дома, для семьи, да чтобы не доставали... Часто не будет заряжать проект с полгигом зависимостей с npmjs, а быстро нагуглит плагин для $(), и наманстырит быстрошляпу, особенно, если будет знать, что поддерживать её будет кто-то другой.
mvv-rus
А разве это имеет значение в данном контексте? Как и все многочисленные достоинства jquery, которые я могу не знать? Дело-то не в этом.
jquery встроить-то, может быть, и можно было, но — уже не встроили. А вот у HTMX шанс есть. И куда лучший шанс, IMHO. Потому что идеологически jquery чужеродно основному языку страницы — HTML(плюс CSS, естественно), оно — расширение для JS, стороннего для HTML средства, сильно отличающегося по идеологии от HTML.
HTML, будучи языком разметки — язык декларативный. А JS, в основе своей — императивный (а сейчас — ещё и с функциональными элементами). Такой язык создает куда больше степеней свободы, чем декларативный, а потому — и сложностей с безопасностью тоже куда больше создает.
А вот HTMX (как я понял из статьи) — это тоже декларативное расширение, а потому его безопасность куда легче контролировать, чем JS. Вследствие этого у HTMX есть своя область применения, отличающаяся от JS и любых библиотек/фреймворков на его основе.
Что до jquery, то его вряд ли возможно отвязать от JS со всеми его степенями свободы. Но это не точно — не возьмусь утверждать наверняка, т.к. глубоко в проблему не погружался.
movl
Думаю в появлении метода
querySelector, jQuery сыграл не последнюю роль. Наверняка jQuery также оказал свое влияние и на ряд других элементов стандартного WebAPI. Да даже банально в консоли отладки можно сделать вызов$("my-selector")с ожидаемым результатом и без подключения jQuery. Это конечно не встраивание в чистом виде, но логичное предоставление стандартных инструментов для тех практик, что приживаются в сообществе.Если честно, вообще не понимаю этот тезис. Для 90-х годов, возможно, такие рассуждения и имели смысл, то есть когда только формировалось какое-то представление о дальнейшем развитии данных технологий. Но в современном мире ни HTML, ни CSS не развиваются независимо от WebAPI, предоставляемого через JS. Это одна экосистема, где все глубоко интегрировано.
mvv-rus
Вообще-то, тут для разъяснения нужна полноценная статья. Но пока я такую не нашел и сам не написал, попробую разъяснить очень кратко, без примеров и с минимумом пояснений.
Основная мысль: эта интегрированность — она, с одной стороны, излишняя для существенной доли содержимого веб (если исходить исключительно из способов взаимодействия конечного пользователя с содержимым и игнорировать потребности размещающих рекламу, о последнем — ниже), а с другой — несет дополнительные риски.
С точки зрения способов взаимодействия конечного пользователя с содержимым в вебе существуют, минимум, три разных его типа:
Как видим, возможности взаимодействия с пользователем при переходе «сверху вниз» увеличиваются. Но это имеет и обратную сторону: при переходе увеличивается и поверхность атаки — то есть либо уменьшается безопасность, либо увеличиваются затраты на ее сохранение на приемлемом уровне: если для первого способа достаточно не допускать грубых ошибк в коде стандартных программ: веб-сервера (выход из дерева каталогов и т.п.) и браузера(переполнение буферов в стеке или куче и пр.), то для второго способа надо ещё и фильтровать ввод в приложении на сервере (чтобы не получить SQL injection, к примеру). Ну, а полноценное использование JS требует защиты от выполнения вредоносного кода (использования «песочницы») на клиенте, от XSS с CSRF… Короче, много чего дополнительно требует.
Именно поэтому я, как пользователь, считаю обоснованным ограничение доступных возможностей для разных типов содержимого. А потому я — за замену JS на условный HTMX там, где это возможно (а уж NoScript я и сам готов себе настроить).
Однако, если учесть потребности тех, кто, в основном, оплачивает современную веб-разработку и эксплуатацию веб-сайтов — рекламодателей — то им, наоборот, крайне желательно, чтобы любая страница в вебе была приложением: так легче делать рекламу максимально эффективной.
А потому я сомневаюсь, что нынешнюю экосистему веба можно изменить в сторону большей безопасности (без изменения его экономической модели, по крайней мере). Однако, я — за то, чтобы хотя бы попробовать.
movl
Для CSRF атак вообще не имеет значение наличие или отсутствие JS, плюс все современные браузеры умеют работать с
Access-Control-Allow-*заголовками. Да и ответственность, за возможность проведения таких атак, в любом случае лежит на беке.По XSS, при рендере документа на беке, точно также, придется специальными средствами санитайзить пользовательские данные. Потому что для 99.9% пользователей веб-браузеров NoScript - это какое ругательство. Помимо этого у бека есть другие возможности, накладывать ограничения, предотвращающие различные сценарии подобных атак, например CSP.
Я могу согласится, с тем что JS, может предоставить дополнительный вектор атак, нацеленных именно на сам веб-браузер и операционку пользователя, но этому также подвержены любые другие технологии. А из того, что перечислено, это просто перекладывание ответственности с одних веб-разработчиков, на других, что никак не влияет на безопасность технологии.
mvv-rus
Правильно. Поэтому JS для того типа содержимого, для которого он не нужен, должен отключаться сами браузером автоматически. Но я думаю прежде всего о себе. А так как лично я к этим 99,9% не отношусь, то могу сам позаботиться об отключении JS — если создатель сайта позволит мне не использовать его для работы с сайтом.
А если не отключать JS (который по умолчанию включен), то и никакого уменьшения поверхности атаки не будет.
Разве? Суть CSRF — послать созданный злоумышленником запрос на другой сервер из браузера пользователя без ведома этого пользователя, но с сохраненными браузером секретными данными пользователя для этого другого сервера. Как это можно сделать без помощи JS, я не представляю. Не подскажете, как?
PS А CORS — это уже дополнительное средство, которое можно использовать неправильно.
На сервере JS в содержимом не выполняется. А в браузере, как я написал выше, польза будет, естественно, только если JS на этой странице будет отключен.
andreymal
Заманиваем пользователя на свой сайт, а на своём сайте пихаем:
Браузер, отправляя такую форму, без вопросов отошлёт все куки, отправка которых не запрещена через SameSite
mvv-rus
А это существенно. А ещё он ещё пошлет и не тот HTTP-Referer, и можно защититься и без CORS.
Но, в целом я был не прав, согласен — запрос юез JS послать можно.
movl
Простая форма для этого подойдет.
Помимо корс заголовков, на сколько я помню сейчас в браузерах по умолчанию выставляется SameSite атрибут у куки. Но сложно спорить с Вашим утверждением, конечно. Однако правильная настройка безопасности, включая шифрование, CORS и CSP, и экранирование пользовательских данных, позволяет обезопасить, на сколько это возможно, всех пользователей сайта для стандартных настроек веб-браузера. И это гораздо важнее с точки зрения бизнеса, чем думать о паре чудиках, которым по каким-то причинам есть дело до отключения JS на странице. Я к тому, что аргумент с безопасностью в пользу выбора этого инструмента очень слабый, по крайней мере в существующей реальности.
upd. Сорри, не заметил сообщение выше
vanxant
Встроили, встроили jquery в браузер. Есть библиотечка cash.js, которая по сути является обёрткой над querySelectorAll и ещё некоторыми шнягами. Весит 2 кб в гзипе, даёт почти стандартный $(...), заменяя 80кб jquery, и, иногда с некоторым шаманством, позволяет запускать достаточно тяжелые штуки, например слайдер slick.js.
Кроме querySelectorAll, в jquery сначала появились и были обкатаны такие штуки как промисы, прокси ($.proxy), fetch ($.ajax), аналог requestAnimationFrame и css-анимаций ($.animate) и т.д. И только потом были внедрены в стандарт.
Собственно, во многих других языках ситуация похожая. Например, в плюсах новые функции сначала обычно обкатывают в библиотеке boost.
mvv-rus
Я виду противоречие в этих двух предложениях. Потому как либо «встроили» (т.е. библиотечки не требуется совсем), либо «есть библиотечка»
vanxant
cash.js это адаптер, который "переименовывает" код типа
$(...).clickвfor ( ... in document.querySelectorAll(...)) {addEventListener('click',...)}mvv-rus
То есть, таки не встроили, а реализовали через адаптер к коду движка JS браузера, внешний по отношению к браузеру.
Safort
Вот тут не соглашусь. Знающий человек не будет использовать jQuery просто потому, что знает о современных возможностях браузеров и о том, что jQuery ему не нужен для мелочи.
myhambr
Знающий человек без червей в голове как раз будет использовать jQuery или cash.js, тупо потому что это удобней, чем писать длинный, но ванильный код. Выше привели прекрасный пример, насколько это короче https://habr.com/ru/companies/ruvds/articles/736754/#comment_25577364
laatoo
50кб минифицированного js, к слову говоря :)
nin-jin
Что в 2 раза больше, чем весь todomvc на $mol.