Ответил выше . Не считаю :). На скорость многое влияет. Сборка в обычном исполнении в режиме JIT-оптимизации (но осторожно напишу, что не сразу) может быть сравнима с нативно откомпилированной программой.
@Sipaha, спасибо за комментарий. Вот уж JIT и AOT начали бурно обсуждать. Статью я хотел написать не про JIT и AOT :). Одна "неосторожная" фраза в статье увела дискуссию в эту сторону. Технологии JVM не стоят на месте и скорости работы могут быть соезмиримы. Просто есть у нас еще один фрэйморк. Статья про это. Ешё про реактивные возможности Kotlin. Я ещё для себя открыл не так давно Kotest, отличный фрэймворк. Моё субьективное мнение :) Есть еще отдельная тема о наличии JVM типа GraalVM в дополнение к "обычным". Ведь если целые компании тратят время на создание чего-то подобного, то значит в этом есть какой-то смысл. Я думаю, мы должны иметь информацию о подобных возможностях. А использовать или нет - это уже другой вопрос. Ещё раз спасибо.
@TerraV, спасибо. Полностью согласен, и про JIT-прогрев в частности. Добавлю, или акцентирую, что статья не про нативную сборку и не призыв, переходить на неё. И не призыв уходит с проверенного SpringBoot. Просто информация об ещё одном фрэймворке. Одна фраза в статье типа "эмоциональное" восхищение чем-то вызвало такую реацию? Автор же имеет право высказать свое отношение к чему-то? И если есть в новом фрэймворке, почему про это на написать. Я, когда читаю статьи, полезную информацию для себя просто помечаю, чтобы в свободное время поглубже разобраться. Только и всего. да, про скорость и вопрос про 10 раз. Естественно, после "прогрева" и работы JIT и оптимизаций, разница в скорости может сойти на нет. Я думал, это все понимают. Набросились на меня из GraalVM :)
Вы серьезно считаете, что программа работающая в связке "jvm + байт-код" работает с той же скоростью, что и тот же вариант программы, скомпилированный в нативный вид?
Наверное, я допустил некорректную фразу в статье. Допустим есть два сервиса: один работает в нативно-откомплированном виде, практически без усилий со стороны разработки по причине выбора фрэймворка, второй сервис в виде байткода. Во втором сервисе всё работает (а не только старт) в десятки раз медленнее по своей природе. Не хочу чтобы дискуссию ушла ещё в сторону JIT или AOT, я очень неплохо разбираюсь и в этом. Далее, первый сервис можно точно также настроить в среде "бегущих" подов. Уход в другой контекст мне тоже непонятен. Если в том контексте атомарные сервисы будут быстрее работать, разве это плохо? Да, в среде K8S разница в скорости может быть и не так заметна, не в десятки раз, но эта разность будет уже по другим причинам. Мы сравниваем скорость работы атомарного процесса. Зачем тогда GraalVM или подобная технология? Можно подумать что "бегущих" подов это безполезные технологии? Заканчивую свой ответ. Я просто показал имеющуяся альтернативу. Использовать или не использовать быстрее в 10 раз работающий сервис или модуль - выбор архитектора. Выбор: попробовать Micronaut или остаться на SpringBoot? А может вообще уйти со SpringBoot в Quarkus. Я бы предложил попробовать откомпилировать в нативный вид сервис SpringBoot с JPA? В Golang компиляция в нативный вид присутсвует из коробки, например. И Golang при выборе технологии "побеждает" в том числе и из-за этого преимущества. Кстати, в Android-экосистеме подобный подход в видоизмененном виде уже давно используется. В упрощенном виде этот подход выглядит так: после установки на конкретное(!) устройство при первом запуске программа переводит себя в нативно-откомпилированный вид полностью, и далее работает уже нативно. Там уже давно не стоит вопрос о преимуществах нативно-откомпилированной программы. Если новые возможности не впечатлили, то можно остаться и на проверенных технологиях. Я знаю разработчиков, которые со мной захотели бы поспорить о ложных преимуществах Kotlin перед Java. Это была бы дискуссия на подобную тему. Кстати, в той же Android-экосистеме уже давно только Kotlin, и эффективность языка проверена на миллионах устройств и программ, как и нативная работа этих программ. Нашему enterprise-бэкэнду до такой статистики очень далеко. Но и Java для Android-разработки тоже осталась, если любишь Java продолжай на нём программировать. Так и здесь. Можно остаться на SpringBoot без возможности нативной компиляции. Нативная компиляция только формально есть, вспомни про JPA и "всё на рефлексии" . А можно попробовать почти идентичную технологию, которая позволяет делать сборку в нативный вид без "танцев с бубнами". Кто решения по выбору технологий принимает, многие знают и без меня :). Своим ответом никого обидеть не хочу. И на "религиозные" темы спорить тоже не хочу.
Сообщением выше кнопкой промахнулся. Нужно было "ответить" :)
Опять не поспорю. Добавлю только, что для юридической значимости нужно соблюсти ряд требований. Не только иметь возможность использовать совершенные технологии криптоалгоритмов, но и соблюсти ряд условий. Например, для подписи использовать сертификат, выданный доверенным центром сертификации(мой самоподписанный сертификат только меня самого удовлетворит :) ). Но самое главное: подписать документ в среде, которая будет гарантировать и время подписания (синхронизируется с серверами времени извне и время подписи нельзя подделать) и самого владельца подписи. Тут-то и появляются практически безалтернативные среды, которые серифицированы. Подписи такие, упаковывают в специальные контейнеры. Если нужно гарантировать работу с такой подписью чере много лет то это, например CAdES-A v3.
А вот внутри организации можно свои правила вводить. В тех же СЭД широко используется простая электронная подпись - если пользователь аутенфицирован, то его все действия подтверждены этим фактом, например, именно такой-то согласовал внутри организации такой-то документ в контексте конкретной СЭД. Но можно чуть-чуть улучшить алгоритмы: использовать не сигнатуру MD5, а более надежную сигнатуру подписи RSA. Конфидицальные документы шифровать для доступа определенной группы(чтобы текст документов был виден только этой группе, например членам правления, а не всем админам ПРОД-а, хоть они и подписывают документы о "неразглашении" :) ). Вот тогда примеры реализации, как в этой статье например, могут быть полезны разработчикам. А нужны ли гостовские алгоритмы для шифрования внутри оргнанизации без доступа извне со всей этой огромной конструкцией типа крипта-про - тоже вопрос. Кому-то точно не нужны.
Всё верно написали. КриптоПро - фактически монополист. Разработчики КриптоПро JCP в своем продукте используют bouncycastle (изучал их тесты в этой библиотеке, полюбопытсвуйте). По моему мнению, дело не в сертификации самой библиотеки а в сертификации "окружения". У самой КриптоПро - есть конкуренты, но слабые (не погружался в эту тему и не хочу никого обидеть. Фиксирую просто, что конкуренты есть). Можно сгенерить сертификаты в КриптоПро, выгрузить их. Можно настроить openssl для работы с гостовскими алгоритмами. Но как правило за пределами КриптоПро их сертификаты не работают. Их поддержка мне напрямую ответила что keystore они не поддерживают и не собираются. И скорее всего не будет работать и то, что вы сделаете за пределами самой КриптоПро и каким-то образом туда заимпортируете (например через openssl). Надо прилагать некие усилия (конвертировать платной утилитой или некие патчи накатывать). Я полюбопытствовал и не нашел "красивых" решений. Сама bouncycastle - красива :). С гостовскими алгоритмами можно рботать (см тесты которые я приложил), но по моим ощущениям всё совсем негибко. А просто использовать и шифровать данные RSA и AES (без ГОСТ) - легко и понятно.
Никто не спорит, что в части проектов, уменьшение двух нативных команд в одну, по формуле "станет" = "было" * 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-версией. Просто для объективности картины.
Вся аргументация притянута "за уши". 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 :) Удачи компании Озон. Компания хорошая :). Постоянно пользуюсь услугами этой компании. Надеюсь, что такие эксперименты не отразятся на качестве программ этой компании. Хотя конкретно описанная здесь программа - это мобильная программа для внутреннего использования работниками Озон на пунктах выдачи. Так что вроде всё хорошо.
Ответил выше . Не считаю :). На скорость многое влияет. Сборка в обычном исполнении в режиме JIT-оптимизации (но осторожно напишу, что не сразу) может быть сравнима с нативно откомпилированной программой.
@Sipaha, спасибо за комментарий. Вот уж JIT и AOT начали бурно обсуждать. Статью я хотел написать не про JIT и AOT :). Одна "неосторожная" фраза в статье увела дискуссию в эту сторону. Технологии JVM не стоят на месте и скорости работы могут быть соезмиримы. Просто есть у нас еще один фрэйморк. Статья про это. Ешё про реактивные возможности Kotlin. Я ещё для себя открыл не так давно Kotest, отличный фрэймворк. Моё субьективное мнение :) Есть еще отдельная тема о наличии JVM типа GraalVM в дополнение к "обычным". Ведь если целые компании тратят время на создание чего-то подобного, то значит в этом есть какой-то смысл. Я думаю, мы должны иметь информацию о подобных возможностях. А использовать или нет - это уже другой вопрос. Ещё раз спасибо.
@TerraV, спасибо. Полностью согласен, и про JIT-прогрев в частности. Добавлю, или акцентирую, что статья не про нативную сборку и не призыв, переходить на неё. И не призыв уходит с проверенного SpringBoot. Просто информация об ещё одном фрэймворке. Одна фраза в статье типа "эмоциональное" восхищение чем-то вызвало такую реацию? Автор же имеет право высказать свое отношение к чему-то? И если есть в новом фрэймворке, почему про это на написать. Я, когда читаю статьи, полезную информацию для себя просто помечаю, чтобы в свободное время поглубже разобраться. Только и всего. да, про скорость и вопрос про 10 раз. Естественно, после "прогрева" и работы JIT и оптимизаций, разница в скорости может сойти на нет. Я думал, это все понимают. Набросились на меня из GraalVM :)
Вы серьезно считаете, что программа работающая в связке "jvm + байт-код" работает с той же скоростью, что и тот же вариант программы, скомпилированный в нативный вид?
Наверное, я допустил некорректную фразу в статье. Допустим есть два сервиса: один работает в нативно-откомплированном виде, практически без усилий со стороны разработки по причине выбора фрэймворка, второй сервис в виде байткода. Во втором сервисе всё работает (а не только старт) в десятки раз медленнее по своей природе. Не хочу чтобы дискуссию ушла ещё в сторону JIT или AOT, я очень неплохо разбираюсь и в этом. Далее, первый сервис можно точно также настроить в среде "бегущих" подов. Уход в другой контекст мне тоже непонятен. Если в том контексте атомарные сервисы будут быстрее работать, разве это плохо? Да, в среде K8S разница в скорости может быть и не так заметна, не в десятки раз, но эта разность будет уже по другим причинам. Мы сравниваем скорость работы атомарного процесса. Зачем тогда GraalVM или подобная технология? Можно подумать что "бегущих" подов это безполезные технологии? Заканчивую свой ответ. Я просто показал имеющуяся альтернативу. Использовать или не использовать быстрее в 10 раз работающий сервис или модуль - выбор архитектора. Выбор: попробовать Micronaut или остаться на SpringBoot? А может вообще уйти со SpringBoot в Quarkus. Я бы предложил попробовать откомпилировать в нативный вид сервис SpringBoot с JPA? В Golang компиляция в нативный вид присутсвует из коробки, например. И Golang при выборе технологии "побеждает" в том числе и из-за этого преимущества. Кстати, в Android-экосистеме подобный подход в видоизмененном виде уже давно используется. В упрощенном виде этот подход выглядит так: после установки на конкретное(!) устройство при первом запуске программа переводит себя в нативно-откомпилированный вид полностью, и далее работает уже нативно. Там уже давно не стоит вопрос о преимуществах нативно-откомпилированной программы. Если новые возможности не впечатлили, то можно остаться и на проверенных технологиях. Я знаю разработчиков, которые со мной захотели бы поспорить о ложных преимуществах Kotlin перед Java. Это была бы дискуссия на подобную тему. Кстати, в той же Android-экосистеме уже давно только Kotlin, и эффективность языка проверена на миллионах устройств и программ, как и нативная работа этих программ. Нашему enterprise-бэкэнду до такой статистики очень далеко. Но и Java для Android-разработки тоже осталась, если любишь Java продолжай на нём программировать. Так и здесь. Можно остаться на SpringBoot без возможности нативной компиляции. Нативная компиляция только формально есть, вспомни про JPA и "всё на рефлексии" . А можно попробовать почти идентичную технологию, которая позволяет делать сборку в нативный вид без "танцев с бубнами". Кто решения по выбору технологий принимает, многие знают и без меня :). Своим ответом никого обидеть не хочу. И на "религиозные" темы спорить тоже не хочу.
Сообщением выше кнопкой промахнулся. Нужно было "ответить" :)
Опять не поспорю. Добавлю только, что для юридической значимости нужно соблюсти ряд требований. Не только иметь возможность использовать совершенные технологии криптоалгоритмов, но и соблюсти ряд условий.
Например, для подписи использовать сертификат, выданный доверенным центром сертификации(мой самоподписанный сертификат только меня самого удовлетворит :) ). Но самое главное: подписать документ в среде, которая будет гарантировать и время подписания (синхронизируется с серверами времени извне и время подписи нельзя подделать) и самого владельца подписи. Тут-то и появляются практически безалтернативные среды, которые серифицированы. Подписи такие, упаковывают в специальные контейнеры. Если нужно гарантировать работу с такой подписью чере много лет то это, например CAdES-A v3.
А вот внутри организации можно свои правила вводить. В тех же СЭД широко используется простая электронная подпись - если пользователь аутенфицирован, то его все действия подтверждены этим фактом, например, именно такой-то согласовал внутри организации такой-то документ в контексте конкретной СЭД. Но можно чуть-чуть улучшить алгоритмы: использовать не сигнатуру MD5, а более надежную сигнатуру подписи RSA. Конфидицальные документы шифровать для доступа определенной группы(чтобы текст документов был виден только этой группе, например членам правления, а не всем админам ПРОД-а, хоть они и подписывают документы о "неразглашении" :) ). Вот тогда примеры реализации, как в этой статье например, могут быть полезны разработчикам. А нужны ли гостовские алгоритмы для шифрования внутри оргнанизации без доступа извне со всей этой огромной конструкцией типа крипта-про - тоже вопрос. Кому-то точно не нужны.
Всё верно написали. КриптоПро - фактически монополист. Разработчики КриптоПро JCP в своем продукте используют bouncycastle (изучал их тесты в этой библиотеке, полюбопытсвуйте). По моему мнению, дело не в сертификации самой библиотеки а в сертификации "окружения". У самой КриптоПро - есть конкуренты, но слабые (не погружался в эту тему и не хочу никого обидеть. Фиксирую просто, что конкуренты есть). Можно сгенерить сертификаты в КриптоПро, выгрузить их. Можно настроить openssl для работы с гостовскими алгоритмами. Но как правило за пределами КриптоПро их сертификаты не работают. Их поддержка мне напрямую ответила что keystore они не поддерживают и не собираются. И скорее всего не будет работать и то, что вы сделаете за пределами самой КриптоПро и каким-то образом туда заимпортируете (например через openssl). Надо прилагать некие усилия (конвертировать платной утилитой или некие патчи накатывать). Я полюбопытствовал и не нашел "красивых" решений. Сама bouncycastle - красива :). С гостовскими алгоритмами можно рботать (см тесты которые я приложил), но по моим ощущениям всё совсем негибко. А просто использовать и шифровать данные RSA и AES (без ГОСТ) - легко и понятно.
Никто не спорит, что в части проектов, уменьшение двух нативных команд в одну, по формуле "станет" = "было" * 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-версией. Просто для объективности картины.
Вся аргументация притянута "за уши". 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 :)
Удачи компании Озон. Компания хорошая :). Постоянно пользуюсь услугами этой компании. Надеюсь, что такие эксперименты не отразятся на качестве программ этой компании. Хотя конкретно описанная здесь программа - это мобильная программа для внутреннего использования работниками Озон на пунктах выдачи. Так что вроде всё хорошо.