Комментарии 48
Ещё React Native есть. В целом, идея писать всё на Котлине выглядит перспективно. После того, как Android разработчики предали язык Java и перешли на Kotlin, сложилась такая ситуация, что сервер на Java, Android на Kotlin, а ios на Swift. Было бы хорошо их всех перевести на Kotlin. Тогда можно получить хорошую монолитную команду разработчиков.
Единый язык не означает, что можно будет легко с сервера переключиться на мобилы. Да даже в рамках одного языка-платформы разные фреймворки имеют существенную разницу и необходимо доучиваться. Например react-angular
На JS уже изобретено - сайт, iOS, Android, Windows (и электрон, и WinUI нативно, и джей скрипт), Linux (и даже NodeOS), MacOS, FreeBSD, СмартТВ (и веб, и с вендорными вставками), терминал, бекенд, база данных (MongoDB нативно исполняет JS), голое железо (через кросскомпиляторы, и не только ардуино), блокчейн, облачные функции, прикладные функции энтерпрайз софта, и я не удивлюсь если где-то на JS работает кофеварка. И вот вам и интерфейсы, и толстые и тонкие клиенты, под всё это бекенды с базой, на телике показать и, в случае особых потребностей, извратится во всех сферах где можно запустить код. И нужны только JS разработчики и ты властелин мира.
Идея не нова - уже была в Java с виртуалкой на всё что имеет хоть какой процессор, даже на пластиковые карты. Да и С++ так то многое позволяет.
Только вот во всех технологиях сразу чтобы подовсё есть нюансы…
Это не Андроиды предали Java, это бэкендеры застряли на Java. Мало того что есть куча гайдлайнов об использовании Котлина на бэке, уже не первый год существуют крутые библиотеки по типу Ktor. То есть есть куда осуществлять мягкую посадку. А то что Котлин на голову лучше чем Жава разработчики поймут очень быстро и сами начнут всем рекламировать язык.
А есть вариант перевести все на дарт )
-
Для работы на Flutter требуется знание языка программирования Dart. Разработчиков на Flutter тяжело найти на рынке — по данным того же hh.ru, сейчас их всего 1877 человек в России. Вы, конечно, можете нанять обычных Android- и iOS-разработчиков, но тогда надо будет потратить время на их переучивание. Без этого они и строчки не напишут.
Так всё просто, ищите фронтендеров, пишущих под реактивные фреймворки. Особенно под тайпскриптом. Цена доучивания будет копеечная.
Поскольку Flutter работает с языком Dart, то для настройки интеграции с нативными фичами — звонками или блютусом — придётся разрабатывать бриджи.
Забыли упомянуть, что бриджи под 99.99% функционала давно уже написаны сообществом.
В KMP же эта функция реализована нативно, следовательно SDK от производителя оборудования легко подключить. В итоге вы можете быстрее настроить интеграцию.
Ага, AirWatch, или как он там щас называется, подключите))
Да, конечно, во Flutter можно постараться и создать нативно выглядящий интерфейс под каждую платформу
Не можно, а нужно. Благо, что все элементы интерфейса, как Android, так и iOS, давным давно реализованы. И при этом вам, в большинстве случаев, не придётся писать ДВА интерфейса.
Как я и сказал выше, вам не придётся обучать всех разработчиков новому языку. Можно обучить iOS-разработчиков Kotlin или не обучать и оставить им только интерфейс и платформо-специфичные функции, такие как блютус.
Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
И в конце куча выводов, сделанных на неверных исходных данных.
Ну ок :)
Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
Сильно спорно. Особенно если кроме интерфейса в приложении есть что то еще. Любому кроссплатформенному разрабу нужно знать обе платформы под которые он пишет, имхо. Пусть не прям глубоко - но основы на уровне джуна точно, плюс нюансы некоторые которые только с опытом приходят.
Ага, AirWatch, или как он там щас называется, подключите))
Да вроде нормально подключаться должно. Просто expect/actual + в абстракции все заворачивать. Но да, местами менее удобно будет чем писать на чистом KMP. Впрочем AirWatch сам по себе шляпа та еще. Помню с вами пересекались на эту тему лет 5 назад.
В общем флаттер я поковырял для себя, и понял что пока предпочел бы котлин. Про KMP как раз возможно в свободное время займусь постепенным переносом частей кода на него в приложении над которым работаю. Немного поковырял - придется конечно что то выкинуть/заменить, что то переписать, но переиспользование неплохое получится когда приступим к разработке версии под ios.
Любому кроссплатформенному разрабу нужно знать обе платформы под которые он пишет, имхо
Но согласитесь, это несколько отличается от необходимости держать разработчиков под две платформы, чисто ради написания интерфейсов (что, кстати, весьма немалая часть приложения).
Да, Flutter-разработчик должен понимать основы работы обеих платформ и их нюансы, влияющие на работу приложения. Но это совсем не те же знания, которые надо для разработки серьёзного нативного интерфейса.
Помню с вами пересекались на эту тему лет 5 назад
Я тоже помню))
Так всё просто, ищите фронтендеров, пишущих под реактивные фреймворки. Особенно под тайпскриптом. Цена доучивания будет копеечная.
Вы замеряли это или может есть открытая статистика? У нас был негативный опыт погружения react-разработчиков в кроссплатформу, давно и на RN правда. В крупных компаниях, которые разрабатывают на флаттер и имеют большое количество разработчиков, это оправданно, тк в команде есть специалисты с опытом в мобильных приложениях. Если же людей мало, то вы всегда будете находиться в ситуации с рисками недостатка платформенной экспертизы.
Благо, что все элементы интерфейса, как Android, так и iOS, давным давно реализованы.
Реализованные виджеты не всегда ведут себя так, как на платформе.
Для примеров можно открыть тысячи issue платформ ios и android. Некоторые из них кажутся незначительными. Но есть и глобальные, например: 1, 2, 3 .
Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
По обучению - если в команде есть специалисты Android и iOS, то общую часть может начинать Android без дополнительного обучения (заменяются только библиотеки некоторые). Нативные iOS-разработчики после Swift достаточно быстро въезжают в Kotlin, особенно, когда приходят на уже готовый проект.
Единственный разработчик - это идеальная картина кроссплатформенных фреймворков, которая может работать для простых приложений на начальном этапе, до тех пор, пока не придется залезть в нативную часть из-за бага, нюанса платформы или пока приложение не вырастет.
Так всё просто, ищите фронтендеров, пишущих под реактивные фреймворки. Особенно под тайпскриптом. Цена доучивания будет копеечная.
Ага, и напишут они столько всего, что потом расхлебывать будете. Мобильному разработчику очень много думать нужно про то, что веб разраб не задумывается. Это нужно будет разрабу ломать шаблон мышления.
Забыли упомянуть, что бриджи под 99.99% функционала давно уже написаны сообществом.
Ага, и качество у них соответствующее. Баги если найдете и либа не сильно популярная - фисите сами, и дай бог овнер примит пуллреквест, иначе - будете жить с форком и меть геморой с подливом "мастера".
Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
Значит у вас не было сложного приложения с нативными функциями. У меня был такой опыт, очень и очень грустно когда нету специалиста под платформу. А просто лезть в незнакомые дебри - не продуктивно и кучу времени сьедает.
Ага, и качество у них соответствующее. Баги если найдете и либа не сильно популярная - фисите сами, и дай бог овнер примит пуллреквест, иначе - будете жить с форком и меть геморой с подливом "мастера".
Форкаете либу себе, в pubspec меняете зависимость на ваш форк ссылкой, пушите в свой форк фиксы, при необходимости fetch upstream одной кнопкой на гитхабе
Нет там геморроя
Есть у меня нативное приложение под android (compose). Получает данные с сервера, отображает, хранит данные в sqlite и делает бэкап в хранилище. Решил сделать его кросплатформенным: android+iOS+desktop+wasm. Выбирал между kmp и flutter. На Хабре топят за kmp, выбрал его (точнее compose multiplatform). И... Ничего быстро не получилось. В процессе выяснилось, что используемые мной сторонние compose библиотеки собраны только под android, а под compose multiplatform даже аналогов нет, нужно писать с нуля. Работа с файлами, получение разрешений, открытие диалогов открытия/сохранения файлов находится в composable функциях (т. к. это интерфейс) и это нельзя шарить между платформами, нужно под каждую писать свою реализацию, свои экраны. На это уйдёт много времени и по сути это как дублирование кода. Еще неизвестно с какими проблемами придется столкнуться под web.
Таким образом выбор kmp в разы увеличил время разработки, требует навыков разработки под ios. (Приложение пишу я один). Поэтому мне пока не понятны восхищённые отзывы об kmp. И теперь опять перед выбором: писать все с нуля и долго на kmp (всетаки как язык Kotlin нравится) или перейти на flutter и быстро получить результат под все платформы...
А довод про поиск разработчиков считаю невереным. Для разработки на flutter нужен один разработчик, для kmp два. Это же дороже в два раза. При этом сам язык Dart проще Kotlin, его изучить можно за пару дней (естественно имея базу из Си подобных языков).
В конце статьи написано, когда стоит выбрать Flutter или KMP.
Мне лично KMP очень нравится и я к нему привык, compose multiplatform так вообще один в один с jetpack compose и библиотеки можно практически без изменений копипастить. И надо понимать, что compose multiplatform еще сырой и поддержка ios только недвано появилась, поэтому необходимым либ мало совсем .
На счет разрешений, файлов и другого, можно без особого труда решить проблему через expect/actual и все будет отлично шариться. Да, что-то надо реализовать самому пока, но со временем появятся готовые либы, как это было с flutter. (возможно уже какие то либы есть из перечисленных, для файлов думаю точно должно быть что-то)
Короче через какое то время будет все супер и даже лучше
Вот полезная репа с kmp библиотеками и там есть для файлов и разрешений (но я ими не пользовался, поэтому не могу ничего сказать)
Спасибо за описание своего опыта!
Насчет наличия библиотек - выше подметили репозиторий с kmp-библиотеками. Он часто обновляется. В частности там есть библиотека для работы с пермишнами.
По невозможности шарить composable-функции между платформами - не очень понял. Есть официальные примеры, в этом же и суть.
Наличие библиотек только под android в compose понятно - пока именно compose-multiplatform развивается. И все библиотеки не будут моментально адаптированы сообществом. Нужно ждать беты и стейблы.
Про разработчиков писал в комментах выше. Нужно мерять не только простоту языка, но и его удобство, лаконичность, чтобы язык не ставил палки в колеса. Для разработчика с опытом и желанием не будет проблемой въехать в любой из высокоуровневых языков общего назначения. Swift и Kotlin достаточно похожы, поэтому в нашей команде ios-разработчики вкатываются быстро.
Кстати, наш android-разработчик в качестве pet-проекта разрабатывает приложение на compose-multiplatform (android, desktop, ios) без наличия опыта ios-разработки.
И эта статья не про восхищенный отзыв, а про сравнение 2 фреймворков через призму нашего опыта)
Jetpack Multiplatform для iOS использует skia, как и Flutter, до недавнего времени. В чем принципиалная разница? виджеты для iOS ненативные и там и там.
Все верно, использует skia. Но kmp позволяет не делать интерфейс через jetpack multiplatform. Вы в своем праве шарить только то, что вам нужно в проекте.
Даже есть эксперимент создания ui на flutter с общей логикой на kmp))
То есть UI на чем угодно дугом, кроме KMP?
Если нужен нативный UI, то да, если нет, то можно в KMP с помощью compose multiplatform сделать
Я к тому, что при сравнении с другими кросспдатформенными технологиями в достоинства KMP заносят нативный UI, в то время как UI в нем нет вовсе
Все имеют в виду, что платформа пилит UI нативно, а потом этот нативный UI можно законектить с KMP. Так что все правильно пишут, KMP позволяет делать приложения с нативным UI и это плюс, возможно просто формулировка не точная.
Вообще я вроде видел где-то, что прям в KMP вьюшки делают для ios и android и они нативные, но не могу вспомнить где (оставлю ссылку если найду). Есть небольшой шанс, что когда-нибудь в compose for ios сделают вьюшки нативно по аналогии с Android, но это можно сказать мечты, которые вероятно останутся мечтами :)
Вам в приложении нужно использование блютуса, приём звонков и другие нативные фичи
Это давным давно не проблема. Можно использовать Platform Channels.
Как я и сказал выше, вам не придётся обучать всех разработчиков новому языку. Можно обучить iOS-разработчиков Kotlin
А с Виндовс разработчиками что делать? Flutter поддерживает 6 платформ, а не только мобильные. + также можно писать модули для андроида на котлине, а модули для айос на свифте.
То что вы написали в статье - это ваше мнение, основанное на вашем опыте, в этот опыт не входит хорошее знание Flutter.
Что kmp, что compose multiplatform поддерживают разработку для windows. Но будем честны, остальные платформы - это скорее бонус, а не необходимость.
Там же JVM будет под капотом?
Нет, native
В комментарии вам процитировали текст относительно "не придётся обучать разработчика на другой платформе новому языку". Для винды на котлине мало кто разрабатывает. Т е Виндовс разработчика прийдётся обучать котлину, если хотите, чтобы ваша команда поддерживала разработку под Виндовс.
А вы ответили, что в котлин уже поддерживает Виндовс разработку. Збс логично)
Забыли упомянуть, что бриджи под 99.99% функционала давно уже написаны сообществом.
Кстати да, абсолютно верно.
Я бы еще добавил #5. Может я не правильно понял п. #3 но все же внесу свои 5 копеек.
У любого бизнеса могут быть разные задачи, и соответственно может быть разный дизайн под разные платформы. Таким образом, если дизайн будет розниться на том же iOS и Android (да, редко... но такое бывает), то смысла рассматривать Flutter совсем нет (по моему мнению), иначе дело заканчивается лютейшими костылями со стороны Flutter. Мне кажется это один из ключевых пунктов, по которому стоит рассматривать KMP, в качестве кросс платформы.
Всех благ! Статья понравилась.
Это как раз пункт про нативный интерфейс:)
Во flutter это как раз решается одним флагомif (Platform.isAndroid) и в зависмости от него разные виджеты подкидывать, используя общую логику работы.
+1 расскажем им про то, что ещё веб интерфейс отличается и все живёт в одной кодовой базе? Или пока рано?
Еще про ембедед и десктоп без JVM
и посмотрим на платформы Compose Multiplatform )
а если серьезно то вряд ли в ближайшем будущем что-либо пошатает позиции текущих веб фреймворков
В идеальном мире и в перспективе, лучшим может стать Котлин, но готовые решения и скорость развития flutter делают его сегодня номер 1
Кстати, а как во Flutter среде обстоят дела с юнит тестами? Гонятся ли они параллельно? Удобно ли работать с моками?
С автором в целом согласен, но по моему не подсвечена проблема производительности Flutter. Видимо, связанная с отсутствием вразумительной работы с нативным жизненным циклом.
К плюсам KMP также следовало отнести готовность Гугл поддержать рублём любые вклады в их продукт (создать или переписать либы). Это было озвучено на одном из недавних KotlinConf...
Вот меня удивляет в российском АйТи то, что все сидят на каком-то устаревшем стеке и гордятся им как последними достижениями человеческой мысли. KMM изначально был временным решением, неким MVP. И после переименования в KMP, он принципиально не поменялся. А вы его тут расхваливает как замену Flutter.
Ничем подобным он никогда не являлся.
Реальной заменой Flutter является Jetbrains Compose Multiplatform, который делается на базе Google Jetpack Compose. И это реальная и мощная замена Flutter-у, а не костыль KMM. И для этого продукта не нужно придумывать надуманные аргументы типа Dart выучить тяжело. Да ничего сложного в нем нет. Не в этом проблема Flutter-а. А в том, что у него канва своя и он плохо учитывает особенности платформ. Да ещё и Dart не стал популярным и экосистема не такая богатая как в других языках.
А если смотреть ещё дальше, то в ближайшие годы развернется серьезная битва между Kotlin и Rust. Но в России об этом узнают лет через 10-15, как всегда.
у Jetbrains Compose Multiplatform тоже своя канва в той же Skia, с котторой Fluttter съехал в iOS
Откуда взята информация, что KMP - устаревшее решение? Было бы хорошо, если бы вы пояснили свою мысль
В статье не упоминается KMP как "замена" Flutter. И KMP таким действительно не является. Он не целится в переиспользование UI (хотя compose multiplatform и позволяет это делать) в этом и заключается одно из преимуществ - шарьте только то что нужно вам. Почему вы считаете это костылем?
Использовать compose multiplatform не будет возможным без KMP.
Выучить новый язык не составит сложностей разработчику с опытом, да это и не утверждается в статье. Но очевидно, что распространение Kotlin выше чем у Dart. Dart используется в основном на флаттере и больше нигде. В веб разработке с него ушли, например Wrike.
А почему нет сравнения, какой Framework больше поддерживается? Я сомневаюсь, что разработчик захочет все с 0 писать а не брать готовое решение. По поводу нативного дизайна, тоже не понял, если речь идет о мобильной разработке, а другого в статье не приведено, у Flutter есть набор виджетов Material и Cupertino , которые с этой задачей справляются. Дальше, почему не сказано, сколько платформ поддерживает KMP? Это тоже может стать решающим фактором. Аргумент про сложность Dart тоже такой себе, язык вообще не сложный. Единственным минусом Flutter могу считать размер собираемого файла, но здесь я это тоже не увидел.
Дальше будет статья "Почему нужно взять .NET MAUI вместо Flutter если у вас штате только С# программисты?"
p.s С KMP не работал, поэтому статья стала интересна, но по факту все аргументы, сводятся к тому, что если знаешь Kotlin то выбирай KMP.
Что flutter, что kmp в stable. Ни для кого не секрет что flutter в стейбле дольше. Тут не нужно проводить сравнение. Не очень понял что значит писать с 0 или брать готовое решение.
Про ui отвечал в комментариях выше
KMP поддерживает ios / android / desktop / web. Будем честны, немобильные платформы редко берутся в расчет при выборе этих технологий. Desktop нераспространен, в web много своих нюансов.
В статье не приводится аргумент про "сложность" Dart. Ответил выше
Сравнение .NET MAUI и KMP некорректно в данном плане - Kotlin нативный язык для Android. И при разработке сложных мобильных приложений разработчику все равно нужно будет знать нативную платформу.
Сравнение .NET MAUI и KMP некорректно в данном плане
Здравствуйте, если вы так топите за мультиплатформу, то, тот же C# можно взять вообще везде. Связка (.net, blazor, .net MAUI) тоже перекрывает все нужды. Повторюсь еще раз, вся ваша статья просто восхваление KMP , я тут не увидел адекватной критики.
Kotlin нативный язык для Android.
А Swift вообще не нужен получается? Если так, почему это в плюсы не приведено?
без свифта с KMP никуда! там и котлин и свифт нужны!
как уже подсвечивал в статье, знание 2 языков не является обязательным требованием
с использованием Compose multiplatform количество Swift-кода уменьшается
ну и для написания платформенно-специфичного кода во flutter swift тоже нужен.
Пожалуйста, перечитайте статью, C# не удовлетворяет ни 1 из приведенных сценариев.
Swift используется при реализации нативного UI ios-платформы. Не вижу с этим никаких проблем. Вся кроссплатформенная часть пишется на Kotlin. В том числе внутри кроссплатформенной части можно обращаться к нативным функциям платформы на Kotlin.
4 сценария, когда нужно сделать ставку на Kotlin Multiplatform, а не Flutter