Pull to refresh

Comments 23

Есть же ".hta" от Microsoft, зачем такое дважды? Похоже я не уловить суть

У всего этого есть фатальный недостаток (то, из-за чего все Rails-приложения ощущаются заторможенными) — задержка по сети: https://gist.github.com/jboner/2841832

Какая разница возвращать JSON или готовый HTML? Задержки будут одинаковыми.

ну если придираться - то json по объему будет меньше)

Его ещё парсить надо, и встраивать в DOM

Не понимаю этого сравнения. При логике на клиенте мы можем очень быстро реагировать на действия пользователя (например показать спиннер или реализовать Optimistic UI), запрос может выполниться гораздо позже чем пользователь увидит отклик в интерфейсе. С логикой на сервере мы этого сделать не можем, а задержки в отклике у подходов отличаются на порядки. И если задержки на клиенте мы можем оптимизировать потому что это наша зона ответственности, то с задержками по сети всё куда сложнее и уже выходит далеко за пределы области фронтенда.

На сервере осталась та же логика, которая там была при SPA, просто ответ с сервера это уже готовый HTML. На клиенте теперь не надо иметь сложную систему типа React, достаточно небольшой либы, которая этот HTML куда надо положит. Можно сделать спиннеры и optimistic UI в простых случаях и запрятать в эту либо или прицепить на какие-то события из неё.

подходи супер простой и сломается если

  • UI обновляется в куче несвязанных мест - нажали на кнопку и в результате в 10 несвязанных блоках на странице что-то поменялось.

  • Вы вынуждены хранить состояние на клиенте и только там. То есть сервер в принципе не может HTML сделать.

  • Куча интерактива не связанного с сервером. Водим курсором - падают снежинки на экране, типа такого

Все это чаще всего присутствует в навороченном UI. А типовой UI ala панель управления облаком, админка, тикет систему и т.п. очень неплохо ложатся в этот подход.

Ого, пахнет совсем недавно забытым jQuery и SSR по запросу из $.ajax(), что как бы намекает, что ничего нового или производительного не дает, это просто шаг назад. Нет?

Тут основное отличие, что нет jQuery (и JS) - всё декларативно.

Не всегда нужно обращаться на сервер, чтобы изменить интерфейс. Как на HTMX сделать локальную динамику? Далеко не всё можно сделать на CSS. А если нужно использовать местную базу данных? А если делаешь приложение на Electron? Очень много «если». Плюс, на каждое нажатие ждать ответа от сервера — это такое себе. На JS можно сделать режим ожидания, спиннер, и это выглядит плавно и приятно в отличие от прямых задержек при обращении к серверу.

Короче говоря, HTMX решает далеко не все задачи JS'а.

смотря, где шаблон лежит. Если уже на клиенте, то капец как быстро будет этот json

Я не сторонник рейлс подобных приложений, когда все рендерится на стороне сервера, но только учитывая как тормознуто и глючно написано подавляющее большинство современных одностраничников в сравнении получаем что тормознутое приложение на рельсах получается не такое уже и тормознутое и зависит часто только от пинга

А посмотрите как работает https://www.hey.com/ Там кстати соединение по вебсокетам идет, а не просто ajax

Сейчас приходится поддерживать старый проект с большим количеством кода на Java Server Faces. Мне кажется, или это в общем и целом "те же уши, вид сбоку"?..

Нет, htmx намного проще. Он просто заменят куски страницы на HTML, который вернул сервер. То есть вместо JSON возвращаем HTML и убираем весь фронтенд код.

По такому описанию всё ещё не понимаю, в чём разница. JSF - по крайней мере, та часть, с которой мы столкнулись, - тоже генерирует фронтэнд-код только для того, чтобы а) отправить запрос, б) заменить кусок страницы на HTML из ответа. htmx делает меньше?

То есть ради того чтобы заменить html на html мы должны теперь использовать htmx?)))) Чувак, а кто мешает сделать запрос на сервер и вернуть готовый html прямо в json?) Что за велосипеды :)

Угу, они там друг другом все вдохновлялись

Turbo + Stimulus не предлагают отказываться от простого JavaScript'a, чем мне больше и нравятся. Я сторонник идеи - для каждой задачи, свой инструмент.

С помощью turbo/frames плюс маленьких контроллеров на Stimulus, или даже стандартных веб-компонентов гарантированно можно однообразно реализовать любую функциональность. Насколько гибкий нерасширяемый htmlx - большой вопрос.

в laravel есть похожая тема livewire.

очень уменьшает рутину в некоторых местах, особенно во всяких админках.

логика в одном месте (на сервере), эту логику не видно посторонним, и не нужно заниматься рутиной - гонять json в обе стороны.

но насклько я знаю от не "просто заменяет html" а делает это с VDOM (меняет то что изменилось), там используется vue core.

в общем обычный тонкий клиент.

наеверное это не панацея для любых проектов, но часто очень выручает.

Аргумент про Internet Explorer 11, конечно, насмешил

Sign up to leave a comment.