Два года с Duit — история взросления фреймворка

[itatarchenkoru]

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

Можно ли провести аналогию с SSR в web разработке, с разницей в том, что компоненты встроены в приложения. Фреймворк имеет инструменты для отправки с сервера описания компонентов, а на клиенте парсер и builder, который создает из библиотеки компонентов необходимы интерфейс?

Есть ли у Вас boilerplate для начала работы с фреймворком?

[LesleySin]

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

Да, все верно.

Можно ли провести аналогию с SSR в web разработке, с разницей в том, что компоненты встроены в приложения. Фреймворк имеет инструменты для отправки с сервера описания компонентов, а на клиенте парсер и builder, который создает из библиотеки компонентов необходимы интерфейс?

Концептуально SSR и BDUI схожи, но только на первый взгляд. Главное отличие заключается в том, что SSR генерирует готовый html-код страницы, в то время как BDUI-фреймворки работают с мета-писанием UI (его структурой и свойствами). И решаемые задачи немного разные: для SSR - быстро показать пользователю страницу, для BDUI - управлять контентом и логикой экрана на стороне сервера.

Duit реплицирует библиотеку виджетов Flutter as is, что в моем пониманиии не является компонентом в привычном смысле (как это понимается в веб-разработке), скорее это атомарные строительные блоки UI (компоненты, имхо, более комплексные). Но в целом суть верна: бекенд с помощью DSL формирует макет экрана/виджета, а на стороне приложения этот макет обрабатывается и преобразуется в дерево виджетов Flutter.

Есть ли у Вас boilerplate для начала работы с фреймворком?

К сожалению, полноценного и актуального example app нет. Над этим еще предстоит поработать :(