Pull to refresh

Comments 17

UFO just landed and posted this here

Сто процентов. На js вообще все можно, просто мне в целом понравилась идея, я думаю для каких-нибудь узких задач концепция годна.

UFO just landed and posted this here

Для того чтобы пользователь увидель результат реакт должен сзодить на сервер за данными.

С другой стороны при нынешних скоростях интернета разница сходил по апи или получил страницу в html малозаметна. но серверный рендеринг намного проще чем разделить сайт на фронт и бек а потом их стыковать, соответственно и разработка дешевле.

разделить сайт на фронт и бек а потом их стыковать, соответственно и разработка дешевле.

По мне это еще вопрос, что дешевле… Много раз сталкивался с тем, что для сайта с серверным рендерингом на шаблонах еще потом приходилось делать апи. А если еще и мобильное приложение понадобится, то имхо проще все делать на условном реакте и переиспользовать.

Так и представляю себе: 10 кнопок-иконок в интерфейсе, на показ тултипа по наведению к каждой нужно каждый раз дергать сервер, а юзеру - ждать.

Мне кажется, что если и есть шанс уйти от js/ts, то это - wasm. Blazor и т.д. Но, с учётом сложности современного фронта, у нас будут бэкендовые фротендщики или фронтендные бэкендщики.

В случае с тултипами все было бы не совсем так:

  • При наведении на кнопку-иконку юзер просто увидит тултип, (если только вы специально не пропишите дернуть сервер)

  • Однако если например кнопка-иконка это "like it" а тултип выводит список юзеров, кто уже лайкнул, то да, пропишем что нужно спрашивать сервер, и будем всегда иметь up-to-date список юзеров в этом тултипе. В данном случае в любом js/ts frontend нужно было бы также дергать сервер(если хотите updated list иметь всегда).

  • django-sockpuppet можно очень тонко настроить относительно ренденринга элементов, допустим в данном случае можем обновлять непосредственно только тултип.

Мне видится что уйти от js/ts невозможно, а вот иметь чуть больший выбор технологий, почему бы и нет?)

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

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

Интересно сравнить скорость разработки и стоимость поддержки. Писать фронт все равно нужно. Т.е. нужны фулстеки.

Что-то пахнет Phoenix LiveView... Забавно, что уже не Elixir из других языков черпает вдохновение, а наоборот :)

Вы правы ), как рассказывает разработчик django-sockpuppet, Phoenix LiveView был ориентиром про создании StimulusReflex в экосистеме Rails, а SR в свою очередь подтолкнул к созданию django-sockpuppet в экосистеме python, django. В целом идея очень проста и реализуема на любом языке, просто LiveView был первым)

Да, hotwire похож по концепции, посмотрю по-внимательнее, похоже что тоже интересная вещь) спасибо)

Действительно, похоже что концепция html-over-the-wire многим становится интересна, имеем: htmx, liveview, StimulusReflex, hotwire, django-sockpuppet.

Зачем попу гармонь и геморой (Django, его темплейты, python, и прочее,) если можно больше и без них и на любом языке. https://github.com/Claus1/unigui

но ведь в документации стоит "Proof of concept" или? Кстати идея очень похожа на hypergen.

не похож ни разу на hypergen. html разметки нет в принципе. только декларация данных и их ЛОГИЧЕСКАЯ группировка. "Proof of concept" было давно. рабочий инструмент для меня)

Sign up to leave a comment.

Articles