тут вот статься есть, там даже видео с этими дифами есть https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript

Он посылает дифф не в виде сгенерированного html-я.

В общем на какой-нибудь event тебе прилетает сокет с переменными, которые в template указаны, например %Phoenix.LiveView.Socket{
 assigns: %{description: nil, link: nil, loading: false, status: nil},
 changed: nil,

в темплейте есть переменные description: nil, link: nil,, status: nil

Да, в этом есть смысл. А почему тогда все орут про SSR

если ты в сокет чего нибудь запишешь то он приоберет вид %Phoenix.LiveView.Socket{
 assigns: %{description: "223", link: "", loading: false, status: :added},
 changed: %{description: true, link: true, status: true},

вот такая хрень появляется changed: %{description: true, link: true, status: true},

и он знает тепереь что темплейт надо пересчитать, но только лишь его

Проблема, которую я вижу - не в том, какое количество трафика он посылает, а в том, что на каждое изменение в rendering-е обязательна коммуникация с сервером и в случае потери интернета - приложение перестаёт работать.

Или точнее проваливается в фронтенд JS. Соответственно не важно, как много или мало оно посылает пакетов по сути, когда в случае с SPA - можно вообще с сервером не общаться во многих случаях.

Как то ты сильно загнул "во многих случаях"

Когда информация та же, но изменяешь то как она рендерится на фронтенде(а чаще изменяется её вид, нежели получается новая информация - по крайней мере я такие видел чаще и мой петпроект такой), уходишь во всякие - показать расширенную информацию, применяешь какие-то фильтры на уже сфетченную информацию, изменяешь параметр отображения - этого очень много. И я уверен, что в большинстве нетривиальных приложений рендеринга меняющего только отображение информации столько же или больше, чем рендеринга меняющего данные, которые должны быть на сервере.

К примеру, в моём пет приложении можно листать дни вперёд назад и фронтенд запоминает и кеширует информацию и для удобства можно можно убирать и показывать определённые части информации, соответственно после первичной загрузки, человек может ходить вперёд, назад по дням и менять то, как видит данные(чтобы лучше их понять), а коммуникации с сервером к тому моменту уже нет, потому что вся нужная информация загрузилась один раз и подгружается только то, чего нет.

А как это будет выглядеть с LiveView? Напрягать сеть на каждый чих на фронтенде.

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

слушайте, ну очевидно же, что liveview это для каких-то простых кусочков и тех, кто не знает - и не хочет знать js

+

я вот например считаю js убогим куском говна и рад, когда получаю возможность сделать что-то "As an application developer, you don’t need to write a single line of JavaScript"

Да, до тех пор пока твой webpack успешно упакует phoenix_live_view.js вместе со всеми его зависимостями

А вот как перестанет паковать - вот тогда можно будет подохереть as application developer, который не любит js