Вот, деды же придумали чтобы UI-формы генерились на сервере — сервер отдавал HTML смешанный с данными. Ну пусть работало только в браузере, зато всегда была последняя версия приложения.
Потом и сказали что формы должны генериться на клиенте, сервер отдает только концентрированные данные в виде JSON. А клиенты разные — для моб. 2 шт. и для браузера. Клиенты нужно обновлять каждый отдельно (ну разве что в браузере как бы сам обновляется).
Теперь это:
Backend Driven UI (BDUI) — это концепция, при которой сервер управляет не только данными в приложении, но и формирует интерфейсы: экраны, верстку, реакции на взаимодействия пользователя и переходы между экранами. Задача клиентской стороны сводится к рендерингу экранов на основе данных, полученных с сервера.
Т.е., по сути, перепридумали браузер внутри браузера и внутри моб.
Видите как — вроде бы смысла нет технического. А практический смысл офигенный — ведь приложения распространяются централизованно и монополизированно, мы как человечество к этому пришли.
S>Т.е., по сути, перепридумали браузер внутри браузера и внутри моб. S>Кто сталкивался?
Да сплошь и рядом.
Тот же razor.
Но все еще хуже.
1. На клиенте поднимается хромиум.
2. Сервер генерит HTML, отправляет его клиенту и припасает у себя
3. Попутно поднимается соединение через WebSocket
4. На клиенте каждое нажатие кнопки отправляется на сервер
5. На сервере генерируется новый HMTML и делается diff с припасенным п. 2
6. diff через WebSocket прилетает клиенту и JS его применяет к текущему DOM
S>Т.е., по сути, перепридумали браузер внутри браузера и внутри моб.
Чего только не наколбасят все эти resume-driven architects, вместо того чтобы скачать и запустить в виртуалке микроскопический exe desktop-приложения.
Здравствуйте, Osaka, Вы писали:
S>>Т.е., по сути, перепридумали браузер внутри браузера и внутри моб. O>Чего только не наколбасят все эти resume-driven architects, вместо того чтобы скачать и запустить в виртуалке микроскопический exe desktop-приложения.
А как? Допустим вы контора уровня Яндекс, хотите клиентам некое приложение для решения их насущных проблем. Как это сделать?
O>>Чего только не наколбасят все эти resume-driven architects, вместо того чтобы скачать и запустить в виртуалке микроскопический exe desktop-приложения. S>А как? Допустим вы контора уровня Яндекс, хотите клиентам некое приложение для решения их насущных проблем. Как это сделать?
Сперва нужен запускник (какое-то самодельное VMWare), обозвать его "новый броузер с нейросетями" и в нём "поддержка новых современных особо защищённых приложений".
S>Кто сталкивался?
Я сталкивался как пользователь — первые версии госуслуг примерно так и были устроены. То есть там типа фронт по SOAP забирает с сервера XML-разметку, в которой закопана структура UI вместе с client-side JS для оживления страницы, генерирует UI на основе этого XML, запускает JS. JS по SOAP подключается к серверу конкретного приложения и вытаскивает JSON-разметку, которая описывает конкретную форму; генерирует HTML на основе этой формы и вклеивает его в UI полученный на предыдущем шаге. Дальше запускается очередной JS, вытащенный в JSON, вот он уже по REST-протоколу лезет на сервер и наполняет форму конкретными данными.
В общем, смотреть на госуслуги под F12 было крайне занятно. Вопросы "почему так медленно" сразу отпадали, заменяясь вопросом "ооо, как они сумели сделать это настолько быстрым".
А вообще, инженерная мысль движется возвратно-поступательно. Наверное, если под каким-то углом на это посмотреть, то мы увидим спираль, но надо аккуратно выбирать угол.
Помнится, лет 15 тому назад я тут спорил с матёрыми разработчиками о преимуществах веб-приложений перед локальными; а теперь мы видим заход на очередной круг — давайте переизобретём динамический HTML.
Получим веб-сайт, который притворяется приложением, которое на самом деле внутри тащит с сервера не только данные, но и весь look and feel.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Osaka, Вы писали:
O>Сперва нужен запускник (какое-то самодельное VMWare), обозвать его "новый броузер с нейросетями" и в нём "поддержка новых современных особо защищённых приложений".
O>>Сперва нужен запускник (какое-то самодельное VMWare), обозвать его "новый броузер с нейросетями" и в нём "поддержка новых современных особо защищённых приложений". S>https://github.com/divkit/divkit — это и есть такой запускник.
Это — какое-то фантасмагорическое безумие, которое надо год изучать, чтобы написать мобильное приложение из 1 окошка с кнопкой "заплатить". Аналогичный по функционалу хелловорлд на delphi или c#, показывающий формочку с несколькими контролами, будет exe размером 50кб, без 300М жабаскрипта на клиенте, и написан слева направо сверху вниз безо всяких паттернов и микросервисов.
Но ведь цель новомодных фреймворков, как мы знаем, — не повышение качества и производительности.
Здравствуйте, DiPaolo, Вы писали:
DP>Да-да, сразу вспоминается XSLT, которому сто лет в обед DP>У меня такое же ощущение сложилось от темы топика – что это про заход на очередной виток и возврат к идеям, которые когда-то уже использовались.
Но как ни крути — а смысл в этом есть. Ведь у человечества всего лишь 2 платформы моб. девайсов — Android и iOS. И приложения в каждой из этих платформ распространяются преимущественно через маркет. Если Android еще более демократичная, можешь сам поставить себе и скачать — то iOS такого не позволяет в принципе. А эти маркеты могут неделями проверять твое приложение. Использование такой вот системы — это единственное решение.
Здравствуйте, Shmj, Вы писали:
S>Тут вводная: https://habr.com/ru/companies/yandex/articles/768282/
S>Вот, деды же придумали чтобы UI-формы генерились на сервере — сервер отдавал HTML смешанный с данными. Ну пусть работало только в браузере, зато всегда была последняя версия приложения.
S>Потом и сказали что формы должны генериться на клиенте, сервер отдает только концентрированные данные в виде JSON. А клиенты разные — для моб. 2 шт. и для браузера. Клиенты нужно обновлять каждый отдельно (ну разве что в браузере как бы сам обновляется).
S>Теперь это:
S>
S>Backend Driven UI (BDUI) — это концепция, при которой сервер управляет не только данными в приложении, но и формирует интерфейсы: экраны, верстку, реакции на взаимодействия пользователя и переходы между экранами. Задача клиентской стороны сводится к рендерингу экранов на основе данных, полученных с сервера.
S>Т.е., по сути, перепридумали браузер внутри браузера и внутри моб.
S>Кто сталкивался?
S>З.Ы.
Мы сталкиваемся, структура страниц передается через json а там react рисует. Ни когда не делайте так, если не хотите проблем. Это даже не выстрел в ногу, а куда-то повыше.
Здравствуйте, Qulac, Вы писали:
Q>Здравствуйте, Shmj, Вы писали:
Q>Мы сталкиваемся, структура страниц передается через json а там react рисует. Ни когда не делайте так, если не хотите проблем. Это даже не выстрел в ногу, а куда-то повыше.
Здравствуйте, swame, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Здравствуйте, Shmj, Вы писали:
Q>>Мы сталкиваемся, структура страниц передается через json а там react рисует. Ни когда не делайте так, если не хотите проблем. Это даже не выстрел в ногу, а куда-то повыше.
S>А в чем выстрел, можно развить?
В том что бек-энд и фронт-энд программистам приходится взаимодействовать между собой по более широкому кругу вопросов, в этом и проблема, а если их связывает только тоненькая ниточка из передаваемых данных, то им взаимодействовать друг с другом на много проще. Это первое, второе — такой подход просто лишен смысла, с отображением данных нужным образом легко справить программист на фронтенде и это собственно его обязанность. Использовать нужно api first подход.
Здравствуйте, Qulac, Вы писали:
Q>В том что бек-энд и фронт-энд программистам приходится взаимодействовать между собой по более широкому кругу вопросов, в этом и проблема, а если их связывает только тоненькая ниточка из передаваемых данных, то им взаимодействовать друг с другом на много проще. Это первое, второе — такой подход просто лишен смысла, с отображением данных нужным образом легко справить программист на фронтенде и это собственно его обязанность. Использовать нужно api first подход.
