Классический способ написания UI как Swing и т.п. - это MVC где есть 2 типа функций рендеринга - 1) функция которая рендерит начальное состояние UI 2) множество функций обновления UI, которые по реакции на события и обновления модели обновляют UI

Так работали наверно 95% всех UI фреймворков во всех языках программирования и 100% в JS.

Когда вышел React он произвел революцию, поскольку он не требует создания обработчиков 2го типа, и делает это все сам автоматически (благодаря Reconciliation). С реактом можно выкинуть из проекта большую часть самого сложного кода - всю эту кучу методов которые слушают состояние модели и обновляют UI, и которые раньше надо было писать вручную. В реакте на любое событие - весь UI рендерится с нуля, затем риакт сравнивает старый и новый UI и САМ определяет как изменить старый UI чтобы он стал новым.

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

Итак - Риакт произвел революцию убрав кучу тупого обезьяньего кода. Далее добавились Angular, Vue и Svelte. Они тоже (условно конечно)работают примерно также и убирают необходимость писать тупой обезьяний код.

Тем не менее - Реакт не решает второй огромной проблемы - распределенной системы. Поскольку в отличии от скажем PHP или Сервлетов где вся логика на сервере, с Риактом теперь она у нас размазана по Серверу и Браузеру, и нам надо дублировать модели, создавать АПИ и коммуникацию между сервером и клиентом иметь разные валидации на клиенте и сервер. Опять приходится поддерживать кучу тупого обеьзяньего кода.

И тут появился Elixir Phoenix LiveView - по словам создателя сделал он его совершенно случайно, подумав а что если переместить код реакта на сервер. Переместить весь клиентский код на риакте из Браузера на сервер, а события (как нажатие клавиши) сериализовать и передавать на сервер по вебсокету, и расчет реакта (работающего на сервере) об изменении HTML DOM также сериализовать и отправлять в браузер. Соответственно браузер превращается во что-то типа Терминала или Удаленного Стола. Клиентское приложение на риакте в реальности работает на сервере (стейтфул), там-же на сервере рендерится ХТМЛ, а в браузер просто посылается его копия. Т.е. ни кода ни логики в браузере почти нету.

(Не путать с server-side react rendering, progressive rendering, enchancement и т.п. - это не имеет ничего общего с этим подходом и нужно для ускорения открытия страницы и загрузки риакта, там риакт рендерится на сервере только для загрузки а затем запускается на браузер и работает дальше как обычный риакт, в то время как Elixir Phoenix LiveView - риакт вообще никогда в браузер не загружает).


Как оказалось подход работает неожиданно хорошо https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript (там тоже ряд оптимизаций кому интересно посмотрите на ютубе презентацию где детально рассказывается как все работает)

Нахрена все это нужно? Потому-что убирается распределенная система, выкидывается больше половины кода, поскольку больше нет раделения на клиентский и серверный код, нет проблемы N+1 запросов, не нужно АПИ и т.п.

Короче вопрос - что из этого есть в Java / Kotlin

П.С.

Не упоминать GWT, Vaadin, kweb, Wicket, teavm и т.п.

Должно быть 2 веши

1) Декларативный рендеринг, без необходимости писать вручную как изменять UI на реакцию на события
2) Фреймворк должен работать на сервере, не на клиенте
3) (думаю само собой понятно, но все-же) Это не Servlet, Spring, JSP, JSF и т.п.

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

Это классический MVC (контроллера для простоты), есть модель - счетчик, метод который рендерит страницу, и метод который обновляет страницу когда меняется модель. Так работает Swing, и все старые JS фреймворки до реакта.



А вот так будет выглядеть код на Риакте (реакт имеется ввиду концепция, не фреймворк React.JS).
Кусок обезьяньего кода выкинули on_change, но работать будет все так-же интерактивно как и раньше. Потому-что риакт сам знает когда нужно выполнить код обновления UI и сделает этот вызов "document.body.innerHtml = count" автоматом.



А Elixir Phoenix LiveView или серверный реакт - это когда все это запущено на сервере, на JVM с Java/Kotlin но при этом показывется в браузере и работает так-же интерактивно и быстро, словно это клиентское приложение сделанное на риакте.

Серверный риакт - это как браузер который запущен на сервере (на самом деле только умный алгоритм рассчета изменений дерева компонентов), все вычисления и UI крутится внутри сервера, а в реальный браузер транслируется просто копия его текущего HtML, типа как удаленный рабочий стол, или старые десктопы-терминалы на майнфреймах.

(контроллера для простоты убран)

авторНо например Oracle ADF - все программируется на сервере, JavaScript вообще не нужен, он под капотом контролов спрятан.
Подозреваю остальные Java Server Face фраймворки примерно так же.

Там нужно вручную писать код - как менять UI в ответ на события. Это старые фреймворки. Собственно "react" называется так из-за реактивности - словно там есть магия когда изменения модели автоматически, реактивно, сами по себе меняют интерфейс. Как в Excell - ты изменил код в одной ячейке - и в других зависимых ячейках все автоматом поменялось. Реакт делает то-же самое для интерфейса, обновляет его автоматически.

А в фреймворках предыдущего поколения - Java Server Face и еще сотен других - это все надо писать вручную.

Мы уходим от дискуссии, как работает риакт я описал, кто не знаком с риактом и если интересны детали - они есть на официальном сайте реакта.

Хорош подход или нет - зависит от задачи, понятно что если приложение посещают десятки миллионов и бабло льется рекой - нужно делать нативно.

Но если это скажем заказные проекты, сокращение кода раза в 3 - и соотв. сроков, усилий и затрат - это хороший вариант.

Про варианты с Kotlin в браузере да есть варианты, но вопрос в том как полностью убрать код на клиенте .

В ZK-фреймворк нет клиентской части (то что нужно), но в ZK-фреймворке нет реактивности.

Изменение UI происходит императивно, за счет прямых манипуляций с компонентами интерфейса, вот кусок кода из его примера, это классический MVC, Swing UI и еще наверно десятка таких-же.




Вот собственно с википедии страницы ZK-фреймворк и указывается что это событийный-компонентный фреймворк.

автор... создавать полноценные пользовательские интерфейсы для веб-приложений без применения JavaScript, в событийно-ориентированной парадигме и компонентной модели ...

Т.е. нужно напрямую манипулировать компонентами интерфейса, изменения интерфейса императивны , в то время как в в реакте, и реактивных фреймворках изменения компонентов интерфейса производятся декларативно , за счет умного алгоритма фреймворка.

В предыдущих постах вы привели 2 вещи, каждая из которых содержит только 1 част из 2х:

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

Мне нужно чтобы было и то и другое (как например в Elixir Phoenix LiveView) :).

То что есть палитра готовых компонентов в ZK и Oracle ADF - это безусловно хорошая вешь, большое улучшение по сравнению с чистым HTML и JS, с ними работать гораздо легче, как десктопное приложение в Дельфи получается .

Но реактивность - это другой уровень, это еще лучше.

Реактивность работает точно также с такими-же палитрами готовых компонентов, там тоже не нужно писать базового HTML, примеры с HTML на риакте - просто чтобы просто было и понятно о чем реч. В реальности в react.js никто не пишет HTML, берется готовая или делается с нуля палитра компонентов - точно такая-же как oracle adf - и точно-также быстро из готовых блоков строится. Только оно еще ко всему прочему и реактивное.

Короче, нужна реактивность на сервере. А не реактивность только на клиенте (с JS подобными клиентскими Kotlin фреймворками), или на сервере но только событийность, без реактивности (ZK, Oracle ADF).

К слову - React - это не веб-фреймворк, понятно что основная движуха идет в вебе, и 90% проектов это хтмл и жаваскрипт. Но вообще это абстрактный алгоритм обновления компонентного дерева в соответствии с заданной моделью. Он работает где угодно, начиная от веба и заканчивая swing, мобильными нативными деревьями компонентов и т.п. на любых языках и с любыми компонентами.

Собственно то что отсутствует в ZK фреймворке - этот самый алгоритм - который автоматически обновляет компонентное дерево в соответствии с изменившейся моделью.

реактивность точнее, фреймворк - react.js это реализация этой идеи и алгоритма для хтмл и жаваскрипта.

Но вообще наверно прийдется умерить желания и поближе посмотреть на компонентные фреймворки ZK и Vaadin.

Вообще в ZK и Vaadin уже есть 90% того что нужно, нет только самого алгоритма сравнения соответствия дерева интерфейса с моделью.
Сам то он простой, но вот чтобы он эффективно работал нужна возможность быстрого сравнения обьектов.
А это можно сделать только если они иммутабельные. Соотв такой алгоритм в ZK и Vaadin потребует использования иммутабельных структур данных в моделях. И у них видимо часть пользователей к этому не готова и не обрадуется, возможно поэтому и не делают.

Смотрю Котлин второй день - бомба. Фактически, если не рассматривать отличия в грамматике/синтаксисе - концептуально получисля улучшенный руби.




Вобщем - классно, много хороших вещей.

Единственно я не понял что они замышляют с инициализацией массивов и мэпов. Я так понимаю у команды котлина мозговые штурмы наверно идут уже наверно лет 5 не прекращаясь = какие скобочки использовать [1, 2] илл {} или еще что-то. Вероятно можем ждать от них самого невероятного прорыва 21 века в области нотации для инициализации коллекций.

Ошибся темой, сори

авторОпять таки, я не понимаю, что Вы понимаете под понятие "model".

Нет, Смысл реактивного программирования в том что весь этот хлам вообще выкидывается.
JavaRx - это не реактивность, это скажем так - некая попытка реализовать что-то вроде реактивности на жаве, на мой взгляд весьма убогая если сравнить с Elm или Svelte.

React.JS - это тоже не настоящая реактивность а ее подобие, но хоть и не настоящая, сделана достаточно хорошо. Единственно требует чтобы данные были иммутабельны.

А что такое модель - `var count = 1` - вот это модель, весь хлам типа бинов, листенеров, JavaRx и т.п. - не нужен. Любые данные языка могут быть моделью.

авторВ ADF (или в ADemphire) это данные в базе или бины.

Вот из этого ничего не нужно. ADF пытается закрыть проблему за счет готовых компонентов, которые каким-то образом прячут событий и их обработки внутри. Реактивный подход - убирает эту сложность. В риакте - я меняют число `count += 1` - и все что где-то как-то использует его напрямую, или не напрямую - автоматически обновляется. Без каких-то бинов, RxJava, лисенеров и т.п. костылей.

Вот целое видео

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

Elm и Svelte это идеалы, но их сложно реализовать, и в ближайшее время в Java ничего подобного не будет, а React - практичная и достаточно простая концепция которая при минимальной сложности и простой реализации - дает большую часть преимуществ и мало минусов.

авторВ Java, по окончанию функции, count становится муссором и все... что где-то как-то используется идет лесом
Поэтому я и написал что настоящая реактивность типа Elm и Svelte в Java невозможна.
Есть либо перегруженные, неудобные поделки типа RxJava и т.п.
Либо модель React.JS - которая достаточно хороша и достаточно просто реализуема.

Риакт и есть ФП. Иммутабельный, декларативный, и без сайд-эффект.

Весь риакт - это одна функция, причем чистая, без сайд эффектов.

fun render(model: AnyDataStructure) -> HtmlTree