Комментарии 146
В статье почему-то не написан важный момент (либо я плохо читал):
технически HTMX реализован в виде небольшой библиотеки на JS.
Да. Однако я не вижу технических причин, почему HTMX не может быть реализован внутри самого браузера — раз уж большая часть необходимого для этого кода уже есть в движке JS.
jquery тоже можно, дальше то что
Не понял, причем тут jquery.
jquery AFAIK — это реликт эпохи войны бараузеров, средство для того, чтобы делать единообразно действия, которые в разных браузерах на чистом JS делались по-разному.
А HTMX предлагается как стандарт, который реализуют все браузеры (что вполне реально, т.к. войны браузеров теперь ушли в прошлое).
Вы таки пользовались jquery или только поговорить?
Изначально идея была в кроссбраузерности (но это не точно), а дальше туда влетело столько свистелок и переделок, что знающие люди умели таки в симфонический оркестр) Это потом для рукожопов, хотя стоит признаться, что изначально не только для них, наваяли всякие ангуляры, реакты, вуи и прочее.
И до сих пор, в 2023 году, знающий человек, когда надо сделать что-то мелкое, но интерактивное для дома, для семьи, да чтобы не доставали... Часто не будет заряжать проект с полгигом зависимостей с npmjs, а быстро нагуглит плагин для $(), и наманстырит быстрошляпу, особенно, если будет знать, что поддерживать её будет кто-то другой.
Вы таки пользовались jquery или только поговорить?
А разве это имеет значение в данном контексте? Как и все многочисленные достоинства jquery, которые я могу не знать? Дело-то не в этом.
jquery встроить-то, может быть, и можно было, но — уже не встроили. А вот у HTMX шанс есть. И куда лучший шанс, IMHO. Потому что идеологически jquery чужеродно основному языку страницы — HTML(плюс CSS, естественно), оно — расширение для JS, стороннего для HTML средства, сильно отличающегося по идеологии от HTML.
HTML, будучи языком разметки — язык декларативный. А JS, в основе своей — императивный (а сейчас — ещё и с функциональными элементами). Такой язык создает куда больше степеней свободы, чем декларативный, а потому — и сложностей с безопасностью тоже куда больше создает.
А вот HTMX (как я понял из статьи) — это тоже декларативное расширение, а потому его безопасность куда легче контролировать, чем JS. Вследствие этого у HTMX есть своя область применения, отличающаяся от JS и любых библиотек/фреймворков на его основе.
Что до jquery, то его вряд ли возможно отвязать от JS со всеми его степенями свободы. Но это не точно — не возьмусь утверждать наверняка, т.к. глубоко в проблему не погружался.
jquery встроить-то, может быть, и можно было, но — уже не встроили.
Думаю в появлении метода querySelector, jQuery сыграл не последнюю роль. Наверняка jQuery также оказал свое влияние и на ряд других элементов стандартного WebAPI. Да даже банально в консоли отладки можно сделать вызов $("my-selector") с ожидаемым результатом и без подключения jQuery. Это конечно не встраивание в чистом виде, но логичное предоставление стандартных инструментов для тех практик, что приживаются в сообществе.
Потому что идеологически jquery чужеродно основному языку страницы — HTML(плюс CSS, естественно), оно — расширение для JS, стороннего для HTML средства, сильно отличающегося по идеологии от HTML.
Если честно, вообще не понимаю этот тезис. Для 90-х годов, возможно, такие рассуждения и имели смысл, то есть когда только формировалось какое-то представление о дальнейшем развитии данных технологий. Но в современном мире ни HTML, ни CSS не развиваются независимо от WebAPI, предоставляемого через JS. Это одна экосистема, где все глубоко интегрировано.
Думаю в появлении метода querySelector, jQuery сыграл не последнюю роль.Наверняка. Но, хотя суть близка, форма записи — разная.
Если честно, вообще не понимаю этот тезис.
…
в современном мире ни HTML, ни CSS не развиваются независимо от WebAPI, предоставляемого через JS. Это одна экосистема, где все глубоко интегрировано.
Вообще-то, тут для разъяснения нужна полноценная статья. Но пока я такую не нашел и сам не написал, попробую разъяснить очень кратко, без примеров и с минимумом пояснений.
Основная мысль: эта интегрированность — она, с одной стороны, излишняя для существенной доли содержимого веб (если исходить исключительно из способов взаимодействия конечного пользователя с содержимым и игнорировать потребности размещающих рекламу, о последнем — ниже), а с другой — несет дополнительные риски.
С точки зрения способов взаимодействия конечного пользователя с содержимым в вебе существуют, минимум, три разных его типа:
- документы — статическое содержимое (текст, изображения, звук, видео), почти все взаимодействие пользователя с которым заключается только в переходе по гиперссылкам; это — исторически первый тип содержимого веб, под который он был изначально разработан;
- страницы ввода данных для серверного приложения — для них дополнительно требуются возможности ввода данных, проверки ввода и подстройки интерфейсов ввода под ранее сделанный ввод; поддержка таких эти приложений появились в HTML почти сразу (элементы <input> и <form>), но эти, ранние, возможности удовлетворяют далеко не все потребности таких приложений; и HTMX предназначен как раз для закрытия всех потребностей работы с такого типа содержимым, чтобы заменить JS, используемый для этого исторически;
- полноценные интерактивные приложения; для них, очевидно, нужен полноценный язык программирования, такой, как JS
Как видим, возможности взаимодействия с пользователем при переходе «сверху вниз» увеличиваются. Но это имеет и обратную сторону: при переходе увеличивается и поверхность атаки — то есть либо уменьшается безопасность, либо увеличиваются затраты на ее сохранение на приемлемом уровне: если для первого способа достаточно не допускать грубых ошибк в коде стандартных программ: веб-сервера (выход из дерева каталогов и т.п.) и браузера(переполнение буферов в стеке или куче и пр.), то для второго способа надо ещё и фильтровать ввод в приложении на сервере (чтобы не получить SQL injection, к примеру). Ну, а полноценное использование JS требует защиты от выполнения вредоносного кода (использования «песочницы») на клиенте, от XSS с CSRF… Короче, много чего дополнительно требует.
Именно поэтому я, как пользователь, считаю обоснованным ограничение доступных возможностей для разных типов содержимого. А потому я — за замену JS на условный HTMX там, где это возможно (а уж NoScript я и сам готов себе настроить).
Однако, если учесть потребности тех, кто, в основном, оплачивает современную веб-разработку и эксплуатацию веб-сайтов — рекламодателей — то им, наоборот, крайне желательно, чтобы любая страница в вебе была приложением: так легче делать рекламу максимально эффективной.
А потому я сомневаюсь, что нынешнюю экосистему веба можно изменить в сторону большей безопасности (без изменения его экономической модели, по крайней мере). Однако, я — за то, чтобы хотя бы попробовать.
JS требует защиты от выполнения вредоносного кода (использования «песочницы») на клиенте, от XSS с CSRF
Для CSRF атак вообще не имеет значение наличие или отсутствие JS, плюс все современные браузеры умеют работать с Access-Control-Allow-* заголовками. Да и ответственность, за возможность проведения таких атак, в любом случае лежит на беке.
По XSS, при рендере документа на беке, точно также, придется специальными средствами санитайзить пользовательские данные. Потому что для 99.9% пользователей веб-браузеров NoScript - это какое ругательство. Помимо этого у бека есть другие возможности, накладывать ограничения, предотвращающие различные сценарии подобных атак, например CSP.
Я могу согласится, с тем что JS, может предоставить дополнительный вектор атак, нацеленных именно на сам веб-браузер и операционку пользователя, но этому также подвержены любые другие технологии. А из того, что перечислено, это просто перекладывание ответственности с одних веб-разработчиков, на других, что никак не влияет на безопасность технологии.
для 99.9% пользователей веб-браузеров NoScript — это какое ругательство.
Правильно. Поэтому JS для того типа содержимого, для которого он не нужен, должен отключаться сами браузером автоматически. Но я думаю прежде всего о себе. А так как лично я к этим 99,9% не отношусь, то могу сам позаботиться об отключении JS — если создатель сайта позволит мне не использовать его для работы с сайтом.
А если не отключать JS (который по умолчанию включен), то и никакого уменьшения поверхности атаки не будет.
Для CSRF атак вообще не имеет значение наличие или отсутствие JS
Разве? Суть CSRF — послать созданный злоумышленником запрос на другой сервер из браузера пользователя без ведома этого пользователя, но с сохраненными браузером секретными данными пользователя для этого другого сервера. Как это можно сделать без помощи JS, я не представляю. Не подскажете, как?
PS А CORS — это уже дополнительное средство, которое можно использовать неправильно.
По XSS, при рендере документа на беке, точно также, придется специальными средствами санитайзить пользовательские данные.
На сервере JS в содержимом не выполняется. А в браузере, как я написал выше, польза будет, естественно, только если JS на этой странице будет отключен.
Как это можно сделать без помощи JS
Заманиваем пользователя на свой сайт, а на своём сайте пихаем:
<form action="https://сайт-жертва.рф/admin/delete-everything" method="POST">
<button type="submit">Скачать бесплатно без регистрации и смс</button>
</form>Браузер, отправляя такую форму, без вопросов отошлёт все куки, отправка которых не запрещена через SameSite
Как это можно сделать без помощи JS, я не представляю. Не подскажете, как?
Простая форма для этого подойдет.
PS А CORS — это уже дополнительное средство, которое можно использовать неправильно.
Помимо корс заголовков, на сколько я помню сейчас в браузерах по умолчанию выставляется SameSite атрибут у куки. Но сложно спорить с Вашим утверждением, конечно. Однако правильная настройка безопасности, включая шифрование, CORS и CSP, и экранирование пользовательских данных, позволяет обезопасить, на сколько это возможно, всех пользователей сайта для стандартных настроек веб-браузера. И это гораздо важнее с точки зрения бизнеса, чем думать о паре чудиках, которым по каким-то причинам есть дело до отключения JS на странице. Я к тому, что аргумент с безопасностью в пользу выбора этого инструмента очень слабый, по крайней мере в существующей реальности.
upd. Сорри, не заметил сообщение выше
Встроили, встроили jquery в браузер. Есть библиотечка cash.js, которая по сути является обёрткой над querySelectorAll и ещё некоторыми шнягами. Весит 2 кб в гзипе, даёт почти стандартный $(...), заменяя 80кб jquery, и, иногда с некоторым шаманством, позволяет запускать достаточно тяжелые штуки, например слайдер slick.js.
Кроме querySelectorAll, в jquery сначала появились и были обкатаны такие штуки как промисы, прокси ($.proxy), fetch ($.ajax), аналог requestAnimationFrame и css-анимаций ($.animate) и т.д. И только потом были внедрены в стандарт.
Собственно, во многих других языках ситуация похожая. Например, в плюсах новые функции сначала обычно обкатывают в библиотеке boost.
знающий человек, когда надо сделать что-то мелкое
Вот тут не соглашусь. Знающий человек не будет использовать jQuery просто потому, что знает о современных возможностях браузеров и о том, что jQuery ему не нужен для мелочи.
Знающий человек без червей в голове как раз будет использовать jQuery или cash.js, тупо потому что это удобней, чем писать длинный, но ванильный код. Выше привели прекрасный пример, насколько это короче https://habr.com/ru/companies/ruvds/articles/736754/#comment_25577364
Для мелочи не нужен, а для чуть крупнее, чем мелочи? Ну реально для кучи мелкого нестандартна, чем возиться самому можно гугльнуть добавив в запрос jquery и удивиться, что таки оно уже
50кб минифицированного js, к слову говоря :)
Что в 2 раза больше, чем весь todomvc на $mol.
За что же SPA так...
Чувствуется фрустрации бэкендера, не въехавшего в современный фронт
Я сам не с веба вообще, но по общим настроениям в Твиттере и вообще в тусовке, я вижу что от SPA стараются уйти вообще все, теперь современный фронт это Remix и его клоны.
Remix 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.
это скорее незамутненный взгляд со стороны на весь этот содом и гоморру )
Вводная часть статьи и описание минусов SPA очень неполное. Проблема с SPA в том, что он используется надо-не надо. Для формочек без сложной логики вполне подходит серверный рендеринг, не надо там два раза логику дублировать (фронт-бек).
И идея не нова, в свое время еще баловался pjax, где заменяется только часть html. Правда были проблемы с биндингами к элементам.
В современном вебе можно использовать серверную обработку + vue/react в местах, где это необходимо.
когда требования к проекту не позволяют тратить время на обращение к серверу для получения разметки
:)
вспоминается, как мы перенесли логику сжатия (из картинок любого размера в миниатюры 640*480) картинок при загрузке из бека на фронт - так сразу стало веселее.
и ведь это не только на ресурсах сервера отразилось, но и на скорости соединения.
возможности nginx по генерации превьюшек вышли из чата
Странно, почему гугл не транскодирует загружаемое видео на фронте... логично же сэкономить на серверах за счёт клиентов? </Sarkasm>
Я к тому, что требования к проектам могут отличатся.
Я не понял, вы чтобы отобразить у клиента условные 640*480 передаете ему условные 2560*1920, и говорите что это оптимизация?
Или наоборот когда пользователю нужно что-то зааплоадить, превьюшка генерится у него локально? Такой кейс более понятен конечно.
Автор преувеличивает сложность одностраничных приложений. Вот, например, колхозный одностраничник latis.cc на голом JS без использования каких-либо фреймворков. Вся логика одностраничности помещается в 20 срок (функция goTo + updateState).
Не надо на сервере гонять логику UI/UX, пусть он сервает бизнес-логику и модель данных через API и возвращает JSONы.
Не надо на сервере гонять логику UI/UX, пусть он сервает бизнес-логику и модель данных через API и возвращает JSONы.
Да. Но статья — скорее о том, что не надо в браузере гонять (точнее, дублировать) бизнес-логику. С одной стороны это так. Но с другой — а куда отнести логику проверки введенных пользователем данных? Эта логика имеет двойственную природу: с одной стороны это — часть бизнес-логики, проверяющая пригодность данных для обработки, а с другой — часть логики пользовательского интерфейса, показывающая пользователю его ошибки, желательно — как можно раньше.
куда отнести логику проверки введенных пользователем данных
валидация "техническая" - на клиенте, никуда от нее не деться
валидация "доменная"/"смысловая":
а) в сервис, который ходит на бэк с вопросами, и получает ответы
SomethingAvailabilityService.isAvailableAt(...)б) в сервис, который уже получил в каком-то формате constraints от сервера, и сгенерировал правила для проверки (ConstraintBuilder+ConstraintValidator)
Техническую пригодность (валидность) данных проверяем сразу и онлайн, при вводе, а правильность/пригодность/применимость - уже там, где бизнес-логика.
Например: логин (емейл)/пароль (минимум 6 символов), валидность ввода (введён именно емейл, проверяем регуляркой, введены минимум шесть символов в поле пароля) проверяем на фронте сразу при вводе и сразу показываем ошибку пользователю, удовлетворяющее техническим ограничениям (валидные) данные отправляем на сервер, а там уже проверяем есть ли юзверь в базе и тот ли у него пароль.
Это все так, но…
Формальную правильность данных ("техническую пригодность") все равно придется проверять и на сервере — потому что данные на сервер может передать не только клиент: канал передачи данных на сервер не защищен от посылки на него поддельных запросов.
Для валидации такого уровня даже кастом JS на клиенте особо не нужен, это всё валидируется через HTML5 input types + built-in form validation (атрибуты required, minlength, maxlength, min, max, type, pattern)
Нууу... Онлайн-валидацию (сразу показывая клиенту неверный ввод, до отправки формы) без JS Вы не сделаете.
Вы точно прочитали про что я написал? HTML5 Input Attributes + built-in form validation через атрибуты не требует НИ СТРОЧКИ JS кода в минимальном виде (да, если вы хотите кастомизировать поведение браузера и сообщения - то тут Validation API все ж понадобится и более того, хорошим тоном даже при валидных для браузера данных и серверной валидации будет обернуть ответ об ошибке через Validation API).
до отправки формы
Не валидная, с точки зрения браузера, форма вообще не отправится.
https://nickyx3.ru/f.html - можете развлечься с отправкой неверных данных
(вздыхает) Вы точно прочитали мой комментарий?
**Как** Вы без JS покажете ошибку *в момент ввода*?
Не при отправке, а сразу?
Так отправки не происходит, build-in form validation без JS происходит до отправки формы. И кстати, если на первом скрине моя форма - что за браузер вам дал ввести не цифры во второе поле? Chrome не дает, ибо type="number"
В 80% случаев встроенной валидации форм достаточно для обычных задач, ибо оно единообразно во всех браузерах через единый API. Если Вам конкретно надо кастом валидацию (ну на on typing например) - берете и делаете через этот же API свой JS (ну там setCustomValidity() и вот это всё), и будет так же ЕДИНООБРАЗНО.
type=date тоже единообразен во всех браузерах?
Я знаю, что отправки не происходит.
Но когда юзверь фигачит многоэкранную форму на 100500 полей, лучше ему сразу подсказать, что тут он лажу гонит, чем заставлять его кругами бегать по этой форме, ища по очереди все неверные поля - есть шанс, что он озверееть, плюнеть и свалит с такого "юзабильного" сайта, то есть прямой убыток конторе и з/п разрабов, как прямое следствие падения доходов :)
А без JS валидацию на вводе сделать невозможно, я изначально ровно про это писал.
P.S. Браузер Safari Version 16.5 (18615.2.9.11.4) на macOS 13.4 (22F66) Ventura
Я же не говорю, что JS не нужен совсем. Минимальная валидация средствами браузера есть и работает. Хотите плюшек - делайте с JS, но, внимательно прочитайте, что я писал. Для минимальной не нужен. Для плюшек понадобится, но хорошим вариантом должно быть то, что плюшки используют этот же API, для единообразия. Ибо setCustomValidity() в стандарте не просто так - а именно для этого. А уж как вы оформите сообщения (а они оформляются) и :invalid states – это вторично
Для самой минимальной - да, не нужен. Я и не спорю :)
Но самая минимальная не есть хорошо для удобства пользователя.
> Ибо setCustomValidity() в стандарте не просто так - а именно для этого.
Да, но она просто устанавливает HTMLInputElement.validationMessage в кастомное, к валидации на вводе это отношение не имеет.
Если уж делать, то лучше доверстать HTMLSpanElement и ему в textContent пихать либо пустую строку, либо то же validationMessage стандартное браузерное (что на моём втором скрине выше и было :) ), либо своё собственное сообщение об ошибке.
Да, но она просто устанавливает
HTMLInputElement.validationMessageв кастомное, к валидации на вводе это отношение не имеет.
Не совсем, если сообщение не пустое - то и state становится invalid, если пустое - то state сбрасывается на валидный.
It's vital to set the message to an empty string if there are no errors. As long as the error message is not empty, the form will not pass validation and will not be submitted.
А уж как вы обернете reportValidity() это реально вторично, мы вот так сделали например
В данном случае мы в textContent у ошибок ничего не добавляем, только меняем data атрибут и контент из него попадает через :before + :after с помощью CSS. Нам так показалось удобнее (просто пустые элементы с классом в шаблоне)
Ну это уже тупо техника, да. А переключатель на 'change' или 'input' вешаете?
Переключатель чего? проверки reportValidity?
В зависимости от поля, change или keyup для текстовых
Ну да, состояний и показов ошибок :)
Скажите, а какое преимущество у 'keyup' для текстовых перед 'input'? Или это просто исторически сложилось?
input это событие такое? Хм.. Надо почитать про это, ни разу что-то не пользовался. А в целом исторически, ибо не все нажатия кнопок в полях ввода вызывают change, а отпускание кнопки keyup таки да. Плюс там местами (в конкретном случае название города) на keyup навешан выбор города из разрешенных (мы берем НП своего региона с населением 1000+ граждан, в более мелких смысла нет)
Да, это именно для текстовых полей хорошо.
На событие 'input' вешаем слушатель, который проверяет evt.target.validity.valid и в зависимости от результата ставит/снимает классы ошибки с самого поля и прилежащего HTMLSpanElement, которому в textContent записывает/снимает сообщение об ошибке, стандартное из HTMLInputElement.validationMessage или своё, самодельное :)
И вишенкой на торте - проверяем валидность всех инпутов в форме, и если хоть один невалидный - отключаем (или включаем, если все ОК) кнопку отправки, заодно ставим/снимаем класс, стилизующий её неактивной.
ставит/снимает классы ошибки с самого поля и прилежащего
HTMLSpanElement, которому вtextContentзаписывает/снимает сообщение об ошибке, стандартное изHTMLInputElement.validationMessageили своё, самодельное :)
Я уже написал, там и так проверяются все поля, но как раз через нормальную работу с Validation API, то есть биндим на form событие invalid, где в замыкании переопределяем стандартное поведение (вот те baloon браузерные погасить) и вызываем уже свою функцию которая будет куда надо выдавать сообщения, стандартные или нет (кстати в event.target у формы при таком событии как раз невалидный input). Мы это делаем не через текст в самом блоке, а через дата атрибуты и CSS - можно посмотреть ниже пример, мы не навешиваем класссы, псевдокласс :invalid и так сам навешивается
Плюс этого подхода в том, что при даже отправке формы и серверной валидации мы можем через setCustom вызвать всю эту цепочку автоматически
Не понимаю, почему в этой ветке до сих пор не упомянули это А нет, упомянули, но так мелко, что я не заметил. Но раз уж я уже отправил комментарий, то:
input:invalid {
border: 1px solid red;
}Текст ошибки конечно не выведет, но по крайней мере это даст юзеру возможность увидеть красную рамочку вокруг ошибочного инпута сразу в момент ввода
Потому что это - технический момент. Ещё можно `color: red;` и кучу других развлекаловок внешних добавить.
Технические моменты, на моем скриншоте еще что-то подобное
input:invalid + .error-block::before {
/* icon */
}
input:invalid + .error-block::after {
content: attr(data-content);
}
input + .error-block {
display: none;
}
input:invalid + .error-block {
display: flex;
}И соответственно, меняя атрибут data-content можно текст ошибки менять, не меняя содержимое самого блока ошибки напрямую
Для такого лучше использовать Stimulus
И на что только люди не готовы пойти, лишь бы нормальный API не писать...
а мне нравится uniGUI - страничка выглядит как windows-приложение, и работает так же, да и пишется такой сайт теми же средствами что и приложение (Embarcadero RAD Studio)
замечательная технология.
а теперь напишите на ней форму брони 4-8 мест в 16 ряду кинотеатра на сеанс с 13:00 до 15:30.
6 место уже продано. при покупке 3+ мест скидка 5%. это постоянный клиент, поэтому ему положен бесплатный попкорн. таймзона браузера - москва, кинотеатр в хабаровске. сервер отвечает 502 через раз.
вот этим занимаются во фронтенде, а не тудушками с гипермедиями
Когда пользователь нажимает на кнопку редактирования, браузер выполняет
HTTP GETк указанному ресурсу todo. Сервер возвращает гипермедиа-ответ, который является описанием этого ресурса с элементами управления гипермедиа.
и про темную тему не забудьте, в москве еще ночь.
htmx-патчами с сервера весь интерфейс перекрасить надо :)
htmx-патчами с сервера весь интерфейс перекрасить надо :)
Зачем для этого какие-то патчи, если есть prefers-color-scheme?
где-то возможно и так.
а) с 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>...И чтобы автоматически заказывало клинету авиабилет телепорт из Москвы в Хабаровск!
я бэкендер, причём ненастоящий, объясните пожалуйста почему:
6 место уже продано. при покупке 3+ мест скидка 5%. это постоянный клиент, поэтому ему положен бесплатный попкорн.
сервер не может отобразить 6 место как недоступное, а логику постоянного клиента и скидки 3+ в любом случае сервер должен обработать, нет? ну разве что пока клиент думал 6ое место выкупили, а страница не умеет обновляться.
таймзона браузера - москва, кинотеатр в хабаровске.
а фронт это как решает? бэк может при желании время и без часового пояса отдавать, и с поясом.
сервер отвечает 502 через раз.
ну за это бэка бить надо.
Вопросы искренние, прошу посвятить.
сервер не может отобразить 6 место как недоступное, а логику постоянного клиента и скидки 3+ в любом случае сервер должен обработать, нет?
сложность в управлении сложностью.
сегодня вы управляете сложностью, нарезая интерфейс на компоненты, изолируя внутри каждого отдельного компонента его сложность. у вас будет компонент SeatPicker, который проверит доступность мест (сходив на сервер), выведет ошибку.
когда вы сядете рисовать форму брони в терминах htmx'а (с его "hx-trigger", "hx-target", "hx-swap", итп), вы всю сложность компонента (потому что его нет) обязаны хранить у себя в голове. большая часть вашей головы будет занята конвертированием hx-* терминов в бизнес и обратно. это сложно. форма брони превратится в мешанину из спутанных hx-* штук ещё до того, как вы закончите работать над ней
ну за это бэка бить надо.
хабаровские бэки вам сами наваляют ) чья вина в 502 - это не проблема фронтендера, вам важно эту ошибку обнаружить, обработать, и уведомить пользователя о том что он с этим может сделать
а фронт это как решает? бэк может при желании время и без часового пояса отдавать, и с поясом.
it depends, но в любом случае фронт должен обнаружить что часовой пояс юзера не совпадает с ЧП кинотеатра, и что то с этим сделать.
в простом случае - вывести предупреждение что время местное.
в сложном - брать конвертацию на себя.
в адовом - конвертировать из серверного в местное при выводе (на сервере utc, кинотеатр в хабаровске), из пользовательского в местное при вводе в форму (потому что модели работают с местным временем), из местного в серверное при отправке на сервер (потому что модели работают с местным временем, а на сервере utc)
когда вы сядете рисовать форму брони в терминах htmx'а (с его «hx-trigger», «hx-target», «hx-swap», итп), вы всю сложность компонента (потому что его нет) обязаны хранить у себя в голове. большая часть вашей головы будет занята конвертированием hx-* терминов в бизнес и обратно. это сложно. форма брони превратится в мешанину из спутанных hx-* штук ещё до того, как вы закончите работать над ней
Компонент может быть и на стороне сервера — и с тем же успехом заниматься конвертированием в бизнес и обратно всех этих «hx-trigger», «hx-target», «hx-swap». Более того, ему не потребуется для этого делать лишний запрос на сервер — он уже там выполняется.
Да можно и на беке всё решить, конечно. Будет кусок html с расставленными креслами в зале(зелеными и красными), кол-вом билетов и общей ценой с учётом скидки, попкорна и пр.
Есть несколько actions /add-booking-number?params=, /cancel-booking-number?params= и так далее. Но всегда возвращается целый кусок html с залом, ценой и т.д. Получается, что на любой запрос вы замещаете условный <div id="hall">...</div> - этот div и будет являться target-ом всегда.
Конечно, трафика будет больше, чем получить короткий json. На сервере будет сессия, time-zone, вычисления стоимости и рендер html. Будет ли работать? - Да. Изящно ли это? - Ну, это зависит...
Но если стоит задача сделать трейдинг-клиента, то тут, конечно, лучше сразу взять условный vue.
Да кто ж спорит - даже конвертор валют с двух-сторонним по валютам связыванием удобнее писать на vue.
Htmx удобен не для приложений, а для сайтов, где обратная связь, квиз, форма опроса и прочие несложные вещи.
Автор оригинальной статьи считает, что таких приложений много, а потому HTMX будет востребован. Про это я ничего не скажу — статистики у меня нет.
Так и не понял в чем сложность написать это на предложенном тут HTMX. Технология же не запрещает пользоваться CSS.
Рендеринг на сервере и HTMX
Не особо вникал, но звучит как будто пориджи переизобрели php
Не особо вникал
Слова типичного смузихлёба.
к слову, php за последние 5 лет развился куда сильнее, чем люди, тиражирующие о нем шутки из 2007 года. Тот же Livewire способен легко заменить и обсуждаемый htmx, и "сложную" логику фронтендера выше (ибо компоненты и биндинг)
Тоже так показалось. А вообще в экосистеме laravel уже много лет существует такая штука - livewire. Делает примерно то же самое, только удобнее.
Не знаю почему, но почему то мне вспомнился GWT.
Такую статью надо доверять писать фронтендеру
Кроме того, что бекендеру писавшему фронт 20 лет назад "ближе такой код" преимущества непонятны, подходы обеспечивающие изоморфность кода, серверный рендеринг, стриминг html, пуш ресурсов из http2 и тп существуют добрые 5 лет и пользуются хорошей нишевой популярностью.
Увиденное меня не впечатлило. Сложно работать с React, используйте что-то попроще или наймите специалиста.
HTMX напоминает мне SQL в смысле декларативного подхода к решению задачи
Кстати, где код Add Note, неужели там настолько все плохо ;D
Какие-то элементы и идеи, возможно, и пригодятся, но выкидывать SPA ради этого никто не будет.
P.S. В статье автора чуствуется негодование и разочарование в React. *Питер Паркер говорит: "Ну, давай, заплачь"*
Глядя на эту очередную странную идею о том, как избавиться от необходимости синхронизировать фронт/бэк, я в который раз думаю: когда уже приложения будут целиком и полностью исполняться на сервере, а клиенту тупо стримить картинку. Зачем эти полумеры, какие-то «гипермедиа»? Сделать так — и синхронизировать станет нечего, безопасность станет максимальной, а нагрузка на клиент — O(1). Серверные инстансы приложений можно пускать по модели десктопных ОС, которая давно отлажена и заоптимизирована — шарится всё, что только можно без ущерба для безопасности. И никаких больше стресс-тестов на разрыв соединения — он ведь ничего не может испортить!
Требования к пингу и толщине канала при таком подходе сильно вырастут. Нужно же гнать, по сути, не картинку, а видео.
По пингу(латенси) нет, не вырастут, может даже и наоборот сократится немного в некоторых случаях. Как посмотришь как современные даже вроде несложные странички сотни запросов к Х разных серверов в процессе загрузки гененируют… А так это будет локально большей частью на сервере бегать(или к соседним в датацентре), а не через половину мира — туда-сюда-обратно между клиентом и серверами по каналам связи бегать.
По толщине (пропускной способности) канала конечно да, намного...
Да, по сути это будет видео, но с переменной частотой кадров (вплоть до нуля fps если на странице ничего не меняется в данный момент — например клиент сидит что-то читает из открытого, или вообще свернул браузер/отошел от компа). И с очень хорошим коэффициентм сжатия (даже если совсем без потерь качества/lossless) у современных алгоритмов определяющих неизменные части (или передвигающиеся — простейший случай скроллинг) и кодирующих и пересылающих только изменения от предыдущих кадров.
Ближайший аналог — софт "удаленного рабочего стола", где многое из этого уже реализовано.
Я открывая статью по заголовку тоже думал, что будет что-то в этом роде описываться, а не просто очередной подход к разбивке фронт/бэк.
например клиент сидит что-то читает из открытого
А читает он в пределах одного экрана? Чтоб говорить предметно: как мне в таком случае прочитать в поездке в метро лонгрид на Хабре?
Ближайший аналог — софт "удаленного рабочего стола", где многое из этого уже реализовано.
Когда я писал комментарий, я и держал в голове весьма позитивный опыт, полученный при многолетнем доступе через RDP к компьютеру, в т.ч. с очень слабых устройств (256 метров памяти, 1 ГГц процессора) и очень слабом интернете (3G ещё, а может и EDGE, не помню уже). Всё там прекрасно работает, но это доступ к ОС, а платформы, которая давала бы писать и разворачивать отдельные приложения, всё нет.
а платформы, которая давала бы писать и разворачивать отдельные приложения, всё нет.
Запуск отдельных приложений через RDP появился в Windows Server 2008.
А в Unix(и потом в Linux) это было штатной возможностью X Window System ещё с незапамятных (для меня) времен — я с этим имел дело в 1999(ЕМНИП) году, когда проверял работу своего Java applet в браузерах и на Windows (прямо на своем рабочем компьютере, Windows 95 OSR2), и на Linux (на нем же через клиент X Window, такие для Windows были) и уже тогда это была далеко не новая технология.
PS Справедливости ради, по RDP, в основном шел, по возможности, не чистый видеопоток (последовательность Bitmap'ов), а поток команд для графической подсистемы, что-то типа того, что пишется в метафайл (EMF). Потому и требования к полосе пропускания были разумные. Впрочем, через модем на 9600 бит/с (иногда приходилось и так) RDP работал медленно и печально.
Проброс окон есть давно в RDP (RemoteApp).
С *nix вот зигзаг — в X Window System вообще с рождения (собственно изначально X Server это отдельная физически железка) — да, в X Window System это было оптимизировано под небольшой пинг и без учета современных требований к интерфейсу и по этому стало легаси но идея была. А вот сейчас прокидывать нормально Wayland по сети это боль. Но решаемая пусть ресурсов и надо больше.
когда уже приложения будут целиком и полностью исполняться на сервере, а клиенту тупо стримить картинку
Когда у всех клиентов будет постоянное и стабильное подключение, т.е. не скоро.
Я десять лет назад работал через RDP в метро с такого вот девайса: https://www.gsmarena.com/lg_fathom_vs750-3356.php и никаких проблем не было.
Вот смотрю я на твой комментарий и ощущение, что ты полностью повторил мысль автора. Ведь гипермедия - это и есть данные вместе со способом их отрисовки. Браузеру нужно лишь знать, как рендерить параграфы, инпуты и т.д. Также, как и с видео: браузеру нужно всего лишь иметь нужный кодек.
Неправильное ощущение.
Возьмём только одно отличие. DOM для всей этой гипермудии строить надо? Какой там у него оверхед? Это во времена OLE_VARIANT и юнионов оверхед на переменную был 26 байт минус sizeof() от нативного размера. А сейчас, во времена DOM'ов — сам понимаешь. Возьми реальный документ, как мохнатые юзеры любят — упихать стопицот строк безо всякой нормализации в одну таблицу. Возьми недорогой мобильный аппарат, который конторе своим работникам купить не жалко. И засекай время, через сколько минут с таким подходом браузер у тебя просто молча закроется под пальцами.
Однако, я ещё на очень старых девайсах, с 256 мегабайт, ещё под WM со стилусом, гонял через RDP гигантские проекты в студии, в метро, в условиях крайне нестабильной связи! И проблем не знал!
Конечно, RDP это не для массы юзеров. Там надо админить машину. Доступ будет ко всей ОС. Разграничение прав между юзерами надо вводить. В общем, не хватает какой-то платформы, которая бы решала это всё, давая то же самое удобство, что и раньше, а не этот ваш HTMX.
P.S. И при рендеринге на сервере HTML (а не X) вполне бы пригодился, т.к. HTML (со всеми добавками в виде CSS и JS) это отличный набор языков для GUI, неважно, кто, где и как его рендерит.
Я говорил про концептуальный уровень. Большой разницы между правкой ДОМа и декодированием кадра я не вижу. Что в памяти больше места занимает: полноценный кадр (попиксельно) или ДОМ - думаю, вопрос риторический.
Касаемо бедных юзеров с сотовыми. То, как относятся современные программисты к оптимизации, мы оба хорошо знаем. Я видел и див внутри дива внутри дива внутри дива. И реакт, насколько я помню, создаёт виртуальный ДОМ. У Вас решений в том же духе: клиенту тяжело всё это тянуть, пусть сервер отдувается, он всегда может ещё плашек памяти докупить.
Вот сейчас читаю статью 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 полностью в таком случае. В общем, сотовым должно стать полегче. Кстати, большой плюс технологии - возможность отката.
ПС я тут подумал. Может быть чем хуже, тем лучше. Если рендер перенести на сервер, то когда хозява сайтов увидят (а они увидят) экспоненциальный рост потреления ресурсов, а за ним соответсвующий рост расходов, то перестанут рассуждать в стиле "докупить плашку памяти дешевле, чем время программиста" и таки заставят программистов заниматься оптимизацией серьёзно. Так что может быть не такая уж и плохая идея.
Я говорил про концептуальный уровень.
Если говорить о концептуальной разнице, она в следующем. В моём подходе разраб абстрагируется от любых гипермедий. Если в какой-то момент мы начинаем гонять примитивы вместо пикселей, или даже эти самые гипермедии (бывают, наверно, ситуации, когда мы таким образом существенно понизим трафик, незначительно повысив нагрузку на клиент, а если сделать гипермедии weak, то и разрыв не страшен), для разраба они будут деталями реализации низкоуровневого протокола, знать который он не обязан.
Есть ведь много подходов к построению GUI. Помимо DOM'овой (а гипермедиа на DOM-элементах означает неявное требование делать всё через DOM) есть ещё OnPaint()/Invalidate(), есть fps'ная (т.е. for (;;) Render();). Почему низкоуровневый протокол должен диктовать подход к созданию UI?
Т.е. по мнению автора, htmx здорово всё упросит. Хотя бы по причине ненадобности JS.
Развивая вышенаписанную мысль. Вот сейчас в некоторых браузерах добавляют такую фичу: переопределение у DOM-элемента отрисовки. Т.е. когда нам надо сделать групповое выделение объектов синей рамочкой, как в Windows Explorer, можно написать что-то типа такого (псевдокод):
$('container').paint = (e) => {e.paint(); drawFrame(e.canvas); }Во-первых, это оптимизация, потому, что совершенно незачем создавать пачку элементов, с узлами в DOM, с применением правил CSS, и т.д. и т.п., когда надо, по сути, всего лишь добавить несколько графических команд в конвейер. Если активно использовать этот приём, в сумме оптимизация станет в разы. Особенно по памяти.
Во-вторых, это просто выразительно. Мы ведь не думаем о рамке как об объекте со временем жизни и свойствами. Зачем же писать в таких терминах?
Вот и пример того, что через этот HTMX не сделать (если я ничего не упускаю).
Собственно, выше я написал, что продуктивно было бы рассматривать HTML/CSS/JS как чисто GUI-шные языки (и использовать только там, где надо). Делать на элементах HTML транспорт (гипермедиа) — так себе идея.
В моём подходе разраб абстрагируется от любых гипермедий.
как же он на сервере всё это добро будет генерить? Увы, сложность не уменьшится, а переместится.
Т.е. когда нам надо сделать групповое выделение объектов синей рамочкой,
как в Windows Explorer, можно написать что-то типа такого (псевдокод):
Тут да, конкретно под эту задачу js необходим.
Почему низкоуровневый протокол должен диктовать подход к созданию UI?
Хороший вопрос. Хотя бы потому, что так страницы были задуманы изначально. Изменить это - настоящая революция. Я бы на это даже посмотрел. Боюсь только, обратная совместимость не позволит это сделать.
Собственно, выше я написал, что продуктивно было бы рассматривать
HTML/CSS/JS как чисто GUI-шные языки (и использовать только там, где
надо).
Воспринимаю HTMX как нечто среднее между HTML и API. Собственно, про него могу сказать что-то подобное: не надо его пихать везде, но есть ниша (довольно большая по мнению автора), где он будет уместен.
как же он на сервере всё это добро будет генерить? Увы, сложность не уменьшится, а переместится.
«Добро» генерирует не сервер, а разработчик. И он может захотеть просто не генерировать его. Как? А отдать, например, контекст/канвас в стороннюю библиотеку. Может быть, обернув его в wrapper. Всё это прекрасно работает, я могу хоть сейчас запустить по RDP что угодно, хоть WordStar через DOSBox. Потому, что RDC не задаёт глупых вопросов и не требует генерировать гипермедиа.
Что касается уменьшения сложности. В исходной статье речь шла о дублировании на клиенте и сервере. Это и есть та сложность (два набора данных вместо одного), которую уменьшают. Я предложил другой способ избавиться от дублирования и, следовательно, уменьшить сложность.
настоящая революция … обратная совместимость не позволит это сделать.
Обратная совместимость не позволит на сервере запускать сборку CEF, рендерить картинку и отправлять её клиенту? В том и прикол, что сделать это проще простого. Можно даже для начала только этим и ограничиться. Венчурные инвесторы, ау!
Вот только вариант с canvas и подобные — это автоматом вылет из поисковых систем. Для приложения это может быть допустимо. А вот если сайт отдает контент и заинтересован чтобы его можно было найти через поисковые системы — то придется отдавать хоть в каком то читаемом виде.
Нет никакой проблемы отдавать поисковым системам нужный им текст. Сравните выдачу:
https://page.hyoo.ru/#!=ocuu95_3ui1ch
https://page.hyoo.ru/?_escaped_fragment_=%3Docuu95_3ui1ch
Ну вот это и есть "в хоть каком то читаемом виде" (хотя у гугла вроде механизм через _escaped_fragment объявлен устаревшим).
Но поисковой системе ж нужно от cloaking'а как то защищаться + такой механизм требует все равно генерации чего то похожего на html. Если у нас серверный рендеринг как в современных SPA-приложениях на всяких React и прочих — это работает, если сервер вообще одну картинку отдает а клиент рендерит через canvas — придется дублировать логику.
Там только роутинг надо "продублровать", чтобы параметры запроса трансировались в запрос к бд. Это 0.0001% логики. У нас этим вообще nginx занимается и сразу стучится в HARP API: https://sync.hyoo.ru/land=ocuu95_3ui1ch=(title_text;release_ref(release_blob);book_ref(title_text);pages_ref(title_text))
И засекай время, через сколько минут с таким подходом браузер у тебя просто молча закроется под пальцами.
А не надо мобильный аппарат.
Берем например какую то книжку на мегабайт текста, открываем ее в Readwise Reader'е (который https://readwise.io/read ) в Chrome. Читается. Теперь пробуем выделять абзацы хотя бы десяток другой. Запросто можно получить вылет вкладки браузера с сообщением про нехватку памяти.
Ах да, это на машине где 128 Gb RAM и куча ядер, а выделения и аннотирование это основная задача Readwise Reader'а.
Ну или вспоминаем тормозящие статьи с кучей комментов на хабре.
И кто виноват?
Я работаю в небольшой компании. У нас есть заказ. Разработать веб- и мобильную версию приложения. HTMX вышел из чата.
Но допустим даже заказ на чисто веб-приложение. В первой версии. А потом заказчик придёт и попросит ещё и мобильную версию. И выйдет уже не HTMX, а разработчик, и не из чата, а в окно.
Плюс все эти элементы должен кто-то сверстать. Плюс сделать навигациюю по сайту. Gлюс друге украшательства.
Кординация не упрощается в случае с HTMX, а усложняется. У вас специалисты банально становятся более тесно связаны. Так что, на мой взляд, HTMX - очередная фриковская технология
А потом заказчик придёт и попросит ещё и мобильную версию. И выйдет уже не HTMX, а разработчик, и не из чата, а в окно.
Не понял, в чём тут проблема именно связанная с HTMX - это ж просто статичный HTML, который подменяют. Можете объяснить?
Я работаю в небольшой компании. У нас есть заказ. Разработать веб- и мобильную версию приложения. HTMX вышел из чата.
Зависит от архитектуры приложения.
Если приложение — "дикорастущее", т.е. без заранее продуманной архитектуры, с равномерной смесью логики отображения и бизнес-логики по всему коду, где что выросло при реализации очередной функции — как принято было писать лет пятнадцать-двадцать назад, хоть на ПК (Delphi, .NET Windows Forms и т.д.), хоть в вебе (ASP.NET Web Forms) — то так оно и случится.
Но если сразу использовать архитектурные шаблоны (типа недавно раскритикованных MVx), то слой отображения и анализа ввода будет изначально отделен от слоя бизнес-логики. И тогда добавить новую реализацию слоя отбражения — для серверной части это будет простейший переходник между API и вызовами бизнес-логики — будет сравнительно несложно. Ну, а часть слоя отображения, работающую непосредственно на устройстве через API, если я правильно понимаю, по-любому надо будет писать заново.
Что в API действительно хорошо — так это то, что его использование навязывает разделение архитектуры на слои. Впрочем — навязывает условно, не всегда правильно: я тут даже где-то на Хабре видел пример, в котором бизнес-логика реализована прямо в SPA, которое через API лезет напрямую в хранилище данных. И, в любом случае, ничто не мешает написать SPA именно так. Только вот, полагаю, что для таких случаев высок риск выхода из чата в окно безопасника (или, за неимением такового — директора).
Но допустим даже заказ на чисто веб-приложение. В первой версии. А потом заказчик придёт и попросит ещё и мобильную версию.
И в чем проблема? Из кода выдаете данные. Если клиент браузер - накидываете на них шаблон, если нет - отдаете данные.
Я работаю в небольшой компании. У нас есть заказ. Разработать веб- и мобильную версию приложения. HTMX вышел из чата.
Когда изучал pyramid, то встретил весьма любопытную технику: по каждый вид запроса есть свой рендерер. Примерно как в статье: под text/html целая страница, под text/htmx только форма. При таком подходе легко сделать рендер json'a под application/json. И никому никуда выходить не надо.
В случае с json'ами там маппинг должен быть чуть ли не один в один.
До последнего места работы использовал только сервер сайд рендринг. Разделение на фронт и бэк очень порадовало.
1) Меньше народу кто лезет в репозиторий бэка (меньше координации).
2) Паттерн MVC превращается в MC. Что избавило вообще от взаимодействия с js, css, html
3) Не заморачиваешься над тем как использовать виджет в хедере который зависит от контента страницы.
4) Нет проблем в интеграция для партнёров (просто используют ту же api что и наш фронт)
5) Фронт может получать меньше данных, и переиспользовать их.
6) Проще тестировать т.к. форматирование не мешает
И клиент серверные приложения автор тоже отправляет гулять? Неужели не понятно, что браузер это не программа просмотра страниц, это фэрймворк для построения приложений на языке JS. Собственно браузер это тот-же .NET WPF. И при этом он решает главную задачу - простоту доставки приложения (обновлений) клиенту. Более того с приходом WebAssembly фактически решена проблема разнообразия языков разработки фронта.
Неужели не понятно, что браузер это не программа просмотра страниц
Зашёл на Википедию - там всё ещё устаревшее определение "прикладное программное обеспечение для просмотра страниц".
Вкартце:
- есть разные типы содержимого, которые требуют от программы просмотра разных возможностей;
- увеличение возможностей программы просмотра достается не бесплатно: оно увеличивает поверхность атаки на нее.
Зумеры изобрели ASP.NET и Razor.
Ровно такая же мысль была при прочтении. Еще в середине 10-х поддерживал по работе здоровый проект на MVC с фронтовой частью на Razor + jQuery, где значительная часть "динамики" на формах была реализована по типу
$.get("Edit/" + documentId, function(data) {
$("#formContainer").html(data);
});Ну а на серверной части экшены возвращали банальный PartialView();
Чаще всего таким образом делали какие-то табличные части с динамическим редактированием и добавлением строк - один экшн, который при клике на "добавить" - возвращал вьюху с пустыми полями, другой при клике на существующую строку - возвращал эту же строку с инпутами и так далее.
Единственное отличие от предлагаемого подхода - логика заполнения элементов прописывалась для каждой формы "руками", какого-то единого правила, стандарта и общей библиотеки по селекторам элементов, которые надо было перезаписывать, не было, для каждой сущности (контроллера), которых было за сотню, городились каждый раз свои собственные "велосипеды".
SPA - это ведь не только рендеринг тэгов и отправка форм. А как же сложный роутинг, управление состояниями, предметная область каких-нибудь не-серверных фич, аутентификация, работа с разными источниками ресурсов? Фреймворки не просто так разрослись по размеру и сложности. Каким бы простым ни был шаблонизатор, к нему придется дописать много чего.
Как бэкендер, я еще и приветствую единый API ресурсов для разных клиентов. А тут - что? И рендеринг пилить, и апи пилить? И всё равно учить как там какая-то новая приблуда работает. Ну уже нет, не взлетит.
HTML содержит некоторые базовые элементы интерфейса которые можно декларативно скомпоновать в страницы удовлетворяющие потребности, допустим, 1% пользователей. Добавим базовых элементов и сможем удовлетворить 2%. Ну бог с ним, 5%. Так себе выигрыш. Понятно, что большинство современных ситуаций требует полного контроля для программиста, чтобы запрограммировать всё что угодно. По-этому, эта и подобные попытки обречены на провал. Лучше бы придумали для броузера режим с канвасом и автоматическим управлением зависимостями, чтобы каждый чёртов сайт не скачивал чёртов реакт в каждую вкладку.
Странно, а когда будет комикс про зумеров, изобретших AJAX?
Очень легко поддерживать пользователей, которые не могут или не желают использовать JavaScript
Могу ошибаться, но мне кажется, что таких пользователей - исчезающее меньшинство. Эта проблема была актуальна быть может 10+ лет назад, но сомневаюсь, что она актуальна сейчас.
Использовал htmx в связке с Django. Для небольших проектов, где нет возможности привлечь специального человека под написание фронта - очень даже ничего. Я думаю что не стоит идеализировать как и не стоит уничижать данное решение. Для небольших pet-проектов и небольших команд - вполне себе выход. Когда нужна реально сложная логика поведения интерфейса - будет гораздо сложней. Но ИМХО, свою нишу она займет. Лично в моем инструментарии htmx заняла достойное место.
Чем вам QWIK не панацея от всех этих проблем? Причем зная React даже переучиваться не нужно в отличии от htmx
"Серебряной пули не существует" (с)
Современное SPA это, конечно, трэш угар и содомия :(
Откуда такие уши растут, тащем-то, понятно - язык исполнения, априори императивный(во что не ряди), язык описания визуального изображения - декларативный.
И любая попытка скрестить ужа и ежа порождает тааааких мутантов, что мы готовы со сколопендрами обниматься.
HTMX... ну... такое. ИМХО, может помочь с проблемами SEO
Теоретически.
В принципе.
Наверное :)
Все это уже нескольк раз написано - Stimulus, Hotware, и это - просто библиотеки, а не какой-то стандарт или будущее.
Странная фигня. Бегать за каждым элементом на сервер это значит сломать любую возможность автономной работы. Сейчас у меня условный список покупок может работать автономно, храня в LS json, который надо закинуть на сервер когда-нибудь потом. А так инета нет, все, финита ля комедиа.
Не говоря уж о том, что при плохом интернете у меня сейчас тормозит загрузка, а будет тормозить еще и рендеринг.
Допустим, нам нужно правило, гласящее, что после того, как список помечен выполненным, его нельзя было редактировать
При подходе с гипермедиа браузер «туп» и ему не нужно об этом волноваться. Разработчик может реализовать это правило в одном месте — на сервере.
Я и сейчас могу просто отдать ошибку "Not editable" в ответ на попытку сохранить нередактируемый список, в чем проблема-то?
Все это подозрительно похоже на vue.js. и вью очень проста в изучении и относительно легковесна ( можно подключать как файлом так и нпм) . И если не вешать десятки вотчеров, то не тормозит совершенно.
Сегодня пользователи ожидают от веб-приложений плавной работы без перезагрузок страниц.
С чего бы это вдруг? Абсолютно неважно где смотреть на спиннер - в ui или во вкладке браузера. Вон гит-лаб - почти каждый роут перезагружается - сильно кто-то страдает?
SPA позволяют инженерам создавать отличные веб-приложения, но за это приходится платить свою цену:
Сильный рост сложности с точки зрения архитектуры и процесса разработки
SPA как раз сильно облегчают именно DX.
Допустим, нам нужно правило, гласящее, что после того, как список помечен выполненным, его нельзя было редактировать. В мире SPA мы бы взяли сырой JSON и вынуждены были создавать бизнес-логику, определяющую, нужно ли рендерить кнопку редактирования в клиентском коде. Однако, если бы мы хотели, чтобы пользователь каким-то образом не обошёл это правило, ту же защиту нужно было реализовать на сервере. Это кажется несерьёзным и простым, но повышает сложность, а вероятность несогласованности повышается.
Ну точно так же в случае с серверной генерацией html эту проверку нужно делать два раза, при отображении кнопки и при попытке записи изменений в базу, т.к. без проверки при записи ничего не мешает мне вручную добавить эту кнопку в html код страницы и отправить запрос
Рендеринг на сервере и HTMX — это будущее