О да, чудная стоматология СССР. У нас в школе в кабинете стоматологии зубы сверлили, и потом удаляли нервы на живую. До сих пор остались пережитки, куму например штифты в каналы под коронку вкручивали на живую, причем доктор это мотивировал тем, что «Мужик, ничего потерпишь» и «С анестезией не почувствуешь, что я что-то неправильно делаю» (прям как в IT, кровавый патчинг)
Вообще по сути это третья реализация подходов которые были использованы в nitrogen, старогом erlang фреймворке.
Первая реализация была в виде CMS zotonic, в которой под капотом такой же подход как и в nitrogen.
Вторая реализация в виде n2o erlang фреймворка, по сути это переписанный с нуля nitrogen, с вебсокетами и разными вариантами кодирования сообщений.
Третья реализация и скорее всего не последняя от команды разработчиков Phoenix.
Подход очень простой:
1. Сервер отдает сгенерированный html клиенту. В котором все элементы с которыми взаимодействует пользователь (кнопки, выпадающие списки, поля ввода и т.д.) кроме уникальных id (сгенерированных на стороне сервера), содержат js код для отправки payload(нагрузка с данным или просто событием) на сервер…
2. При получении события на стороне сервера происходит декодирование нагрузки, подготавливается ответ, и отправляется клиенту.
3. При получении клиентом сообщения от сервера происходит выполнение кода, как правило это prepend/append, addClass/removeClass, так же может поменять значение элемента или заменить весь блок.
Плюсы такого подхода:
1. Состояние коннекта храниться на сервере, и поэтому не теряется при перезагрузке, так же отпадает надобность в хранилище состояние для фронтенд фрейморка.
2. Для данных которые постоянно дописываются в конец, нету лишнего преобразования данных, с сервера прилетает уже готовый html (в случае фронтенд фрейморков, сервер отдает данные в json, а фреймворк эти данные добавляет в дерево).
3. Для долгих задач на стороне сервера, не надо писать особую логику. Если пользователь закрыл вкладку, то пришедшие данные просто ничего не поменяют.
4. Для клиентов с выключенных js, отдается уже готовый контент, пускай и с урезанной интерактивностью.
Да есть и минусы:
1. Основной минус, что шаблоны и данные идут в перемешку, можно забыть про MVC и прочие патерны.
2. На каждое действие пользователя летит событие на сервер и ответ обратно, при плохой сети это может вызывать проблемы с интерактивностью приложения.
Первая реализация была в виде CMS zotonic, в которой под капотом такой же подход как и в nitrogen.
Вторая реализация в виде n2o erlang фреймворка, по сути это переписанный с нуля nitrogen, с вебсокетами и разными вариантами кодирования сообщений.
Третья реализация и скорее всего не последняя от команды разработчиков Phoenix.
Подход очень простой:
1. Сервер отдает сгенерированный html клиенту. В котором все элементы с которыми взаимодействует пользователь (кнопки, выпадающие списки, поля ввода и т.д.) кроме уникальных id (сгенерированных на стороне сервера), содержат js код для отправки payload(нагрузка с данным или просто событием) на сервер…
2. При получении события на стороне сервера происходит декодирование нагрузки, подготавливается ответ, и отправляется клиенту.
3. При получении клиентом сообщения от сервера происходит выполнение кода, как правило это prepend/append, addClass/removeClass, так же может поменять значение элемента или заменить весь блок.
Плюсы такого подхода:
1. Состояние коннекта храниться на сервере, и поэтому не теряется при перезагрузке, так же отпадает надобность в хранилище состояние для фронтенд фрейморка.
2. Для данных которые постоянно дописываются в конец, нету лишнего преобразования данных, с сервера прилетает уже готовый html (в случае фронтенд фрейморков, сервер отдает данные в json, а фреймворк эти данные добавляет в дерево).
3. Для долгих задач на стороне сервера, не надо писать особую логику. Если пользователь закрыл вкладку, то пришедшие данные просто ничего не поменяют.
4. Для клиентов с выключенных js, отдается уже готовый контент, пускай и с урезанной интерактивностью.
Да есть и минусы:
1. Основной минус, что шаблоны и данные идут в перемешку, можно забыть про MVC и прочие патерны.
2. На каждое действие пользователя летит событие на сервер и ответ обратно, при плохой сети это может вызывать проблемы с интерактивностью приложения.