Make frontend «backend» again

[j_wayne]

Возникла другая сумасшедшая идея (она еще не реализована). Почему бы вообще не опустить эту часть на бэкенд? Почему бы сейчас не уйти полностью от распределенного приложения? Пускай этот subscription и наш view model генерится на бэкенде? Там база доступна, все синхронно. Все просто и понятно.

А не получится ли так, что придется гонять туда-сюда гигантские куски данных?

[powerman]

Данных вряд ли так много, проблема скорее в задержках (latency).

[Eldhenn]

> придется гонять туда-сюда гигантские куски данных

По мобильному интернету!

[solver]

Не получится. Гоняется не весь view, а только diff между состояниями.
По крайней мере так делается в korolev написанном на scala.
При этом пересылается не чистый html, а упакованный, что сильно уменьшает объем передаваемых данных.

[Lure_of_Chaos]

У меня другая сумасшедшая идея: может, пора перестать сходить с ума по веб-приложениям и вернуться к веб-страницам?
Зачем нам ajax, частичная перерисовка, и эти тонны кода, гоняемые клиенту, когда у нас уже нет тонких каналов и проблемы «пустого листа»? Это же с ума сойти можно, ожидая, пока все хозяйство прогрузится на клиент, инсталлируется, кусками подтянет данные с сервера, отрисуется, а потом покажет багованные кастомные элементы, которые ни разу не интуитивны, но зато сверкают анимациями и морфингом.
Отобразить данные в таблице, показать форму с нативными (для браузера) контролами, ведь все в итоге сводится к этому… Тому же, что мы умели и в начале 2000ых — мы не стали решать более сложные проблемы, нет, мы решаем те же проблемы, но используем куда более сложные инструменты… Действительно ли они нам так нужны?
Плиточные упрощенные визуально контролы… Но давайте упрощать их функциональность, а не внешний вид!

[evocatus]

в HTML до сих пор нельзя создать внутри формы несколько кнопок с разными методами. Нельзя в HTML создать форму с методами PUT или DELETE

[klvov]

Тоже размышляю иногда на эти темы. Причем на самом деле все это уже придумано — именно так и работают фреймворки с поддержкой continuations (продолжений) -например Seaside, на языке Smalltalk. И это позволяет получить ситуацию, которую автор назвал «мир живет на сервере, а фронтенд только рендерит». Совершенно точно, инфа 100%, так разрабатывать приложения намного проще, потому что это «схлопывает» асинхронность, и веб-приложение разрабатывается как десктопное. Но… мир веб-разработки пошел по другому пути. Не могу пока понять, то ли Seaside и аналоги — это тупиковая ветвь эволюции, то ли просто сильно опередили свое время, так что никто ничего не понял, и когда-нибудь оно еще до народа дойдет.

[Druu]

именно так и работают фреймворки с поддержкой continuations (продолжений) -например Seaside, на языке Smalltalk. И это позволяет получить ситуацию

У продолжений есть много своих проблем, как с перформансом так и с сериализацией стейта. Назвать это универсальным решением нельзя.

[klvov]

В общем наверное да, потому что если все сделать как в Seaside, то отзывчивость будет так себе — как в 1999, когда каждая страница прогружалась отдельно. Сейчас уже все привыкли к почти мгновенному отклику. Но он достигается ценой того, что приложение распределяется уже на три уровня — window.storage надо реплицировать в local storage, а его потом «персистить» куда-то на сервер, и все это занимает время, и не всегда проходит гладко. С другой стороны, потребность в легковесных потоках (файберах) явно есть, и для нее в go уже сразу были goroutines, а в Котлине сделали suspend fun. А про накладные расходы на сериализацию состояния — это какие-то десятые доли процента (по времени) по сравнению с задержками, которые возникают, когда функции надо лезть в сеть.

[Druu]

А про накладные расходы на сериализацию состояния — это какие-то десятые доли процента (по времени) по сравнению с задержками

Дело не в задержках, дело в том, что часть состояния:

1. принципиально несерализуема
2. велика, и гонять туда-сюда мегабайты данных на каждый запрос — не лучшая идея

В этих случаях состояние надо хранить на сервере, что, в свою очередь:

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

[volyihin]

@niquola Спасибо большое за доклад. Подскажите пожалуйста, как храните состояние веб-страницы в базе? Как это выглядит? (Например если пользователь открыл модальное окно на странице)

[Druu]

Ну это уже даже перестает быть смешным. 2018 год, 40 лет с первой публикации Трюгве Реенскауга об MVC.
И некоторым людям приходит в голову неожиданная идея о том, что "неплохо бы отделять поведение от данных"...

Почему бы вообще не опустить эту часть на бэкенд? Почему бы сейчас не уйти полностью от распределенного приложения?

Да потому что браузер работает на клиенте.

[zesetup]

Почему бы не взять Vaadin или ZK Framework и не вернуть разработку фронтэнда на бэк?
Судя по тому, что они использовали Dojo Toolkit, то приложения были для предприятий и указанные выше фреймворки с довольно богатым набором компонентов самое оно то.

[jetcar]

по сути новомодные веяния single page application далеко от простых веб страничек не ушли, разве что сам рендеринг происходит по большей части на самом клиенте, а не на сервере, удобняшки для пользователя это хорошо, но не главное и об них BE не должен знать, а вот валидации можно и на BE-нде делать всё равно они там нужны, а на клиенте только для экономии ресурсов BE-нда, ангуляр или vue.js по моему оптимальные решения, есть дизайн и есть данные, нужно в дизайн впихнуть данные и достать обратно перед тем как послать на BE, всё остальное от лукавого

[intet]

База данных на фронтенде это по прежнему больное место. Websql больше не является рекомендованным инструментом и не известно сколько будет поддерживаться. Новый же продвигаемый IndexedDB крайне неудобен. Банальный join в нем надо писать ручками и не известно насколько это быстро.