Comments 17
Сто процентов. На js вообще все можно, просто мне в целом понравилась идея, я думаю для каких-нибудь узких задач концепция годна.
Для того чтобы пользователь увидель результат реакт должен сзодить на сервер за данными.
С другой стороны при нынешних скоростях интернета разница сходил по апи или получил страницу в 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? Для джанго версия вроде тоже есть.
htmx из этой же братии
Зачем попу гармонь и геморой (Django, его темплейты, python, и прочее,) если можно больше и без них и на любом языке. https://github.com/Claus1/unigui
но ведь в документации стоит "Proof of concept" или? Кстати идея очень похожа на hypergen.
Django-sockpuppet, интересная альтернатива React, Vue, Angular или очередная заброшенная джанговская «батарейка»?