Привет! Начну с конца - Nui полностью независим от Nanc, и может быть использован сам по себе без ограничений. Nanc (CMS) дополняет Nui песочницей и интерактивной документацией.
Любая анимация - это виджет. А любой виджет поддерживается Nui. Не все виджеты внедрены, но внедрить любой виджет можно за 10 минут - пару часов. Скажем - AnimatedSwitcher = 10 минут, Scaffold - пара часов.
Со сложными анимациями, завязанными на контроллеры посложнее. Если надо реализовать какое-то конкретное решение (готовый виджет с +- известной анимацией) - то это пустяк. Если же надо иметь возможность создавать полностью кастомную анимацию с контроллером и потом ей управлять - такое тоже возможно и даже поверх того, что есть сейчас (то есть без расширения функционала самого движка Nui), но хорошо подумать часа 4 точно придется.
Но это общий список, включая цели использования и CMS, просто мысленно отфильтруйте его только на Nui-фичи.
P.S. у меня проблемы с позиционированием, так как сделаны, по сути, два продукта в одном. И я их пока никак не разделяю. Это следствие того, что изначально я хотел создать решение проблемы, которое бы позволяло создавать UI и затем управлять им из одного места - из CMS.
Есть целые миры разработки, которые не имеют даже близко чего-то общего. В одной крайности до сих пор перемещают DOM на экране с помощью jQuery, получая за это 30-40 тысяч рублей в месяц. А в другой - разработчики не будут даже открывать полное описание вакансии, если где-то в сообщении от рекрутера проскочит слово на j. Так что, я думаю, и чистые верстальщики до сих пор существуют.
Касательно стоашности - безусловно я бы лично предпочёл обновить код приложения, дождаться отработки CI/CD и начать считать количество пользователей с новой фичей, но есть нюанс - даже если бы сторы делали ревью моментально - далеко не все пользователи обновляют приложения. Их можно заставлять, блокируя старые версии, но вы же не будете блокировать сразу предыдущую версию, при выпуске новой - есть риск, что юзер просто перестанет пользоваться приложением. И, по моему опыту, это главная причина, почему Server Driven UI имеет смысл - показывать новый контент всем пользователям сразу.
У вас будет виджет (от балды, назовем его NancListView), способный отрисовать что угодно (написанное на XML), на данный момент, минимальный размер этого виджета в рамках приложения - скроллящийся список. То есть вы можете встроить этот виджет в ваш существующий экран, или сделать отдельный экран из такого виджета и управлять им через CMS.
Ведется работа и по более маленькому размеру - атомарным виджетам. Работать это будет примерно так: Вы полностью создаете виджет через CMS, скажем - некую продуктовую карточку. Используете, условный NancWidget, передавая в него требуемые параметры, которые, по аналогии с {{ page.something }}, можно будет получать и в таком виджете. И теперь вы можете управлять через CMS тем, как выглядит этот виджет, полностью менять его, а через приложение, классическим путем - наполнять его данными. Фактически сохраняя классический способ разработки приложения и получая возможность изменять вид любого компонента через CMS.
Которая может быть использована с вашей текущей инфрой
И которая позволяет (дополнительно к основному CMS-функционалу) создавать UI с (пока небольшой) логикой, используя для этого XML с наименованием тегов, аналогичным наименованию виджетов во Flutter
Flutter-код из XML не генерится в прямом смысле слова. XML парсится в реальном времени, весь "экран", назовем его так, асинхронно преобразуется в виджеты, и затем используются только они.
Чтобы начать использовать достаточно всего одной потребности - "хочу править контент", затем, если "хочу иметь возможность создавать и обновлять экраны Flutter-апок динамически" - то в ход идет UI Builder (назовем его так).
Есть "из коробки", работающие хорошо. Плюс появляются интересные сторонние решения (первое попавшееся).
Воспользуюсь аргументом автора оригинальной статьи: "Вот impeller зарелизится, тогда заживем! 🙂". Если по существу - да, бывают "какие-то баги", которые визуально выглядят как лаги, к сожалению у меня нет iOS устройства под рукой, чтобы как-то погрузиться в причину там происходящего и оправдать Flutter более аргументированно, поэтому просто отвечу - ну ок, есть вот такой вот лаг при такой вот анимации на iOS
Вот у меня тоже есть ощущение (по крайней мере мой опыт именно такой) что почти все делают все кастомное, и это и есть стихия Flutter - на нем не нужно прикладывать усилий, чтобы все выглядело везде одинаково (кастомно), на RN я пока не писал, но есть ощущение, что на нем придется прикладывать дополнительные усилия, чтобы все выглядело одинаково.
Как я и упомянул, единственный (по моему мнению) объективный плюс RN - CodePush. Этот плюс у него есть и относительно нативных способов разработки, но значит ли это, что из-за этого плюса нативная разработка более не применима? Если нет - то это не значит того же и относительно Flutter. Потом, процесс тестирования (именно во время разработки) в случае с Flutter не является сколь бы то ни было сложным или долгим (с любых точек зрения) - если есть CI, то на любой чих можно сделать билды сборок, автоматически доставляемые в интересующий вас канал (например - Firebase Distribution), которые доступны для тестировщиков в течение нескольких минут. Поэтому разница в этом аспекте по сравнению с RN будет заключаться только в том, что тестировщику RN-приложения достаточно будет лишь открыть уже установленное приложение для тестов, а тестировщику Flutter-приложения - установить новую версию поверх старой (~ 1 минута - максимум).
Относительно публикации обновлений приложения "без сторов" - круто, все так, но зыбко. И я, с точки зрения бизнеса, не стал бы делать ставку на какую угодно технологию, полагаясь на серую зону и то, что она никогда не станет черной.
Не ко мне вопрос, но, предположу, что фикс конкретной проблемы (как я понял, проблема не в производительности как таковой, а в сочетании скорости обновления экрана и анимаций или отправке дебаг-эвента) - еще не влит в stable / не протестирован / еще что-то.
Добавленный сюда Xamarin - это стёб. Опять же, ничего не имею против, и это может быть тем, что когда-то выстрелит, но сейчас это совершенно не конкурент ни для Flutter, ни для React Native.
А вот с "невозможностью" переиспользования кода во Flutter - интересно. Какие у вас кейсы, что для веба Flutter не пригоден? И какие именно нативные плюшки вам нужны?
Приходится, иногда, работать в офлайне, но при этом все окружение и все зависимости были установлены при наличии интернета.
Мне кажется, самым простым будет получить, каким-нибудь образом, интернет на рабочей машине, установить окружение, запустить hello-world приложение, и после этого можно будет работать офлайн (но без новых зависимостей).
Либо повторить все это на машине с интернетом и перенести все это на машину без интернета.
Либо завести внешний жесткий, на котором вести всю разработку (пожалуй, последний вариант будет наименее болезненным).
Нет каких-то особых причин, кроме желания написать велосипед. Хотя можно было бы и обосновать это тем, что написав 50 строк кода я избавился от одной зависимости.
Авто-генерируемый фронт подойдёт для очень стандартных админок, сделать кастомный продукт таким образом не получится, а посему - генерация фронта решает очень малую выборку задач.
А по поводу унылости - интересное мнение) я последний год использую gRPC и он мне очень нравится.
Привет! Начну с конца - Nui полностью независим от Nanc, и может быть использован сам по себе без ограничений. Nanc (CMS) дополняет Nui песочницей и интерактивной документацией.
Любая анимация - это виджет. А любой виджет поддерживается Nui. Не все виджеты внедрены, но внедрить любой виджет можно за 10 минут - пару часов. Скажем -
AnimatedSwitcher= 10 минут,Scaffold- пара часов.Со сложными анимациями, завязанными на контроллеры посложнее. Если надо реализовать какое-то конкретное решение (готовый виджет с +- известной анимацией) - то это пустяк. Если же надо иметь возможность создавать полностью кастомную анимацию с контроллером и потом ей управлять - такое тоже возможно и даже поверх того, что есть сейчас (то есть без расширения функционала самого движка Nui), но хорошо подумать часа 4 точно придется.
Для кого подойдёт, хорошо расписал вот здесь:
https://nanc.io/docs/introduction#for-which-purposes-nanc-is-better-suited
Но это общий список, включая цели использования и CMS, просто мысленно отфильтруйте его только на Nui-фичи.
P.S. у меня проблемы с позиционированием, так как сделаны, по сути, два продукта в одном. И я их пока никак не разделяю. Это следствие того, что изначально я хотел создать решение проблемы, которое бы позволяло создавать UI и затем управлять им из одного места - из CMS.
Есть целые миры разработки, которые не имеют даже близко чего-то общего. В одной крайности до сих пор перемещают DOM на экране с помощью jQuery, получая за это 30-40 тысяч рублей в месяц. А в другой - разработчики не будут даже открывать полное описание вакансии, если где-то в сообщении от рекрутера проскочит слово на j. Так что, я думаю, и чистые верстальщики до сих пор существуют.
Касательно стоашности - безусловно я бы лично предпочёл обновить код приложения, дождаться отработки CI/CD и начать считать количество пользователей с новой фичей, но есть нюанс - даже если бы сторы делали ревью моментально - далеко не все пользователи обновляют приложения. Их можно заставлять, блокируя старые версии, но вы же не будете блокировать сразу предыдущую версию, при выпуске новой - есть риск, что юзер просто перестанет пользоваться приложением. И, по моему опыту, это главная причина, почему Server Driven UI имеет смысл - показывать новый контент всем пользователям сразу.
Буквально сегодня вышло видео в тему:
https://youtu.be/71eUes30gwc?si=hudesegSUn9BwRbg
У вас будет виджет (от балды, назовем его
NancListView), способный отрисовать что угодно (написанное на XML), на данный момент, минимальный размер этого виджета в рамках приложения - скроллящийся список. То есть вы можете встроить этот виджет в ваш существующий экран, или сделать отдельный экран из такого виджета и управлять им через CMS.Ведется работа и по более маленькому размеру - атомарным виджетам. Работать это будет примерно так:
Вы полностью создаете виджет через CMS, скажем - некую продуктовую карточку. Используете, условный
NancWidget, передавая в него требуемые параметры, которые, по аналогии с{{ page.something }}, можно будет получать и в таком виджете. И теперь вы можете управлять через CMS тем, как выглядит этот виджет, полностью менять его, а через приложение, классическим путем - наполнять его данными. Фактически сохраняя классический способ разработки приложения и получая возможность изменять вид любого компонента через CMS.Спасибо!
Это стоит рассматривать как:
CMS
Которая может быть использована с вашей текущей инфрой
И которая позволяет (дополнительно к основному CMS-функционалу) создавать UI с (пока небольшой) логикой, используя для этого XML с наименованием тегов, аналогичным наименованию виджетов во Flutter
Flutter-код из XML не генерится в прямом смысле слова. XML парсится в реальном времени, весь "экран", назовем его так, асинхронно преобразуется в виджеты, и затем используются только они.
Чтобы начать использовать достаточно всего одной потребности - "хочу править контент", затем, если "хочу иметь возможность создавать и обновлять экраны Flutter-апок динамически" - то в ход идет UI Builder (назовем его так).
Есть "из коробки", работающие хорошо. Плюс появляются интересные сторонние решения (первое попавшееся).
Воспользуюсь аргументом автора оригинальной статьи: "Вот impeller зарелизится, тогда заживем! 🙂". Если по существу - да, бывают "какие-то баги", которые визуально выглядят как лаги, к сожалению у меня нет iOS устройства под рукой, чтобы как-то погрузиться в причину там происходящего и оправдать Flutter более аргументированно, поэтому просто отвечу - ну ок, есть вот такой вот лаг при такой вот анимации на iOS
Вот у меня тоже есть ощущение (по крайней мере мой опыт именно такой) что почти все делают все кастомное, и это и есть стихия Flutter - на нем не нужно прикладывать усилий, чтобы все выглядело везде одинаково (кастомно), на RN я пока не писал, но есть ощущение, что на нем придется прикладывать дополнительные усилия, чтобы все выглядело одинаково.
Как я и упомянул, единственный (по моему мнению) объективный плюс RN - CodePush. Этот плюс у него есть и относительно нативных способов разработки, но значит ли это, что из-за этого плюса нативная разработка более не применима? Если нет - то это не значит того же и относительно Flutter. Потом, процесс тестирования (именно во время разработки) в случае с Flutter не является сколь бы то ни было сложным или долгим (с любых точек зрения) - если есть CI, то на любой чих можно сделать билды сборок, автоматически доставляемые в интересующий вас канал (например - Firebase Distribution), которые доступны для тестировщиков в течение нескольких минут. Поэтому разница в этом аспекте по сравнению с RN будет заключаться только в том, что тестировщику RN-приложения достаточно будет лишь открыть уже установленное приложение для тестов, а тестировщику Flutter-приложения - установить новую версию поверх старой (~ 1 минута - максимум).
Относительно публикации обновлений приложения "без сторов" - круто, все так, но зыбко. И я, с точки зрения бизнеса, не стал бы делать ставку на какую угодно технологию, полагаясь на серую зону и то, что она никогда не станет черной.
Не ко мне вопрос, но, предположу, что фикс конкретной проблемы (как я понял, проблема не в производительности как таковой, а в сочетании скорости обновления экрана и анимаций или отправке дебаг-эвента) - еще не влит в stable / не протестирован / еще что-то.
В том же issue есть по меньшей мере две отсылки к тому, что проблема решена
Добавленный сюда Xamarin - это стёб. Опять же, ничего не имею против, и это может быть тем, что когда-то выстрелит, но сейчас это совершенно не конкурент ни для Flutter, ни для React Native.
А вот с "невозможностью" переиспользования кода во Flutter - интересно. Какие у вас кейсы, что для веба Flutter не пригоден? И какие именно нативные плюшки вам нужны?
https://docs.flutter.dev/perf/shader
device_preview
Зато работает состояние, когда не работает веб)
Мне кажется, самым простым будет получить, каким-нибудь образом, интернет на рабочей машине, установить окружение, запустить hello-world приложение, и после этого можно будет работать офлайн (но без новых зависимостей).
Либо повторить все это на машине с интернетом и перенести все это на машину без интернета.
Либо завести внешний жесткий, на котором вести всю разработку (пожалуй, последний вариант будет наименее болезненным).
Нет каких-то особых причин, кроме желания написать велосипед. Хотя можно было бы и обосновать это тем, что написав 50 строк кода я избавился от одной зависимости.
Я думаю, он дойдет до публикации в стопах, пока все ещё в процессе написания
Можете ли поделиться тестовыми проектами (1. 2. 3)? Особенно интересен 3.
adb rootтоже работает, то получится ли через adb сделать unpinning (чтобы не пересобирать apk - большой вопрос)Спасибо, буду ковырять
Авто-генерируемый фронт подойдёт для очень стандартных админок, сделать кастомный продукт таким образом не получится, а посему - генерация фронта решает очень малую выборку задач.
А по поводу унылости - интересное мнение) я последний год использую gRPC и он мне очень нравится.