Comments 16
Возникла другая сумасшедшая идея (она еще не реализована). Почему бы вообще не опустить эту часть на бэкенд? Почему бы сейчас не уйти полностью от распределенного приложения? Пускай этот subscription и наш view model генерится на бэкенде? Там база доступна, все синхронно. Все просто и понятно.
А не получится ли так, что придется гонять туда-сюда гигантские куски данных?
Данных вряд ли так много, проблема скорее в задержках (latency).
По мобильному интернету!
По крайней мере так делается в korolev написанном на scala.
При этом пересылается не чистый html, а упакованный, что сильно уменьшает объем передаваемых данных.
Зачем нам ajax, частичная перерисовка, и эти тонны кода, гоняемые клиенту, когда у нас уже нет тонких каналов и проблемы «пустого листа»? Это же с ума сойти можно, ожидая, пока все хозяйство прогрузится на клиент, инсталлируется, кусками подтянет данные с сервера, отрисуется, а потом покажет багованные кастомные элементы, которые ни разу не интуитивны, но зато сверкают анимациями и морфингом.
Отобразить данные в таблице, показать форму с нативными (для браузера) контролами, ведь все в итоге сводится к этому… Тому же, что мы умели и в начале 2000ых — мы не стали решать более сложные проблемы, нет, мы решаем те же проблемы, но используем куда более сложные инструменты… Действительно ли они нам так нужны?
Плиточные упрощенные визуально контролы… Но давайте упрощать их функциональность, а не внешний вид!
именно так и работают фреймворки с поддержкой continuations (продолжений) -например Seaside, на языке Smalltalk. И это позволяет получить ситуацию
У продолжений есть много своих проблем, как с перформансом так и с сериализацией стейта. Назвать это универсальным решением нельзя.
А про накладные расходы на сериализацию состояния — это какие-то десятые доли процента (по времени) по сравнению с задержками
Дело не в задержках, дело в том, что часть состояния:
- принципиально несерализуема
- велика, и гонять туда-сюда мегабайты данных на каждый запрос — не лучшая идея
В этих случаях состояние надо хранить на сервере, что, в свою очередь:
- может вести к значительным затратам памяти
- практически исключает возможность балансировки нагрузки
@niquola Спасибо большое за доклад. Подскажите пожалуйста, как храните состояние веб-страницы в базе? Как это выглядит? (Например если пользователь открыл модальное окно на странице)
Ну это уже даже перестает быть смешным. 2018 год, 40 лет с первой публикации Трюгве Реенскауга об MVC.
И некоторым людям приходит в голову неожиданная идея о том, что "неплохо бы отделять поведение от данных"...
Почему бы вообще не опустить эту часть на бэкенд? Почему бы сейчас не уйти полностью от распределенного приложения?
Да потому что браузер работает на клиенте.
Почему бы не взять Vaadin или ZK Framework и не вернуть разработку фронтэнда на бэк?
Судя по тому, что они использовали Dojo Toolkit, то приложения были для предприятий и указанные выше фреймворки с довольно богатым набором компонентов самое оно то.
Make frontend «backend» again