Хабр забыл, что это сообщество технических специалистов, требовательных и взыскательных, и прогнулся под корпоративных заказчиков.
Я расцениваю эту кнопку, как открытое неуважение к пользователю. Платформа не доверяет компетенциям целевой аудитории. Вместо того, чтобы дать инструменты для самостоятельного анализа, насаждает "костыль", обесценивающий процесс глубокого понимания кода.
Это абсолютно НОРМАЛЬНО, когда новичек ничего не понял из сложной статьи. Для этого надо развиваться и в будущем возвращаться к тексту, а не доверяться объяснению посредственной нейронки. Так что "польза" притянута за уши.
Не то чтобы я знаковый (или даже хоть сколько-то значимый) автор для хабра и сообщества в целом, но я не намерен терпеть, когда мне в рожу тыкают откровенной халтурой. Я больше никогда не стану публиковать статьи на этом сайте.
Я правильно понял основную задачу, которую решает фреймворк - обновление интерфейса приложения на сервере, без необходимости релиза в сторах?
Да, все верно.
Можно ли провести аналогию с SSR в web разработке, с разницей в том, что компоненты встроены в приложения. Фреймворк имеет инструменты для отправки с сервера описания компонентов, а на клиенте парсер и builder, который создает из библиотеки компонентов необходимы интерфейс?
Концептуально SSR и BDUI схожи, но только на первый взгляд. Главное отличие заключается в том, что SSR генерирует готовый html-код страницы, в то время как BDUI-фреймворки работают с мета-писанием UI (его структурой и свойствами). И решаемые задачи немного разные: для SSR - быстро показать пользователю страницу, для BDUI - управлять контентом и логикой экрана на стороне сервера.
Duit реплицирует библиотеку виджетов Flutter as is, что в моем пониманиии не является компонентом в привычном смысле (как это понимается в веб-разработке), скорее это атомарные строительные блоки UI (компоненты, имхо, более комплексные). Но в целом суть верна: бекенд с помощью DSL формирует макет экрана/виджета, а на стороне приложения этот макет обрабатывается и преобразуется в дерево виджетов Flutter.
Есть ли у Вас boilerplate для начала работы с фреймворком?
К сожалению, полноценного и актуального example app нет. Над этим еще предстоит поработать :(
Краткий ответ - да. В текущей актуальной версии (v3.6.0) кастомные события могут быть обработаны заранее связанными с фреймворком обработчиками (на стороне клиента). Это работает не так гибко, как хотелось бы: надо заранее продумывать что делать и какие данные для этого понадобится передать серверу. Также есть возможность передачи и запуска скриптовых действий, который в ходе выполнения могут эмитить новые события.
С диалогами/модалками/меню ситуация чуть сложнее. В текущей реализации они могут быть открыты с помощью тех же кастомных действий, но если вы хотите отобразить там динамический контент duit, то придется внутри виджета создавать дополнительный DuitDriver - это не классно.
Сейчас ведется активная работа на новой мажорной версией фреймворка, где одним из ключевых изменений как раз станет возможность работать с оверлеями и отображать в них динамический контент без создания дополнительных драйверов.
К сожалению, никакой уникальной информации не смог почерпнуть, все что есть в статье было сказано/написано уже много-много раз. Статья крайне поверхностная и про эволюцию я ничего не нашел: ни в контексте BDUI в целом, ни в контексте того, как это применяется в VK. Заявляю это как разработчик опенсорсного BDUI-фреймворка :)
Я ради интереса погуглил детали реализации такой фичи в Ruby и понял, что под капотом просто лежат принципиально разные механизмы. Ключевое отличие - разрешение вызовов в runtime (Ruby) против compile-time (Dart).
В Dart extension methods - просто синтаксический сахар, связывающий функцию (статическую) с определением класса. На самом деле под капотом класс никак не изменяется.
Думаю, от этого и идет порицание подобной фичи в Ruby.
Работать надо не 12 часов, а головой. Вкалывайте сами, сударь.
P.S. Я, как разработчик BDUI фреймворка верю в то, что за BDUI будущее разработки приложений. Руководитель аутсорс компании верит в то, что вот-вот и будет и на его улице счастье.
Спасибо за статью! Жаль, что она не появилась года эдак полтора назад, когда я начинал заниматься своим проектом.
Сейчас я постепенно прихожу к тому же методу продвижения, что описан в статье. Сам я начал продвижение по другому пути - рассказываю о проекте на профильных конференциях. Выхлоп с них минимальный, звездочки и какой-то актив виде контрибьюторов и пользователей конфы особо не приносят, а времени отнимают достаточно много.
Мне кажется, что такое сравнение не совсем валидно по причине того, что в статье рассказывается о том, как люди избавлялись от повторяющихся частей JSON с помощью шаблонизации.
Сжатие, использование иных протоколов обмена данными - это другая сторона задачи по передаче как можно меньшего объема данных по сети, имхо.
Насколько оправдано использовать OpenGL ES, если новых версий не предвидится, а поддержка Vulkan все шире? Или до более менее существенного применения вулкана еще далеко и можно успеть все переписать? Часто такой такой подход можно встретить в продакшене?
Вы верно заметили, что "360" предполагает наличие людей, которые создадут процесс и проанализируют результат. В противовес этому выступаем метод Форда, простой, как палка. Но мне все-таки кажется, что не верно сравнивать эти два подхода, и вот почему: - Обезличенная обратная связь, которую мы получаем в результате "360" может быть интересным чтивом, но реже станет почвой для того, чтобы задуматься о своем положении в коллективе. При ином методе исследования, мы получаем фидбек в "сыром" виде и интерпретируем его сами, проводя тем самым некоторую рефлексию) - "360" требует административного ресурса, а значит - это инициатива "сверху". Описанный в статье метод - это реакция на запрос, который может присутствовать индивидуально у каждого сотрудника.
"Конструктивные" нападки на Flutter со стороны React Native разработчиков выглядят так - "мыши кололись, но продолжали кушать кактус". Достаньте голову из песка и сравните две технологии объективно.
Я перешел на Flutter после долгого периода работы с React Native и по достоинству оценил качество Flutter. Change my mind :)
Если смотреть на статью, как на туториал (что указано), то получился хороший get started гайд. Мне, как человеку далекому от C++, зачастую непонятно, как было бы "правильно" организовать исходник и собрать их с помощью сmake.
Другая сторона медали - обилие примеров кода библиотеки, которые напрямую не относятся к теме статьи. Можно ведь было сделать гораздо короче, и читабельность повысилась бы (многое я проскролил, мог упустить что-то важное).
И тем не менее спасибо за статью, давно хотел поэкспериментировать с плюсами и теперь есть отправная точка для этого :)
Я сам автор BDUI-фреймворка (для Flutter) и в вашей статье я смог найти множество идейных сходств с моим проектом, а также интересных концепций. Спасибо, что поделились опытом и отдельное спасибо за классные картинки, которые сопровождали статью :)
Добрый день и спасибо за статью! Я тоже разрабатываю решением для SDUI под Flutter. Вы проделали большую работу, поддержав такое большое кол-во виджетов. Думаю, что даже смогу "вдохновиться" некоторыми деталями реализации на своем проекте :)
У меня есть несколько вопросов: 1. Поддерживает ли Nui анимации (implicit виджеты или анимации через контроллеры)? 2. Для кого подойдет ваше решение? Как я понял, экраны настраиваются/обрабатываются экшены в CMS, но есть ли вариант использования без этой обвязки, мб можно реализовать какой-то слой абстракций для работы Nui в формате standalone фреймворка?
Сразу хочу сказать - я не отменяю ни KMP (далее и везде под KMP подразумевается он сам и все что рядом с ним) ни Compose никоим образом. Это хорошие и перспективные технологии, которые найдут свою нишу 100%. Но с некоторыми вашими высказываниями я не согласен.
Архитектура. В этом разделе я говорил не о том, как происходит рендер, а о том, как можно добавить новый build target для конкретной технологии. В случае с KMP добавление нового таргета - прерогатив JetBrains. В случае же с Flutter, таргет можно поддержать самостоятельно, при наличии головы на плечах.
Количество команд. При миграции на KMP вы не избавляетесь от необходимости содержать IOS команду. Итого их уже две. Flutter, по понятным причинам, решает эту проблему.
По экономическому фактору абсолютно не согласен. Вы так уверенно выдвинули лидера, что я аж опешил) Вопрос слишком комплексный, чтобы так легко на него отвечать.
Касательно kotlin на бекенде... Как мне кажется, это либо свежие проекты, либо те проекты я которые достаточно хорошо поддерживались в рамках актуального стека. Вижу лица людей, у которых легаси-код на Java 6 - такие неповоротливые машины очень сложно поставить на новые рельсы.
В целом, я склонен утверждать, что каждый уважающий себя Шрек (читай разработчик) хвалит свое болото (язык, фреймворк), так что я не могу согласиться с тем, что преимущество Flutter лишь в том, что основной конкурент ещё в некоторой степени сырой :) Первый комментарий в этом плане позволяет взглянуть на ситуацию чуть шире.
Хабр забыл, что это сообщество технических специалистов, требовательных и взыскательных, и прогнулся под корпоративных заказчиков.
Я расцениваю эту кнопку, как открытое неуважение к пользователю. Платформа не доверяет компетенциям целевой аудитории. Вместо того, чтобы дать инструменты для самостоятельного анализа, насаждает "костыль", обесценивающий процесс глубокого понимания кода.
Это абсолютно НОРМАЛЬНО, когда новичек ничего не понял из сложной статьи. Для этого надо развиваться и в будущем возвращаться к тексту, а не доверяться объяснению посредственной нейронки. Так что "польза" притянута за уши.
Не то чтобы я знаковый (или даже хоть сколько-то значимый) автор для хабра и сообщества в целом, но я не намерен терпеть, когда мне в рожу тыкают откровенной халтурой. Я больше никогда не стану публиковать статьи на этом сайте.
Да, все верно.
Концептуально SSR и BDUI схожи, но только на первый взгляд. Главное отличие заключается в том, что SSR генерирует готовый html-код страницы, в то время как BDUI-фреймворки работают с мета-писанием UI (его структурой и свойствами). И решаемые задачи немного разные: для SSR - быстро показать пользователю страницу, для BDUI - управлять контентом и логикой экрана на стороне сервера.
Duit реплицирует библиотеку виджетов Flutter as is, что в моем пониманиии не является компонентом в привычном смысле (как это понимается в веб-разработке), скорее это атомарные строительные блоки UI (компоненты, имхо, более комплексные). Но в целом суть верна: бекенд с помощью DSL формирует макет экрана/виджета, а на стороне приложения этот макет обрабатывается и преобразуется в дерево виджетов Flutter.
К сожалению, полноценного и актуального example app нет. Над этим еще предстоит поработать :(
Раунд!)
Спасибо за отзыв!
Краткий ответ - да. В текущей актуальной версии (v3.6.0) кастомные события могут быть обработаны заранее связанными с фреймворком обработчиками (на стороне клиента). Это работает не так гибко, как хотелось бы: надо заранее продумывать что делать и какие данные для этого понадобится передать серверу. Также есть возможность передачи и запуска скриптовых действий, который в ходе выполнения могут эмитить новые события.
С диалогами/модалками/меню ситуация чуть сложнее. В текущей реализации они могут быть открыты с помощью тех же кастомных действий, но если вы хотите отобразить там динамический контент duit, то придется внутри виджета создавать дополнительный DuitDriver - это не классно.
Сейчас ведется активная работа на новой мажорной версией фреймворка, где одним из ключевых изменений как раз станет возможность работать с оверлеями и отображать в них динамический контент без создания дополнительных драйверов.
Подробнее о статусе разработки проекта можно узнать в его telegram канале и репозитории на GitHub
К сожалению, никакой уникальной информации не смог почерпнуть, все что есть в статье было сказано/написано уже много-много раз. Статья крайне поверхностная и про эволюцию я ничего не нашел: ни в контексте BDUI в целом, ни в контексте того, как это применяется в VK. Заявляю это как разработчик опенсорсного BDUI-фреймворка :)
Я ради интереса погуглил детали реализации такой фичи в Ruby и понял, что под капотом просто лежат принципиально разные механизмы. Ключевое отличие - разрешение вызовов в runtime (Ruby) против compile-time (Dart).
В Dart extension methods - просто синтаксический сахар, связывающий функцию (статическую) с определением класса. На самом деле под капотом класс никак не изменяется.
Думаю, от этого и идет порицание подобной фичи в Ruby.
Проверь эти 8 узких мест в производительности, прежде чем... перейти на Flutter и перестать страдать :)
Отличная статья!
Даже для "непосвященного" было очень познавательно и местами даже понятно)
Мюсли типичного кабаныча.
Работать надо не 12 часов, а головой. Вкалывайте сами, сударь.
P.S. Я, как разработчик BDUI фреймворка верю в то, что за BDUI будущее разработки приложений. Руководитель аутсорс компании верит в то, что вот-вот и будет и на его улице счастье.
Спасибо за статью! Жаль, что она не появилась года эдак полтора назад, когда я начинал заниматься своим проектом.
Сейчас я постепенно прихожу к тому же методу продвижения, что описан в статье. Сам я начал продвижение по другому пути - рассказываю о проекте на профильных конференциях. Выхлоп с них минимальный, звездочки и какой-то актив виде контрибьюторов и пользователей конфы особо не приносят, а времени отнимают достаточно много.
Пойду завоевывать сердца индусов!)
Мне кажется, что такое сравнение не совсем валидно по причине того, что в статье рассказывается о том, как люди избавлялись от повторяющихся частей JSON с помощью шаблонизации.
Сжатие, использование иных протоколов обмена данными - это другая сторона задачи по передаче как можно меньшего объема данных по сети, имхо.
Насколько оправдано использовать OpenGL ES, если новых версий не предвидится, а поддержка Vulkan все шире? Или до более менее существенного применения вулкана еще далеко и можно успеть все переписать? Часто такой такой подход можно встретить в продакшене?
Спасибо за комментарий!
Вы верно заметили, что "360" предполагает наличие людей, которые создадут процесс и проанализируют результат. В противовес этому выступаем метод Форда, простой, как палка. Но мне все-таки кажется, что не верно сравнивать эти два подхода, и вот почему:
- Обезличенная обратная связь, которую мы получаем в результате "360" может быть интересным чтивом, но реже станет почвой для того, чтобы задуматься о своем положении в коллективе. При ином методе исследования, мы получаем фидбек в "сыром" виде и интерпретируем его сами, проводя тем самым некоторую рефлексию)
- "360" требует административного ресурса, а значит - это инициатива "сверху". Описанный в статье метод - это реакция на запрос, который может присутствовать индивидуально у каждого сотрудника.
"Конструктивные" нападки на Flutter со стороны React Native разработчиков выглядят так - "мыши кололись, но продолжали кушать кактус". Достаньте голову из песка и сравните две технологии объективно.
Я перешел на Flutter после долгого периода работы с React Native и по достоинству оценил качество Flutter. Change my mind :)
Если смотреть на статью, как на туториал (что указано), то получился хороший get started гайд. Мне, как человеку далекому от C++, зачастую непонятно, как было бы "правильно" организовать исходник и собрать их с помощью сmake.
Другая сторона медали - обилие примеров кода библиотеки, которые напрямую не относятся к теме статьи. Можно ведь было сделать гораздо короче, и читабельность повысилась бы (многое я проскролил, мог упустить что-то важное).
И тем не менее спасибо за статью, давно хотел поэкспериментировать с плюсами и теперь есть отправная точка для этого :)
Отличная статья!
Я сам автор BDUI-фреймворка (для Flutter) и в вашей статье я смог найти множество идейных сходств с моим проектом, а также интересных концепций. Спасибо, что поделились опытом и отдельное спасибо за классные картинки, которые сопровождали статью :)
Подписываюсь под каждым словом. После перехода на Flutter мы получили опыт (как пользователи фреймворка) совершенно иного уровня.
Добрый день и спасибо за статью! Я тоже разрабатываю решением для SDUI под Flutter. Вы проделали большую работу, поддержав такое большое кол-во виджетов. Думаю, что даже смогу "вдохновиться" некоторыми деталями реализации на своем проекте :)
У меня есть несколько вопросов:
1. Поддерживает ли Nui анимации (implicit виджеты или анимации через контроллеры)?
2. Для кого подойдет ваше решение? Как я понял, экраны настраиваются/обрабатываются экшены в CMS, но есть ли вариант использования без этой обвязки, мб можно реализовать какой-то слой абстракций для работы Nui в формате standalone фреймворка?
Есть ли на данном этапе поддержка анимаций (implicit)?
З.Ы. Сорри, не прочитал внимательно заключение :)
Спасибо за комментарий!
Сразу хочу сказать - я не отменяю ни KMP (далее и везде под KMP подразумевается он сам и все что рядом с ним) ни Compose никоим образом. Это хорошие и перспективные технологии, которые найдут свою нишу 100%. Но с некоторыми вашими высказываниями я не согласен.
Архитектура. В этом разделе я говорил не о том, как происходит рендер, а о том, как можно добавить новый build target для конкретной технологии. В случае с KMP добавление нового таргета - прерогатив JetBrains. В случае же с Flutter, таргет можно поддержать самостоятельно, при наличии головы на плечах.
Количество команд. При миграции на KMP вы не избавляетесь от необходимости содержать IOS команду. Итого их уже две. Flutter, по понятным причинам, решает эту проблему.
По экономическому фактору абсолютно не согласен. Вы так уверенно выдвинули лидера, что я аж опешил) Вопрос слишком комплексный, чтобы так легко на него отвечать.
Касательно kotlin на бекенде... Как мне кажется, это либо свежие проекты, либо те проекты я которые достаточно хорошо поддерживались в рамках актуального стека. Вижу лица людей, у которых легаси-код на Java 6 - такие неповоротливые машины очень сложно поставить на новые рельсы.
В целом, я склонен утверждать, что каждый уважающий себя Шрек (читай разработчик) хвалит свое болото (язык, фреймворк), так что я не могу согласиться с тем, что преимущество Flutter лишь в том, что основной конкурент ещё в некоторой степени сырой :) Первый комментарий в этом плане позволяет взглянуть на ситуацию чуть шире.