Привет, Хабр! Меня зовут Сергей, я занимаюсь мобильной разработкой 13 лет и недавно стал руководителем разработки мобильного приложения «Пункты выдачи заказов» в Ozon. Невольно став сместителем существующего строя в проекте (фреймворки, технологии, подход), я стал часто слышать вопрос: «Почему вы отказались от Flutter?».
Слышал я этот вопрос прежде всего от разработчиков моей команды и соискателей на наши вакансии, потом во время доклада на эту же тему на конференции Panda Meetup, в конце концов, даже менеджер нашего проекта подошёл с вопросом: «Ну а всё же почему?». Настолько людей захватывает эта тема, что я решил поделиться развёрнутым ответом.
Начнём с ответа на вопрос: «Почему изначально был выбран Flutter ещё год назад?» Попробуем разобраться в технических нюансах.
Чем хорош Flutter?
Мультиплатформенность — то, чем Flutter подкупает прежде всего
Менеджеры всех времён недоумевали: зачем писать одно и то же под разные платформы (iOS, Android), а потом ещё и для Web и, возможно, для десктопа? Поэтому с незапамятных времен мир был наводнён различными средствами разработки, помогающими объединять разработку для всех платформ в одном проекте — на одной кодовой базе и даже одном языке программирования. Среди них были и даже остаются FireMonkey, Qt, Xamarin, React Native и тот самый Flutter, который во многом опережает своих предшественников: на нём можно писать неплохие приложения одновременно и под iOS, и под Android. Да, и кроме мобилок были попытки затащить в наш проект и Web на Flutter, но безуспешные.
Google-Contributed
Гигант настолько увлёкся своим детищем (ну да, я про Dart от Google), что выпустил целую операционную систему Fuchsia OS, интерфейс которой построен на Dart. Внушает и оптимизм за будущее Flutter, и страх за будущее Android.
Давайте заглянем под капот Flutter и обнаружим, что там находится язык Dart — тот самый, который Google изобрела в качестве замены JavaScript в браузерах, а затем он применялся в бэкенд-разработке, пока не стал частью Flutter. В новой среде разработки Dart был немного доработан, и, если говорить про Web, то компиляция происходит в язык JS, а если про мобилки — то в машинный код. Если первый случай теоретически может привести к потере производительности, то второй должен как минимум не уступать. На схеме ниже видно, за счёт чего Flutter опережает в быстродействии своих мультиплатформенных конкурентов-предшественников. Источник
Open source
Говоря про популярность Flutter, стоит отметить, что он открыт и бесплатен: если вдруг Google бросит проект, исходный код останется доступен всем — и вы сможете его поддерживать вместе с комьюнити.
Декларативный подход
Наибольшую популярность Flutter сыскал среди разработчиков благодаря декларативному подходу в реализации интерфейсов, и этот подход значительно ускоряет разработку.
Совместимость с Native
Дисклеймер: под Native в данной статье я буду иметь в виду нативные языки и фреймворки для разработки под iOS и Android.
Последним преимуществом Flutter можно выделить возможность затащить в проект код на Native. То есть, например, специфическое определение геолокации, которая работает по регионам, вы не найдёте из коробки среды, поскольку оно присутствует только на iOS и не было смысла затаскивать его во Flutter. Но не стоит расстраиваться — Flutter позволяет внедрять код, написанный на Swift, в виде плагина и использовать данную возможность, специфичную для iOS и только для iOS. Такая же возможность есть и у других платформ при работе с Flutter, поэтому тем, кто считает, что «Flutter не умеет всё» можно ответить: «А что не умеет — научим на Native».
Данной иллюстрацией пищевой цепочки мультиплатформенной разработки завершаю рассказ о преимуществах Flutter.
Я осознанно не стал упоминать о Kotlin Multiplatform Mobile (KMM) как о ещё более молодом конкуренте, поскольку для меня очевидно, что его развитие в скором времени приведёт Flutter к участи React Native и Xamarin, с которых я уже имел «счастье» переписывать приложения на Native. Думаю, сейчас, в 2022 году, ко мне бы не подошли с аналогичным вопросом о переписывании с React Native. Хотя раньше мне приходилось проходить тот же путь — доказывать бизнесу необходимость и целесообразность переписывания React Native-приложения на Native. Я думаю, что этот поток вопросов о Flutter не утихнет, пока Kotlin Multiplatform Mobile, вангую, — не вытеснит Flutter с пьедестала почёта. На сегодняшний день статистика на этот счёт пока молчит.
Чем же Flutter уступает Native?
̶N̶a̶t̶i̶v̶e̶ ̶k̶i̶l̶l̶e̶r̶ Google Killed
Даже если каким-то чудом KMM не станет вершиной мультиплатформенной программистской мысли, у меня для вас печальные известия: Google славится внезапным закрытием проектов, и Flutter в любой момент может занять топовое место на кладбище гуглопроектов. Правда, в какой-то момент корпорация, так же, как поступила с Dart, может внезапно воскресить Flutter и, например, начать использовать его для программирования чипов, вживляемых людям через прививки, будь то Pfizer или Спутник V. Хотя о чём это я? Неее, скорее всего, этим будет заниматься Google Daydream.
Dart так себе язык
Тут все будут ждать какое-то обоснование, но я просто собрал отзывы вкусовых предпочтений у разработчиков, которые не пожелали оставаться на Flutter. Перегруженный лишними конструкциями синтаксис, точки с запятой и так далее — просто исчадие Java. А Android-разработчики будто на Kotlin с Java побежали от хорошей жизни. А почему, собственно, KMM может опередить Flutter? Вот, например, давайте посмотрим на Dart: когда в него завезли null safety? Правильно, только весной 2021 года, а ведь это базовый механизм статической типизации. Сколько лет меняется Dart — и только сейчас в нём появилось то, что было доступно в первых версиях Swift и Kotlin семь лет лет назад. Зато есть подобие coroutines, что прекрасно для экс-бэкенд-языка.
Сообщество платформы
Конечно, прекрасно, что Flutter можно посмотреть в исходниках, как и увидеть, сколько issues сейчас открыто в официальном репозитории: их количество только растёт — это говорит о том, что команда пока не справляется с потоком ошибок. Например, только совсем недавно сделали, чтобы анимации не тормозили на iOS ¯_(ツ)_/¯
Фреймворки пока тоже сыроваты: при малейшем отклонении программы от обычного документооборота в сторону специфики железа писать вам и так и так придётся на Native. Например, с чем столкнулась моя команда: камера (сканер кодов — это основной функционал, очень критичный компонент для нашего приложения) тормозит и глючит с подсветкой. Когда мы начинали делать этот компонент, во Flutter ещё не было готового решения (сейчас оно существует, но за качество не ручаюсь). Ещё для сохранения состояния приложения использовался сторонний компонент Hive и в какой-то момент обновления библиотеки состояние приложения обнулилось: оказалось, что в компоненте уже известны несколько критичных багов, и почему-то их никто не стремится исправить. В остальном, после того как во Flutter, наконец, пофиксили проблемы с анимацией, кажется, можно «жить», если ваше приложение содержит простую функциональность.
Собственный UI, характерный для обеих мобильных платформ
Ранее я упоминал, что у Flutter свой собственный рендеринг — это означает, что поведение визуальных компонентов (курсора в поле ввода, контекстного меню, анимации, навигации экранов, и прочее) отличается от принятого на каждой из платформ. Всё это может несколько озадачить пользователя вашего приложения.
Инфраструктура
В поисках инфраструктурных решений как нативный iOS-разработчик я натыкался чаще всего на Stack Overflow, посвящённый проблемам с Flutter: сбою работы CocoaPods или fastlane при сборке проекта.
Если вы захотите завести автотесты, у вас также могут возникнуть препятствия. В Ozon принято использовать Appium: когда пытались завести его через специальный драйвер, то при тестировании приложения он постоянно отваливался. Если у вас есть какой-то положительный пример автотестирования, делитесь в комментариях, какой вы инструмент использовали и с чем сталкивались.
И всё-таки кому нужен Flutter?
Несмотря на некоторые негативные моменты, которыми Flutter озадачивает нашу команду на поддержке старой версии приложения до сих пор, на мой взгляд, эта технология хорошо подходит для решения некоторого круга задач:
Абсолютно бескомпромиссный документооборот (только, пожалуйста, без использования камеры).
Стартапы для прототипирования — тот класс проектов, в которых надо быстро проверить гипотезу, чтобы принять решение, развивать дальше продукт или выкинуть.
Разработка по DDD (уверяю, это был не наш случай).
Достоинства и недостатки Flutter (в сравнении с Native)
№ |
Достоинства Flutter |
Недостатки Flutter |
1 |
Мультиплатформенность |
Нестандартное поведение компонентов на платформах |
2 |
Google-Contributed (поддержка IT-гиганта) |
May be killed by Google (поддержка внезапно может прекратиться) |
3 |
Dart компилируемый, хорошая производительность |
Разработчики предпочтут Swift или Kotlin нежели Dart |
4 |
Open source / freeware |
Качество фреймворков пока оставляет желать лучшего |
5 |
Декларативный UI |
На Native теперь есть SwiftUI и Jetpack Compose, аналогичные Dart |
6 |
Возможность совмещать с Native |
Отсутствие специфических функций во фреймворках, приходится их писать на Native |
7 |
Популярен, затмевает React Native |
Может быть вытеснен Kotlin Multiplatform Mobile |
Мы всё взвесили — и решили переехать на Native
А теперь подойдём поближе к нашему проекту мобильного приложения для ПВЗ (пунктов выдачи заказов). С его помощью сотрудники ПВЗ выдают посылки, ищут заказы по номеру или штрихкоду, перемещают товары на полках, принимают возвраты, учатся на Ozon Learning и многое другое.
Итак, наступил момент, когда наш продукт из стартапа с документооборотом решил перерасти в долгоиграющий проект, бизнесу захотелось перейти от количественного к качественному: более нативного поведения и вообще, чтобы ставили только пять звёзд. Как убедить бизнес, что нужно всё переписать на Native? И вообще надо ли? А что будет с командой? Захотят ли спецы на Flutter возвращаться на старый добрый Native-стек?
План перехода на Native
Мы разработали план, чтобы не облажаться:
Составили роадмап разработки минимального функционала (соответствующего версии, которая была написана на Flutter).
Произвели поиск решений внутри компании и обнаружили достаточно мощное движение в поддержку Native и готовые компоненты, выделенные в отдельные SDK, что ускорит переписывание.
Продумали адаптацию команды: нам важно не растерять ценных сотрудников, хорошо знакомых с тонкостями проекта.
Перейдут ли с Flutter на Native разработчики?
Flutter, безусловно, искушает разработчиков тоже перейти на него и оставаться на нём, но можно принять меры в Native и вернуть их на светлую сторону.
Декларативный UI
И тут сам Flutter подсказал решение: он как катализатор развития мобильных платформ подтолкнул их к созданию альтернативных решений для Native — речь идёт о SwiftUI и Jetpack Compose.
Взгляните на листинги кода для интерфейсов: декларативный подход теперь доступен на Native, и он аналогичен таковому во Flutter, причём оценки аналитиков нашего и другого проекта компании показали возможность использования таких технологий.
Единое решение
Кроме того, было принято решение использовать единую архитектуру в мобильном приложении для обеих платформ, делать перекрёстное и межплатформенное ревью, чтобы идти в одном направлении.
Инфраструктура
Ну и наконец, проблемы с автотестированием просто исчезнут, так как даже внутри Ozon уже есть много опробованных технологий на Native. Отмечу, что 80% времени, отведённого на тестирование, мы тратим на написание автотестов, так что у нас нет исключительно ручных тестировщиков.
Заключение
Время покажет, насколько верным было наше решение. С начала переписывания прошло всего полтора месяца, и пока я могу похвастаться тем, что обе команды — и Android, и iOS — идут с опережением графика, согласно составленному роадмапу, несмотря на то, что технологии для разработчиков обеих платформ новые.
Из интересного замечу, что межплатформенное ревью, которое мы провели в начале года, позволило перенять опыт и лучшие практики команд каждой платформы. iOS и Andoid и правда выглядят как братья-близнецы, но при этом, в отличие от Flutter проекта, имеют собственные (платформенные) характеры.
Комментарии (87)
vmityuklyaev
31.01.2022 13:35+2Наконец-то тайна почему в Озоне ушел флаттер - теперь раскрыта. Спасибо за статью)
ookami_kb
31.01.2022 13:37+11Вот эти все качели: "А давайте всё перепишем на Flutter", "А давайте всё вернем обратно на натив" – вызывают подозрение, что анализа на предмет: "А нужен ли здесь Flutter?" не проводилось.
Google killed. Это можно сказать про любую технологию. Какая компания будет годами поддерживать и развивать продукт, который ей больше не нужен?
Dart так себе язык. А с самого начала не видно было, какой это язык? Тем более, что раньше он был хуже – все-таки он достаточно активно развивается. Ну и замечание про "экс-бэкенд" не понял – он же как раз был представлен изначально, как "более лучший яваскрипт", при чем тут бэкенд?
Сообщество платформы. А сколько этих issue в других фреймворках?
Собственный UI. Ну так для каких-то проектов это наоборот преимущество. Опять же, это было известно с самого начала, или это "вдруг" выяснилось через полгода разработки?
Касательно комикса про ожидание от одного Flutter-разработчика. Так это никогда так не работает. Я писал про это 3 года назад:
So this equation:
2 Flutter guys = 2 Android guys + 2 iOS guysis totally wrong, but this one:
1 Flutter guy + 1 Android guy + 1 iOS guy = 2 Android guys + 2 iOS guyslooks more like a truth for me.
Практика показала, что где-то так оно и есть.
SofBix Автор
31.01.2022 14:02+2"Ну и замечание про "экс-бэкенд" не понял –"
Это был сарказм адресованный async await. Ведь в Native он появился позже, чем в Dart, ИМХО полезность фичи прям очевидна, но увы больше в бэкенд разработке.ookami_kb
31.01.2022 14:07+3Не вижу никаких причин ей быть менее полезной на одном "-енде", чем на другом. Везде, где есть асинхронность, async-await может быть удобным. А может и не быть. It depends.
virtusha
31.01.2022 13:48+19Мне показалось, что все описанные проблемы Флаттера зауши притянуты
Ivanzabu
01.02.2022 19:14+7А я наоборот полностью с автором статьи согласен - тоже пробовали флаттер в одно время, и все хорошо, но только до тех пор, пока ты не не отклоняешься от рамок фреймворка ни на шаг - как только тебе нужно какие-то более хардварные фишки (та-же камера) - сразу становится очень больно.
И остальные описанные проблемы тоже имеют место быть и сильно замедляют разработку - будь то сырые фреймворки или необходимость писать два раздельных ui если хочешь выглядить хотя-бы более менее нативно.
Но в те времена когда мы пытались - самая большая проблема была в межслойных багах - когда делаешь что-то несколько нестанадртное и получаешь неопределенное поведение, которое непонятно на какой стороне неопределенное - сломался флаттер, платформа, их взаимодействие друг с другом или код который ты написал неправильный - и если он неправильный то почему (взаимодействие native -> flatter -> native может быть крайне неочевидным)
allswell
02.02.2022 18:07сейчас с камерой на flutter все хорошо, довольно стабильно работает, плюс дописали плагины для web и windows (пр на днях вмержится в мастер) для использования web-камер
Ivanzabu
02.02.2022 18:47Верю, но кажется что flutter как и например web в мобилках пока находится в ситуации вечно отстающего, и эта пробелма, которую можно решить только сделав его нативом для платформы.
В нативе постоянно появляются новые фишки и api, поддержка формфакторов девайсов. Зачастую они дают какие-то конкурентные преимущества (та-же camera2api которая позволяет получать лучше обрабатывать снимки и проще их получать), их имеет смысл сразу внеднять в приложение (но не во все конечно, есть те в которые вообще ничего не надо никогда), а в флаттере/web эта штука появляется с большим опозданием (коробочное решение уровня api которое можно использовать без влезания в натив), и это может сделать приложение неконкурентным с нативом.Пуши, геолокация, камера - это сейчас все и в веб приложении провернуть можно, но оно появилось в поддержке в вебе сильно позже чем в нативе на мобилках, и как итог - те кому нужны были стабильные пуши - сделали приложение.
С другой стороны те, кому не нужны эти фишки, вообще могут не делать приложение а обойтись мобильной веб версией.
Получается флаттер перспективно выглдяит если на нем делать веб + ios + android (с windows 11 в подарок) например - скорее как альтернатива мобильной веб версии с плюсами приложения, чем как замена нативных приложений.
irbis_al
31.01.2022 13:55+3А вот с камерой поясните..Почему вы не используете ТСД (Терминалы сбора данных)...Специально обученное устройство для складов ,чтения (мгновенного) QR кодов различного типа и штрих кодов различного типа...Это устройство в котором есть сканер штрихкодов(с аппаратным декодированием ) и специальная камера с SDK для декодирования этикеты как у Вас на фото(Типа отделить тект от цены от штрихкода)...(Отказ от ТСД ведь не из-за экономии?) В этом случае всё делаеться нативным sdk производителя,а вам отправляется broadcust ,который легко плагином отлавить во flutter.И если чтение штрихкода (разбор этикетки)является камнем преткновения,то в этом случае(ТСД) и проблемы то нет.
SofBix Автор
31.01.2022 18:48+3Возможно вы и правы, ТСД, которые мы кстати использем для Web версии пунков выдачи заказов, стоит адаптировать и под мобилки, уверен мы еще вернемся к этой теме, могу только сказать что мобильный телефон удобен как раз своей мобильностью, а приделывать к нему еще и сканер, да еще который может привести к потери автономности мобилки - все это уменьшит преимущества, ну мы просто спрашивали наших сотрудников, которые пользуются приложением. Тем не менее спасибо за идею, возможно сотрудники ПВЗ изменят свое мнение и мы вернемся к теме ТСД.
pesh1983
01.02.2022 10:32Что характерно, одно время ваши сотрудники всё-таки пользовались сканером, потом перешли на мобилки.
SofBix Автор
01.02.2022 10:45+3Я бы не сказал, что все перешли прям целиком со сканеров, на данный момент мобилками чаще пользуются как бекапом, то есть свет вырубили или вайфай сдох - тогда достают телефон. Одной из главных задач у нас сейчас повысить качество приложения чтобы им чаще пользовались.
raptor
01.02.2022 22:51+1Сканером пользуются, т.к. функционала в самом веб-приложении существенно больше
Пикнуть сканером посылку - все равно удобнее и быстрее, особенно когда их проходит 200-300 штук, а надо за час все обработать.
Как Сергей написал выше, приложение самый незаменимый вариант, если вдруг отключился свет или основная линия интернета упала. Приемка и выдача идут без перебоев
wellx
03.02.2022 13:00А варианты мобмльных терминалов не рассматривали?
как пример:
https://www.zebra.com/us/en/products/mobile-computers/handheld.html
да и на али тоже много разных, и весьма продвинутых
хотя и зебра не так уж и дорогая, в рамках средних мобил
заодно и куар коды считывает от ковида :) )
alexandrim
31.01.2022 14:27+12Возможно, забыли упомянуть аргумент против Flutter, что он отнимает рабочие места у native разработчиков, которые много лет инвестировали в native платформы.
mmmisha
31.01.2022 18:51+7В наше время ли говорить о недостатке рабочих мест, когда на одного соискателя сотня вакансий).
alexandrim
31.01.2022 21:31+1Это была попытка в шутливой и мягкой форме критиковать аргументы автора статьи :)
SofBix Автор
01.02.2022 10:50+5так вам ответили не в менее мягкой форме, что нативщиков сейчас с огнем не сыщешь, они скорее боятся почту открывать, как бы кто не схантил.
mmmisha
01.02.2022 13:39Угадали, прямо в точку). Я простой опытный нативщик, уже поднял себе ожидаемую ЗП в 3 раза, и все равно, несколько десятков писем с предложениями в день.
AlexWoodblock
31.01.2022 18:56+5отнимает рабочие места у native разработчиков, которые много лет инвестировали в native платформы
Ну-да, ну-да, это все заговор злых нативных разработчиков, а вовсе не корявоватый фреймворк, в котором для полноценной разработки все равно нужны эти проклятые нативные разработчики :)
alexandrim
31.01.2022 21:30+3Разумеется, это нарочито слабый аргумент и его задача лишь подчеркнуть слабость и притянутость аргументов из статьи.
AlexWoodblock
31.01.2022 22:33+1А, а я дурак старый, не разглядел. Прошу прощения за ерничание.
В свою защиту могу сказать только то, что такой аргумент я действительно встречал на просторах интернета...
Хотя, если честно, пункты 4 и 5 вполне себе важны. Переизобретенный UI вполне себе может отталкивать пользователя (сам столкнулся со странным скроллингом в Jetpack Compose). Ну а разрабатывать, когда у тебя постоянно что-то отваливается - удовольствия мало, так что пункт 5 тоже вполне себе верен.
slavap
31.01.2022 14:28+7Странная статья, и странные намёки на KMM. Kotlin тоже так себе язык, и Java до сих пор вполне себе жива, да и со звездами на github не очень против Flutter например.
mmmisha
31.01.2022 18:02+1Тем не менее, судя по результатам опроса в конце статьи, большинство согласно с автором, и большинство считают Kotlin лучшим языком.
slavap
01.02.2022 05:04+3Ну да, 23% vs 20% - это убедительная победа Kotlin :-) Учитывая число открытых Flutter багов на github, KMM ждёт впереди долгий и трудный путь, и не факт что JetBrain сможет его осилить.
Sigest
01.02.2022 07:58+3Ну так и джаве сколько лет по сравнению с котлин, а котлин, хоть и моложе, но уже где-то опережает джаву. Меня самого долго ломало переходить на котлин, я считал этот язык каким-то несерьезным что ли. Но когда перешел, на джаву без боли смотреть не могу, хотя считаю, что она наконец поднажала и старается догнать котлин в удобстве и новом функционале. Я может быть когда-нибудь и вернусь на джаву, ибо котлин, в стремлении закрыть недостатки джавы, их закрыл, но при этом добавил свои недостатки и костыли. Но при этом взросление котлина, я считаю, пока более динамичное, и недостатки и баги исправляются быстрее.
slavap
01.02.2022 12:06-2Вообще-то Java8 and Java17 не одно и тоже - на какую после Kotlin "смотреть не могу" ? А на Dart после Kotlin как смотрится?
Neikist
01.02.2022 13:27Дарт после котлина вообще ни о чем. Сам флаттер в принципе понравился, а вот дарт…
slavap
01.02.2022 16:05Ну 'вообще ни о чём' - это детский сад какой-то. Понятно, что Kotlin побогаче, но разница не фатальная точно. Примеры можешь привести?
Neikist
01.02.2022 18:14+2По большому счету мелочи, но этих мелочей просто слишком много. Что то из этого в дарте достигается костылями и кодгеном — но тоже раздражает.
Да блин даже автокомплит для котлина лучше работает чем для дарта. Вот по совокупности этого всего у меня такое впечатление и сложилось.
Sigest
01.02.2022 19:00+2Я расматриваю эти два языка вне версий, так как от версии к версии в них меняется не сильно. Хотя в джаве конечно больше функционала завозят в последние годы, то что в котлине завезли с самого начала. Тем не менее, я не думаю что в Java17 добавили/когда либо добавят то, что я люблю в котлине. Null safety, от которого я в самом начале работы с котлином просто плевался, а сейчас жить не могу. Optional очень слабый конкурент удоству null safety. Максимально удобная функциональщина, и то, как это сделано в джаве - у меня просто кровь из глаз. Функции расширения и многое другое.
На dart я пока никак не смотрю, я бекенд разработчик. Но в планах есть пойтив мобильные разработчики, но я любо перейду на нейтив-андроид, либо на KMM, потому как мысли, выраженные автором я читал много где. Ну и поэтому я думаю, что Flutter я все же пропущу.
slavap
01.02.2022 23:31+1Напрасно,попробуй Flutter - он простой, плюс внятная документация. И null safety в Dart есть.
Sigest
02.02.2022 08:01С удовольствием для развития кругозора, но хотелось бы почитать аргументы Dart vs. Kotlin, KMM vs. Flutter. В данной статье автора они не приводятся. Ибо для меня, например, пока преимущества одного против другого не очевидны, кроме одного пункта в пользу котлина - я его уже знаю
slavap
02.02.2022 12:12-1KMM пока сырой (я о Compose Multiplatform, иначе UI будет разный), Flutter весьма стабильный и UI полностью переносимый. Kotlin vs Dart - нет особой разницы, я ежедневно пишу на Java и Dart переключаюсь без усилия вообще.
vmityuklyaev
01.02.2022 12:38И правда интересно было посмотреть результаты опроса. Наверное, каждый голосовал за свой язык, на котором он пишет, плюс еще те, кто работал с несколькими. Поэтому, может быть, опрос показывает сколько зашло в опрос Swift / Dart / Kotlin разработчиков)
Но все равно интересно посмотреть распределение
debug45
31.01.2022 14:33+3Из-за «Native» вместо «натив» в заголовке подумал, что вы перешли на React Native в итоге, а не на нативщину
Tuwogaka
31.01.2022 14:42+2Для конкретной задачи - объяснено, но не исчерпывающе. Есть ли в двух версиях, для iOS для Андроид, общий код, пресловутая "бизнес логика"? Если нет и всё приложение в основном интерфейс и специфика платформ, подозрительно прозвучала камера, тогда вопрос только в том, что перевешивает - специфика платформ или готовность пользователей, а кто сотрудников то спрашивал, терпеть странноватый интерфейс. Если, типа, перевесило нежелание подгонять камеру под Флаттер, то не изволит ли автор сиё подтвердить?
Если есть, то неужели её пишут дважды? Или трижды ибо бэкенд. Может быть на Котлин, раз уж КММ так воспета? Не будет ли у автора, не достигая границ нарушения корпоративной этики путём разглашения ноу-хау разумеется, возможности уточнить?
Как КММ потеснит Флаттер я не понял. На сейчас тенденция - сливаться в экстазе. Мак с iPad, Андроид с Windows. Флаттер практически достиг полной кросс-платформенности, Эппл + Гугол + Микрософт + Интернет, а Kotlin Native пока (всё ещё) в альфе. И за оставшиеся пол года до WWDC и сопутствующего ему указания каждому его места - из неё не выйдет. Отсюда и КММ - то самое Мобайл актуальность которого уходит в прошлое.
Соответственно, Гугол пока не может убить Флаттер поскольку тогда полностью кросс-платформенное противостояние с Эппл, которое будет по любому, окажется без его участия и вне его контроля. Микрософт ведь тоже шевелится...
SofBix Автор
31.01.2022 18:01вижу кажется 2 вопроса:
- Почему вас только камера беспокоит, там по тексту много разных компонент и инфраструктурных вопросов поднималось, не хочется перестраивать процессы по автотестам ни библиотеки аналитики через плагин тащить, ни гайды дизайнеров расшаренные на натив, не хочется при редизайне заного рисовать компоненты визуальные, которые шарятся по командам на натив.
- Бизнеслогика есть во всех приложения, много ли, мало ли ее - в этом вся разница. На мой взгляд ее не достаточно в нашем приложении для того чтобы скрещивать Native и еще что то, ну например KMM. Бизнеслогику можно вынести на сторону сервисов. Если тащить все таки в клиенты, то получим франкинштейн, до такой необходимости и неизбежности опять же недотягиваем
Mox
31.01.2022 15:47+5Кажется что это рациональное обоснование эмоционального выбора.
На go же все пишут и не парятся про то что гугл убъет проект. Кажется что на Flutter слишком сильная ставка для того чтобы его убить.
Dart да - так себе. Зато хот релоад хорош. Хотя мне после TypeScript / React Native эстетически не заходит.
Kotlin разрабатывается JetBrains, и пытаются с JetPack Compose догнать Flutter. Но точно также может быть разорван контракт с JetBrains
Если для камеры нужно писать нативный код, зачем весь остальной делать нативным. Можно написать свой плагин просто.
По поводу опережения графика - а народу то в сумме больше или меньше фигачит?
Ну то есть с точки зрения трат мне кажется выбор странноватым. Вот клиентское приложение точно должно быть нативным, тут вопросов нет.
SofBix Автор
31.01.2022 18:41Я бы сказал что это было рациональное обоснование того выбора, который был сделан в пользу Flutter в самом начале, ведь он более чем оправдан. Сейчас это уже не обоснование, а констатация фактов пройденого опыта, эксперемент завершен, проект продолжается с новыми силами.
Про плагин камеры согласен, еслиб это была одна проблема и было в компании куча энтузиастов ее решить никто бы не парился, и учитывая что плагинов пришлось бы еще немало написать, тут я планы не могу рассекречивать, но они правда есть, смысл во Flutter потеряется бы довольно быстро
народу стало меньше, я не стал этим козырять ибо сравнивать с Flutter проектом некорректно, он шел не по роудмапу, а по иттерационным изменениям, нам проще так как знаем точку, в которую должны придти.
Я бы сказал что выбор не странноватый, а спорный. Мне тоже показалось так, пока все не взвесили и со стороны бизнеса тоже.
danial72
31.01.2022 17:22+11Просто чтобы подытожить:
- автор стал руководителем какого-то отдела не ознакомившись с технологией, которая используется на проекте
- автор решил просто отказаться от годовых наработок, потому-что ему так удобнее
- бизнесу это встанет в ушедших сотрудников (кто после флаттера станет писать на нативе ? Никто)
- бизнесу это встанет в ожидание разработки нативных приложений
- бизнесу это встанет в просранный HR- бренд, потому-что когда отдел разработки переводят на другие технологии насильно, это очень быстро расходится и вызывает негативные оценки компании
Либо руководство озона крайне наплевательски относятся к инструментам, которые обеспечивают из базовую деятельность, либо какая-то внутренняя политика пошла по известному месту.SofBix Автор
31.01.2022 18:57+2Выше в коментариях я расшифровывал смысл строк "стал невольным сместителем", это означает, что решение было принято до того как автор стал руководителем, и смысл автору вникать в технологии, от которых в компания отказываются и без него? А вот причины разумеется изучены и изложены в этой статье, вы кстати ее читали?
Если бизнес уже согласился, значит ему это выгодно, я кажется упоминал в статье какую выгоду получит бизнес.
Довольно смело пишите за автора, готов взять секретарем)
danial72
31.01.2022 20:20+8Я как-раз кстати прочитал статью. И вы знаете, я не увидел ни одного пункта, в котором были бы описаны причины переходит на натив с точки зрения бизнеса кроме
"захотелось перейти от количественного к качественному: более нативного поведения и вообще, чтобы ставили только пять звёзд"
Это предложение смысловую нагрузку потеряло на вычитке редакторами.
Вы инженер и руководитель, вы в отличии от бизнеса, который почему-то решил перейти на удвоенную трату бюджета и замедление разработки, которое произойдет через полгода, должны понимать что делаете, разбираться в том, что именно нужно переписывать. Бизнесу глубоко неважно, какое поведение у приложения их работников, бизнесу важно, получить заказанную фичу в четкий срок с понятным бюджетом.
Я вообще крайне смелый человек, особенно, когда вижу очевидно ошибочные решения. 90k$/y и поехали
dolpheen
31.01.2022 18:07+1Думаю, картинка с сарказмом "Imagine a world where you write code once" не совсем уместна, тот же Java, который стал языком разработки Android, шёл под лозунгом "Write once, run everywhere", не знаю, шутили ли по этому поводу 20 лет назад.
SofBix Автор
31.01.2022 18:59дык разные Java были. Google чудь не засудили за то что она взяла проваславную Java
kotovsky_art
31.01.2022 18:14-1Привет коллега! Абсолютно с тобой согласен, мой опыт сгенерировал аналогичную статью с анаогичными выводами только на vc )
4press
31.01.2022 19:33+4Нативщик переписывает с кросплатформы на натив. Сначала с RN потом с Flutter. Похоже на то, что кто-то переливает чай из казенной чашки в ту, которую из дома принес, с любимыми цветочками. Мне тоже флаттер не оч, но чет веских причин 'все переписать нах' в описанном кейсе я особо не увидел.
SofBix Автор
31.01.2022 22:04отличный образ, только с учетом возможностей натива (кажется, в статье упоминал, что они шире) перелив из стаканчика в вазу с цветами. А с учетом пропорции в компании Flutter:Native то стаканчик уже давно пора списать как музейный реквизит.
sved
31.01.2022 23:39+2Для меня Flutter был как глоток свежего воздуха. Без него я бы никогда не выпустил версию своего приложения под iOS. Я столько замучался с этими хакинтошами - это просто жесть.
С флутером можно разрабатывать вообще без эмуляторов - компилим виндус версию и запускаем. Хот-релоад неплохо работает.
Получилось обойтись без нативного кода совсем, работает быстро. Разрабатывать на удивление легко (особенно по сравнению с iOS).
Значит дарт - плохой, а swift-образец удобства? С чего вы решили, что разработчики предпочтут Swift?
SofBix Автор
01.02.2022 11:14В вашем случае выбор оправдан, запуск стартапа, ограниченный бюджет, ничего лучше кроме Flutter не придумаешь и об этом я тоже писал.
Swift как язык не образец, но тем не менее я его выбрал, например, для своих стартапов чтобы писать Backend, в выборке были C# и Go еще. Первый слишком тормознутый, второй слишком замороченный, а Swift как-то балансирует, за 4 года не пожалел. Я вообще Swift евангелист. Что до Dart, признаюсь я на нем не писал, поэтому мне пришлось представить в статье мнение 5 коллег, никто из них не является настроенным против Flutter. Один из них кстати тоже выпустил приложение, как и вы на iOS, будучи Android native разработчиком. Первые его впечатления: блин круто, декларативный UI - это будущее, единственное язык древнючий какой-то ну и артефакты в графике
Ivanzabu
01.02.2022 19:21Вот когда удаётся обойтись совсем без нативного кода - все прекрасно в флаттере, но насколько я помню - карты, геолокацию, камеру и остальные хардварные фишки не применить
bean
01.02.2022 06:00+4Google Killed
Так Android и Jetpack Compose, который упоминается в статье, тоже made by Google и по той же логике точно также могут быть закрыты. Можно, конечно, допустить, что неожиданно Flutter решат закрыть через какое-то время, но объективных причин для этого нет. Сам SDK развивается, количество вакансий и разработчиков растет, есть поддержка Fuchsia (если она когда-нибудь разовьётся во что-нибудь для мобилок).
Вот, например, давайте посмотрим на Dart: когда в него завезли null safety? Правильно, только весной 2021 года, а ведь это базовый механизм статической типизации.
Нет такого общепринятого понятия, как "базовый механизм статической типизации" для null safety. Просто в Kotlin/Swift это появилось уже после того, как вышел Dart. Да и сама фича достаточно сложная для добавления, потому что требует правки всей системы типов, миграции кода библиотек/приложений. Если сравнивать с Kotlin, то в итоге получилось даже лучше, потому что компилятор Dart может использовать информацию о типах и вырезать проверки на null в нативном коде, что повышает производительность и уменьшает размер сборки, а в Kotlin это все остается на границах публичных методов, потому что рантайм ничего не знает об этом. В Dart'e действительно нет многих фишек современных языков, но если смотреть не в моменте, а за период с релиза Flutter то развивается он достаточно бодро и разрабы прислушиваются к коммьюнити. Плюс у Dart'a тут есть возможность насобирать шишек за чужой счет и добавлять фичи более обдуманно. Да, конечно, хочется все и сразу, но развитие есть.
Конечно, прекрасно, что Flutter можно посмотреть в исходниках, как и увидеть, сколько issues сейчас открыто в официальном репозитории: их количество только растёт — это говорит о том, что команда пока не справляется с потоком ошибок. Например, только совсем недавно сделали, чтобы анимации не тормозили на iOS ¯_(ツ)_/¯
Количество isssues не равно количеству ошибок, потому что это могут быть фича реквесты, вопросы по использованию SDK, инфраструктурные проблемы, ошибки в desktop платформах (которые еще не в релизе), да и вообще что угодно. Количество тасок скорее говорит о том, что само сообщество вокруг Flutter большое и растет.
По поводу проблем с анимациями на iOS: такая проблема действительно была, но по статье не понятно, аффектило ли это вас или это просто пример. Когда мы выпускали приложение (которое уже было в сторе на Android) на iOS то таких проблем не было.
Собственный UI, характерный для обеих мобильных платформ
Поведение на разных платформах можно кастомизировать, часть из этого работает уже по умолчанию. В примерах есть приложение, которое на разных платформах выглядит нативно при этом максимально переиспользует общие части. Могут быть и другие варианты как это решить, все зависит от дизайна и требований. Тут действительно можно упрекнуть Flutter в том, что он не может как-то автоматически менять UI на разных платформах, чтобы приложение выглядело нативно, но UI паттерны могут отличаться слишком сильно.
В целом доводы в статье субъективные и эмоциональные, а при таком серьезом решении о миграции всего приложения на другой стек, выглядит как раз необдуманно, но, с другой стороны, дает понимание о подходах в компании к таким вопросам.
SofBix Автор
01.02.2022 12:12-2Объективные доводы это и есть численные метрики, растет число вакансий и на нетиве пропорционально Flutter, я точно так же могу перевернуть в свою сторону объективные метрики объяснив все с другой стороны, как вы делаете со статистикой issues. Закроют или нет Flutter вам никто не скажет, но есть риск. Есть исторические факты, например аналогия с ReactNative или закрытие гуглпроектов. История как мы знаем повторяется, не исключено что Flutter разовьется и KMM его не опередит, в будущем возможно все что угодно, но есть тренд. Я о нем рассказал, если он вас напугал, то это не значит, что статья эмоциональная и в Озоне сидят дураки которые боятся что Flutter придется поддерживать самим, просто этот риск нам не нужен, у нас есть большое комьюнити нативных разработчиков и лучше в него вкладываться, чем вкладываться в рисковые технологии превращая проект в монстра. Jetpack Compose имеет меньше рисков на мой взгляд, потому что есть в компании опыт и практика его использования, она более позитивная, но я сейчас не буду расписывать их, статья не об этом
Mitai
01.02.2022 08:18+7какой то внук Ванги, КММ сдвинет флаттер, гугл может убить флаттер, чувак бегает по проектам и все что делает везде переписывает все на натив, статья херня галимая, натив головного мозга
druzzyaka
01.02.2022 11:09+1Автор так критикует синтаксис Java, как будто пользовался ей лет 10 назад.
Ок, пусть даже современная джава немного более громоздкая, но на дворе 2022 и никто не запрещает юзать IDE для автодополнения и быстрой генерации типичных конструкций.
SofBix Автор
01.02.2022 12:18-2Вы угадали, я пользовался ей в последний раз в 2006, на мой вгляд тогда в нее внесли значительные улучшения. Периодически меня удивляли и оптимизации компиляторов и nullsafe, но я не критикую его синтаксис, это был собирательный образ от пользователей Dart) Простите, если задел) мне в Java очень нравится система коллекций, очень продуманная.
mavejee
01.02.2022 11:09-1Кроме того, было принято решение использовать единую архитектуру в мобильном приложении для обеих платформ, делать перекрёстное и межплатформенное ревью, чтобы идти в одном направлении.
Можно где то подробнее прочитать про единую архитектуру приложений? Есть статьи какие-то или доклады?
SofBix Автор
02.02.2022 16:26На старте проекта серчил в основном зарубежные статьи, и даже на английском не смог найти. Зато известна практика, когда MVVM + Rx + Clean architecture на проект с iOS и Android затаскивают (статьи отдельно под платформы вы легко найдете) и примерно одинаково развивают под бдением архитектора оби платформы. Так что вы мне подали отличную идею написать такую статью на стыке двух платформ в будущем. Спасибо за идею.
vmityuklyaev
01.02.2022 12:48+2Писать статьи не очень просто, а комменатриев тут очень много и большая часть с критикой. Понимаю, что есть вероятность, что автор мог не донести мысль из-за чего его аргументы могли быть не в лучшем свете. Но я, все же, думаю, за статьей есть большой смысл и буду ждать новую статью с более подробным разбором, чтобы она могла обьяснить каждому причины отказа от технологии
vmityuklyaev
01.02.2022 12:48Хотя, такое большое количество комментариев с критикой мне бы отбило желание что-то еще писать, но автор - держись, понимаю на сколько не просто писать статьи
SofBix Автор
02.02.2022 16:28-1Спасибо, думаю нужно больше времени, чтобы сказать: да мы это сделали не зря, но акцент уже будет тогда на стороне нетива
ldss
01.02.2022 19:21А вы под Native что имеете в виду? Kotlin Native, или просто разработку под андроид на Kotlin/Java?
SofBix Автор
02.02.2022 16:32Имеется в виду использование Native SDK от создателей операционных систем Android, iOS. Под iOS это Swift, под Android это Kotlin языки. Там где то еще деклаймер есть с мелким шрифтом.
Pawga777
01.02.2022 20:32+4Вся аргументация притянута "за уши". SwiftUI и Jetpack Compose тоже что и Flutter. Это серьезно?
Что Kotlin Multiplatform потенциальный могильщик Flutter? Развитие этой мысли можно продолжить как использовать Kotlin Multiplatform для UI? Серьёзно? Автор извини. Это шутка. Я уверен, что ты знаешь что такое Kotlin Multiplatform.
Dart - непривычный язык после перехода с Kotlin или Swift. Но Dart - не ущемляет в свободе. Да, Kotlin более удобный. Ну нужно точки с запятой в конце оператора ставитьв Dart. Привыкать "обратно" - трудно :) Но что у Kotlin или Swift колоссальный отрыв от Dart - не соглашусь. Всё, что я делал на Kotlin или Swift, я смог делать и на Dart особо не напрягаясь. И скажу, что конструкции у Dart проще и не менее эффективные. Но не такие "сахарные" как у Kotlin.
Собственный рендеринг UI во Flutter в каких местах может озадачить пользователя вашего приложения? Автор точно в курсе, что у Flutter есть контролы Cupertino (iOS-style) и Material Design. Возможности по созданию сложных экранов по UI - впечатляют. Не нашел ни одного ограничения, которые невозможно реализовать в UI на Fluetter (имею опыт разработки и для iOS, и для Android нативным способом). Во Flutter разработчики получают гораздо большую свободу в UI (моё мнение). И как ни странно интерфейс очень часто более отзывчивый и более эффективный.Можно сделать вывод, что набор причин ниже не являются основными для обоснования "погребения" Flutter :
проблемы со сканером кодов (исправлено, есть стабильное решение уже даже версии 2.0.0, и это не какая-то версия 0.xxx)
проблемы с анимацией на iOS (исправлено)
Google имеет привычку убивать свои перспективные проекты (спасибо Google за наличие такой аргументации)
Зная что в компаниях с нативной разработкой (раньше и в Озон так было, знаю по OzonTravel) по 3 - 4 разработчика на платформу (итого 6 - 8, а на Flutter обычно в два раза меньше, то как нынешний руководитель "убедил" менеджеров Озон вернуться к нативной форме команды разработки, увеличивая бюджет на команду и количество разработчиков, приведя вот такие аргументации как выше? Не странно, что эти самые менеджеры приходили с вопросов «Ну а всё же почему?»
Как кто-то выше написал, причины были другие и не технологические. Менеджеров очень часто вводят в заблуждение подобной аргументацией, преследуя какие-то свои цели, "ведущий-разрабочик-техлид-руководитель разработки". Компания тратит бюджеты на эксперименты таких руководителей "туда" и потом "обратно".
Ни один из аргументов, что Flutter хуже нативной разработки, в данной статье меня не убедил. Мне есть с чем сравнивать. Автору скорее всего просто хочется вернуться в нативную разработку iOS :)
Удачи компании Озон. Компания хорошая :). Постоянно пользуюсь услугами этой компании. Надеюсь, что такие эксперименты не отразятся на качестве программ этой компании. Хотя конкретно описанная здесь программа - это мобильная программа для внутреннего использования работниками Озон на пунктах выдачи. Так что вроде всё хорошо.SofBix Автор
03.02.2022 10:19Менеджмент из бизнеса не интерисуются такими ньюансами, которые изложены в статье, эти ньюансы скорее интересны вам как разработчику и прожект менеджеру максимум, чтобы не допустить элементарную ошибку в расчетах, которую вы допустили:
"3 - 4 разработчика на платформу (итого 6 - 8, а на Flutter обычно в два раза меньше)", почитайте комментарии, даже те кто зачем-то рьяно защищают Flutter (будто я на него напал) не считают что 2 нативных разработчика = 1 Flutter разработчику. Это все рано, что полагать, что 9 женщин родят ребенка за месяц.
На данном этапе развития KMM естественно не могильщик, я предположил что его развитие в перспективе может просто потеснить сильно Flutter, как это было с другими эффектными мультиплатформами в прошлом. Compose сделают и будет вам UI на KMM, сделали же для Андройда, у нас зашло, рекомендую кстати вам как человеку, который и в нативной разработке могет.Вернусь к бизнесу, так вот бизнес смотрит на фундаментальные показатели: сроки (ага нтивка тянет быстрее, значит пока флатеристы баги правит в чужих компонентах эти преуспеют, надо скорее пересаживаться на рельсы), качество (не надо думать что свои сотрудники стерпят любое качество приложения, мы вообще то следим за отзывами и ходим в ПВЗ сами, интересуемся что сотрудников не устраивает). И еще есть фундаментальные показатели глобальные, а они говорят за тренд сменяемости, потому что любой мультеплатформе надо поспевать и обогнать конкурентов и поспевать за изменениями в нескольких платформах - такая нагрузка рано или поздно станент отказонеустойчивой. Вы серьезно думаете что один Dart c Flutter хотябы нагонит всех-всех?
Pawga777
03.02.2022 13:25Никто не спорит, что в части проектов, уменьшение двух нативных команд в одну, по формуле "станет" = "было" * 0.5 не работает. Не развиваю вашу тему про "9 женщин и 1 месяц".
Прочитав Ваш пост у многих первое впечатление складывается такое: причина, по которой ваша команда возвращается к "нативной" схеме, в том что, flutter + dart - негодная и незрелая технология, которую вот-вот Google "закроет". Не развиваю эту мысль. Обсудили. Конкретно вашей команде flutter + dart не подошел. Кстати, Google(Аlphabet) недавное рассылал отчет по динамике роста программ на flutter в их магазине. Быстро не нашел этот отчёт. Цифры не вспомню, но взрывной рост качественных и надежных приложений на Flutter, официально опубликованных в магазине.
Про менеджеров. Не секрет, что "главный" разработчик иногда просто навязывает менеджеру, принимающему решение, выгодное ему в каком-то контексте решение. Например. Есть в организации определенная "инфрастуктура" CI / CD с конкретными требованиями по использованию конкретных средств тестирования. Ну очень тяжело втиснуть(настроить, отладить, запустить) новую платформу в эти требования. Баг за багом при настройке. Но не в самой сутевой программе. Время уходит. "Паралельные"команды обгоняют. Или. Есть в организации конкретные требования по использованию довольно конкретных "движков" аналитики, и в этом списке есть и довольно специфические. И очень тяжело какие-то аналитические движки подружить с новой платформой. Вписаться под эти требования с новой платформой типа "flutter + dart" ну очень тяжело. Тестирование ломается, аналитика не собирает нужные данные, общие показатели падают, "главного" разработчика начинают менеджеры ругать. Какой план выстраивается в голове "главного" разработчика, которого ругают? Правильно, предложить вернуться к проверенной и надежной схеме. Тем более есть соответсвующая аргументация в виде SwiftUI + jetpack compose, где тонкие нюансы менеджеру неизвестны. Это не Ваш случай? Если так, то в этом случае "flutter + dart" - не виноваты.
У меня сложилось впечатление, что ваша команда закончила эксперименты с flutter еще год назад и свежие стабильные версии просто не смотрела. А Вы по информации годичной давности написали вот этот пост :)
Были проблемы со "сканером штрихкодов", "анимацией на iOS" и системой хранения на hive. Что-то ещё можете добавить? И любопытно, что не так пошло с web-версией. Просто для объективности картины.
Atreides07
01.02.2022 21:48+1Честно говоря, после прочтения, я так и не понял почему решили перейти на Native :(
SofBix Автор
03.02.2022 10:27А вы бизнесмен? Разработчик? Чтобы понимать на каком языке обьяснить было проще.
HavenDV
02.02.2022 01:44+1А был еще третий вариант - делать PR во Flutter. И себе помогли бы, и другим людям тоже. Хотя переписывать всегда проще, да.
SofBix Автор
02.02.2022 16:37Я всегда за развитие OpenSource и за то чтобы разработчики развивали комьюнити разных технологий. Но мне кажется это непосильная ноша для компании, которая к тому же избрала другой курс. Если бы мы нашли достаточное количество лидов под Flutter, то возможно так бы и вышло, но получилось все как раз наоборот. К тому же обрачу ваше внимание, что есть крупные компании как Google и Apple, которые создали операционные системы и развивает их постоянно. И есть Flutter, который должен постоянно нагонять 2-х гигантов, представляете сколько туда средств требуется вложить?
RevanScript
02.02.2022 12:01-1Читаю такие issues и уже вижу как Kotlin Multiplatform убивает React Native и Flutter. Мало того, что он предназначен для совсем других целей (только шеринг бизнес логики), так ещё и в своём амплуа проблем хватает. Если оно массово не зайдет комьюнити (чего пока не происходит), то активно переписывать существующие библиотеки с JVM зависимостями под него не будут и даже какой-нибудь gomobile сейчас выглядит предпочтительнее.
Krionis
02.02.2022 14:23-3Боже мой, сколько защитников мультиплатформенных поделий в комментариях. Это точно Хабр?
SofBix Автор
02.02.2022 16:42-1Мне кажется у читателей сложилось впечатление, что Flutter гонят саной тряпкой. Но это не так, цель нашей компании просто перейти на другой стек. И причины, которые тут изложены, ясное дело не всем нравятся, с чего они должны быть объективными?
dabystru
03.02.2022 09:57И всё-таки кому нужен Flutter? ... Стартапы для прототипирования
Зависит от того, для кого делается прототип.
Если для инвесторов (мы после акселератора Яндекса в 2020 поговорили с ~50), то, как оказалось, многие хотят увидеть волшебную формулу CAC < 3 * LTV (стоимость привлечения клиента втрое меньше, чем мы на нём зарабатываем).
И часто бывает, что лучше выпустить прототип только на iOS, где Apple собрал «золотой миллиард» (20% людей, выпивающих 80% пива), чем «разбавлять» его Android'ом, где экономика гораздо хуже.
То есть вот просто реально, пока не дадут денег, не выпускать на Android, чтобы не ухудшать показатели.
RockStar17
03.02.2022 13:02Статья очень субъективна. Заходим на github: у flutter 135к звездочек, у React Native 101к, хотя flutter стартонул на несколько лет позже. У flutter реальная мультиплатформенность — iOS, MAC, Web, Linux, Windows. Поддержка сообщества. Реально создали отличный фреймворк, писал на Xamarin — есть с чем сравнить. KMM — общая бизнес логика, UI рисуем отдельно для каждой платформы? так это было в xamarin в 2012 (10 лет назад) — оч. неудобно. Почему flutter проиграет, или google его «закроет»? «Внук Ванги» одним словом.
zloyreznic
Всего лишь камера - и переходить на Native?
Почему не подошел вариант работы с камерой вывести в Native, а остальное на Flutter?
SofBix Автор
Разумеется не только, был упомянут функционал только уже реализованный на Flutter и довольно общий, в будующем надо было бы подключать собственную аналитику и многие другие платформенные компоненты, характерные для нашей компании и реализованные на Native.
Revertis
С ударением на вторую у? ;)
Beanut
Ну, потому что "недавно стал руководителем разработки" и надо же что-то делать, что-то внедрять, как-то засветиться.
SofBix Автор
"Невольно став сместителем существующего..." видимо необходимо расшифровать. Решение уже было принято до меня, а я лишь был назначен на это место, чтобы данное решение грамотно воплотить в жизнь. Это не первый опыт, когда меня нанимали для того чтобы драйвить команду переходить на Native
Z2K
еще одно важное преимущество для программистов - количество вакансий почти удваивается. А если еще и веб, то и ....
SofBix Автор
они удваиваются сейчас и на нативе и на Flutter, и ЗП растет у всех тоже. Это показатель роста самого IT в целом, причем Flutter скорее за взрывной рост новых стартапов.