За 20 лет в ИТ могу сказать что трудозатраты на разработку UI всегда недооценивают и в общем объеме проекта они и съедают огромное количество человеко-часов и в основой части проекта и в последующем развитии и исправлении дефектов. А то что называют весомым словосочетанием "бизнес-логика" обычно делается относительно легко и в предсказуемые сроки в общем-то на любом языке. И я сейчас не только про простенькие приложения, но и про суровые Enterprise системы для большого бизнеса.
Поэтому необходимость дважды пилить UI считаю серьезным недостатком KMP.
Однако, спасибо за обзор, это очень полезно знать.
Под “бизнес-логикой” люди часто понимают разное. И в KMP действительно можно выносить в кроссплатформу разные части, по потребности. В статье мы не стали раскрывать что именно туда входит, тк не хотели закапываться в технику, но кратко опишу тут. Кто-то в KMP выносит только логику работы с данными, а кто-то всю логику: презентационную, доменную, логику работы с источниками данных. Более детально можно посмотреть в опросе от JB (https://blog.jetbrains.com/kotlin/2021/10/multiplatform-survey-q1-q2-2021/). В наших проектах мы идем по второму пути, и поэтому из KMP-части прилетает только UiState, который нужно отрисовать на UI на платформах и передать из платформ в KMP событие от пользователя. Так получается достичь большего переиспользования.
В основном мы как раз делаем приложения для бизнесов, в которых часто разработка интерфейса занимает либо меньше, либо столько же, сколько тратится на логику, всякие синхронизации с сервером, локальное хранение.
Поэтому эффект действительно ощутимый и для клиентов важна возможность сделать интерфейс нативным для пользователей каждой платформы
Но для кейсов где требований к нативности нет, можно использовать compose multiplatform
1. По опыту ищутся они также как и другие кодеры. Нам не нужен отряд разрабов, нам нужны 1-5 хороших 2. Для любой нативной фичи есть готовые пакеты, за 3 года работы с флаттером я ни разу не был в ситуации, где мне требовалось бы что-то писать ручками на нативе, обертки на дарте есть для всего. 3. Флаттеровские виджеты сейчас выглядят абсолютно также также, как и нативные. Может раньше и были еле заметные отклонения в анимациях с айосом, но сейчас даже их нет 4. Мне интересно посмотреть на разработчиков, которые на мидл/сеньор позиции на нативе пойдут учить флаттер. Далеко не каждый джун на такое пойдет. Для переписывания на другой язык/фреймворк нанимают людей, которые уже умеют на нем писать. А истории по типу где ты и швец, и жнец, обычно в компаниях, где весь айти отдел это полтора человека, думаю даже рассматривать смысла нет. Плавный переход кстати тоже осуществляется без проблем, такие кейсы тоже есть.
Итого что имеем. Если у вас мало интерфейса, но много логики, нужно брать кмп. Но по такой же логике можно брать хоть c++ разрабов, их на рынке на порядок больше айосов и андроидов вместе взятых.
Мое негодование вызвано тем, что чтобы показать кмп в лучшем свете зачем то приводят бредовые аргументы сравнивая с флаттером. Зачем говорить, что кмп переиграл и уничтожил флаттер? Вы сами сказали, что на флаттере экономия 40 процентов, а у вас 20-25. Хотя по опыту экономия 60-80.
Итого получается совершенно обратная ситуация, за исключением совсем спецефичных моментов флаттер переигрывает и уничтожает кмп, а не наоборот
UPD: на счет премиальности. Существует огромное количество "премиальных" приложений на флаттере. Так же как и для крупного бизнеса. Так что утверждение что он только для пет проектов и стартапов тоже бред
1. Опыт найма лично вами одного или 5 в разные моменты времени не опровергает факта, что их просто меньше в 2.5 раза. Из этой пропорции следует что нанять их при прочих равных сложнее.
2. На сколько сложные фичи с нативными штуками вам приходилось делать? В статье четко написано, что речь про глубокую работу с нативными фичами. Если делать приложения для рынка, в котором не требуется глубокая работа с нативкой, то даже за долгое время можно так и не столкнуться с ситуацией, в которой требуется что-то написать руками
3. Касаемо виджетов - реализованные виджеты не всегда ведут себя так, как на платформе.
4. Нативных разработчиков имеет смысл пересаживать на KMP, потому что можно ощутимо сэкономить не переучиваясь.
Можно сохранить команду, которая уже в курсе всех деталей бизнеса, но при этом сэкономить в деньгах и скорости
5. Если мало интерфейса, но много логики действительно лучше брать KMP. C++ разрабы не сравнятся в скорости разработки с разрабами на Kotlin и swift, на сколько бы много их не было
6. Премиальность. В статье описаны причины и аргументы, почему премиальные приложения лучше делать с нативными интерфейсами. Факт, что кто-то делает их на флаттере / реакт нейтиве / ксамарине не опровергает этот аргумент
P. S. Ну а переиграл и уничтожил - это мэм такой, а суть чётко описана в заголовке - 4 сценария, когда kmp лучше флаттера
Из всей статьи можно сделать вывод, KMP нужен только в том случае, когда у вас уже есть команда нативщиков, а заказчики их не хотят брать, потому как дорого, а изучать новую технологию они не хотят. Все остальное из пальца высосано, помимо этого автор не рассказал о мешке проблем, с которыми столкнулись при использовании KMP в проде, а не для pet проектов.
За 20 лет в ИТ могу сказать что трудозатраты на разработку UI всегда недооценивают и в общем объеме проекта они и съедают огромное количество человеко-часов и в основой части проекта и в последующем развитии и исправлении дефектов. А то что называют весомым словосочетанием "бизнес-логика" обычно делается относительно легко и в предсказуемые сроки в общем-то на любом языке. И я сейчас не только про простенькие приложения, но и про суровые Enterprise системы для большого бизнеса.
Поэтому необходимость дважды пилить UI считаю серьезным недостатком KMP.
Однако, спасибо за обзор, это очень полезно знать.
Под “бизнес-логикой” люди часто понимают разное. И в KMP действительно можно выносить в кроссплатформу разные части, по потребности. В статье мы не стали раскрывать что именно туда входит, тк не хотели закапываться в технику, но кратко опишу тут.
Кто-то в KMP выносит только логику работы с данными, а кто-то всю логику: презентационную, доменную, логику работы с источниками данных. Более детально можно посмотреть в опросе от JB (https://blog.jetbrains.com/kotlin/2021/10/multiplatform-survey-q1-q2-2021/). В наших проектах мы идем по второму пути, и поэтому из KMP-части прилетает только UiState, который нужно отрисовать на UI на платформах и передать из платформ в KMP событие от пользователя. Так получается достичь большего переиспользования.
В основном мы как раз делаем приложения для бизнесов, в которых часто разработка интерфейса занимает либо меньше, либо столько же, сколько тратится на логику, всякие синхронизации с сервером, локальное хранение.
Поэтому эффект действительно ощутимый и для клиентов важна возможность сделать интерфейс нативным для пользователей каждой платформы
Но для кейсов где требований к нативности нет, можно использовать compose multiplatform
Каждый из этих пунктов бред.
1. По опыту ищутся они также как и другие кодеры. Нам не нужен отряд разрабов, нам нужны 1-5 хороших
2. Для любой нативной фичи есть готовые пакеты, за 3 года работы с флаттером я ни разу не был в ситуации, где мне требовалось бы что-то писать ручками на нативе, обертки на дарте есть для всего.
3. Флаттеровские виджеты сейчас выглядят абсолютно также также, как и нативные. Может раньше и были еле заметные отклонения в анимациях с айосом, но сейчас даже их нет
4. Мне интересно посмотреть на разработчиков, которые на мидл/сеньор позиции на нативе пойдут учить флаттер. Далеко не каждый джун на такое пойдет. Для переписывания на другой язык/фреймворк нанимают людей, которые уже умеют на нем писать. А истории по типу где ты и швец, и жнец, обычно в компаниях, где весь айти отдел это полтора человека, думаю даже рассматривать смысла нет. Плавный переход кстати тоже осуществляется без проблем, такие кейсы тоже есть.
Итого что имеем. Если у вас мало интерфейса, но много логики, нужно брать кмп. Но по такой же логике можно брать хоть c++ разрабов, их на рынке на порядок больше айосов и андроидов вместе взятых.
Мое негодование вызвано тем, что чтобы показать кмп в лучшем свете зачем то приводят бредовые аргументы сравнивая с флаттером. Зачем говорить, что кмп переиграл и уничтожил флаттер? Вы сами сказали, что на флаттере экономия 40 процентов, а у вас 20-25. Хотя по опыту экономия 60-80.
Итого получается совершенно обратная ситуация, за исключением совсем спецефичных моментов флаттер переигрывает и уничтожает кмп, а не наоборот
UPD: на счет премиальности. Существует огромное количество "премиальных" приложений на флаттере. Так же как и для крупного бизнеса. Так что утверждение что он только для пет проектов и стартапов тоже бред
Комментарий недоступен
1. Опыт найма лично вами одного или 5 в разные моменты времени не опровергает факта, что их просто меньше в 2.5 раза. Из этой пропорции следует что нанять их при прочих равных сложнее.
2. На сколько сложные фичи с нативными штуками вам приходилось делать? В статье четко написано, что речь про глубокую работу с нативными фичами. Если делать приложения для рынка, в котором не требуется глубокая работа с нативкой, то даже за долгое время можно так и не столкнуться с ситуацией, в которой требуется что-то написать руками
3. Касаемо виджетов - реализованные виджеты не всегда ведут себя так, как на платформе.
Для примеров можно открыть тысячи issue платформ ios и android (https://github.com/flutter/flutter/issues?q=is%3Aopen+label%3Aplatform-ios%2Cplatform-android+). Некоторые из проблем кажутся незначительными. Но есть и глобальные, например: 1(https://github.com/flutter/flutter/issues/82906), 2(https://www.reddit.com/r/FlutterDev/comments/yywx66/attn_all_your_vote_is_needed_to_fix_critical/), 3(https://www.reddit.com/r/FlutterDev/comments/1140pdv/two_years_later_flutters_biggest_problem/)
4. Нативных разработчиков имеет смысл пересаживать на KMP, потому что можно ощутимо сэкономить не переучиваясь.
Можно сохранить команду, которая уже в курсе всех деталей бизнеса, но при этом сэкономить в деньгах и скорости
5. Если мало интерфейса, но много логики действительно лучше брать KMP. C++ разрабы не сравнятся в скорости разработки с разрабами на Kotlin и swift, на сколько бы много их не было
6. Премиальность. В статье описаны причины и аргументы, почему премиальные приложения лучше делать с нативными интерфейсами. Факт, что кто-то делает их на флаттере / реакт нейтиве / ксамарине не опровергает этот аргумент
P. S. Ну а переиграл и уничтожил - это мэм такой, а суть чётко описана в заголовке - 4 сценария, когда kmp лучше флаттера
Из всей статьи можно сделать вывод, KMP нужен только в том случае, когда у вас уже есть команда нативщиков, а заказчики их не хотят брать, потому как дорого, а изучать новую технологию они не хотят. Все остальное из пальца высосано, помимо этого автор не рассказал о мешке проблем, с которыми столкнулись при использовании KMP в проде, а не для pet проектов.