Комментарии 30
KMP выглядит перспективно, но пока коллеги очень противоречиво о нем отзываются. Даже то, что проект для КММ не создаётся с нуля в студии, а где-то в стороннем решении это уже печаль.
Плюс, даже вы указали, что либ нет или мало. Что делать когда нужно что-то, а этого нет? Писать руками. Но у флаттера это все в минус запихивают, а у кмп почемуто молчат, хотя это самое важное. Компоуз - это прямо привет из флаттера.
Далее, горячая перезагрузка, даже для иоси - это просто божественная штука экономящая десятки часов времени. В Кмм - облом, перекомпиль, перезапускай.
И ещё. Сделать приложения для яблока и для дроида в Кмм одним разрабом пока или нельзя, или очень сложно. А флаттер даёт это. И это тоже колоссальная экономия для заказчика.
Производительность, если присмотреться к тестам очень близка к нативу. А платформ каналы это не реакт, они реально могут перегонять тонны данных.
Так что сложно все это. Нужно ещё времени, чтобы разработка на Кмм была такой же лёгкой как на флаттере.
Ещё в нативке есть кучи всяких фреймворков, DI, подходов. И это создает ад. Я еще и нативщик. Но когда мне говорят "давайв го в легаси" у меня дрожь по телу. Потому что никогда не знаешь, что там напридумали. Во флаттере кол-во пакетов и подходов в разы меньше.
А еще флаттер прост в обучении, и за 4-6 месяцев джун уже неплохо им овладевает и спокойно выполняет работы мидла.
Сторонее решение не обязательно, можно создать проект тут https://kmp.jetbrains.com/
Думаю что стоит начать с того, что KMP ещё в бета, и, вероятнее всего, потому гугл и не занесли в студию создание проекта KMP по дефолту (а может никогда не занесут), но странно что это причина для расстройства, создать KMP проект не проблема, на сайте jetbrains (см. комментарий выше) или из репо Цховребова (https://terrakok.github.io/Compose-Multiplatform-Wizard/) где можно собрать проект с нужными либами, которые уже работают в мультиплатформе. Да и работать над проектом не обязательно в студии, jetbrains предлагает использовать fleet, сам я использую обе IDE.
По поводу либ, да, не все либы портированы на все платформы, но есть относительно удобные механизмы для того, чтобы использовать специфичные либы на отдельных платформах, Розов собрал актуальный список либ (https://github.com/androidbroadcast/AndroidToKMPState), которые можно заюзать в мультиплатформе, ну и собственно в конструкторе проектов от Цховребова перечислены только полностью мультиплатформенные (насколько помню). И если взглянуть на список полностью мультиплатформенных библиотек, то видно что их достаточно для многих проектов.
Архитектурный подход и DI на проекте вы устанавливаете сами, и делаете единый на весь проект, наверное только из каких-то иррациональных побуждений разработчик будет применять разные паттерны, но и тут за нас уже все придумали, совсем недавно выходила очень хорошая статья на хабре о том как правильно организовывать архитектуру проекта https://habr.com/en/articles/824048/ . Помимо этого есть очень хорошие библиотеки для MVI, например MVIKotlin (Аркадия Иванова), которые избавляют нас от головной боли по архитектуры и специфичных провайдов.
Печально каждый раз видеть, как люди путают Kotlin Multiplatform, который уже давно Stable, и Compose Multiplatform, который Stable для Android и Desktop, Beta для iOS и Alpha для Web. В этой статье вообще про Compose Multiplatform пара предложений (видимо, автор оригинального материала не вполне в курсе последних апдейтов и релизов), а между тем фреймворк уже сейчас вполне может соперничать с Flutter. По пути своего развития он будет собирать все те же проблемы, что и Flutter: производительность, поддержка собственного канваса на iOS, баги платформенных реализаций под капотом, и т. д.
Но гибкость Compose Compiler и Compose в целом как инструмента реактивного декларативного UI рвет на части все. Будем дальше наблюдать за этой эпической битвой)
полностью согласен. Пробовал как то писать на kmp с compose и понял, что это очень сырой инструмент, ну или же я не понял его фишки. На флаттер я могу написать среднее по объему приложение за 2 недели, благодаря большому количеству пакетов, большому коммюнити и простоте написания. А в KMP мне придется либо отказаться от компоуз и использовать нативный ui, так как ui библиотек очень мало(я лично столкнулся с тем, что не было ar sdk), а некоторые не stable. Также просто убивает настройка gradle. Я конечно не прокачаный сеньор, но не советовал бы использовать kmp(Если только ваше приложение не строится на нативных возможностях), тем более flutter в производительности практически ничем не уступает. И автор в статье приводил пример со сканом штрихкодов на флаттер. Я недавно делал проект со сканером и у меня проблем со скоростью не возникало. Была проблема если в приложении было несколько экранов, использующих разные пакеты для управления камерой, но эта проблема решилась правильной сменой контроллеров камеры. Короче, язык котлин я люблю, но kmp меня разочаровал.
Подписываюсь под каждым обзацем, + Киркоров довольно мудро сказал, что каждый хотя бы раз в жизни входит не в ту дверь, окей Гугл, в какую дверь пойдём после КМП?
Flutter vs. Kotlin
Вы фреймворк и ЯП сравниваете?
В оригинале этой глупости нет.
Вместе с приложением загружается движок Flutter, который добавляет к общему весу приложения 3-4 МБ
Т.е. размер приложения Flutter всего на 4 Мб больше чем размер приложения KMP? Раньше кажется разница была около 30 МБ
Сейчас весь store завален приложениями по 150-200 Мб, хотя раньше они занимали около 30 Мб. Думаю это из-за перехода на Flutter, а не из-за контента. Считаю такой размер очень большим. Приложений же не одно на телефоне и когда они обновляются, то за раз скачивается несколько Гб. Не везде еще в России хорошая связь да и трафик на многих тарифах не безлимитный. В свое время отказался от Flutter из-за размера приложения.
Ну сейчас уже выигрыш в размере у KMP надо Flutter не актуален). Это как на спичках экономить).
Думаю это из-за перехода на Flutter, а не из-за контента. Считаю такой размер очень большим.
Вы это серьёзно? На какой версии флаттера вы остановились из-за размера приложения? В каком году это было? Попробуйте установить флаттер и собрать приложение на флаттере и КМП, размер будет в худшем случае на 4 мб больше, а в большинстве случаев размер приложений такой же как у нативных. Я перешёл на флаттер с натива, мне есть с чем сравнивать. В плей сторе большой вес имеют приложения, собранные на unity и unreal. И то что в России интернет "не только лишь везде" - это не проблема флаттера.
И вообще в плей стор грузится формат aab, который подгружает и обновляет только необходимые библиотеки.
если вы не хотите разбираться в куче разных фреймворков, если вы не разрабатываете приложение для знакомого с ИП, если вы хотите хорошо, поддерживаемо и надолго - выбирайте натив
а для всего остального конечно, можно изгаляться как угодно, лишь бы попасть в свои хотелки с изучением нового, ускорением=удешевлением разработки и тд
Представьте, вы создали успешный продукт, который взлетел на Android. Что дальше? Собирать команду для реализации на iOS? А потом ещё придётся адаптировать его под Аврору. А завтра выйдет Kaspersky OS или что-то ещё. В наше время нужно серьёзно задуматься, прежде чем начинать разрабатывать продукт на нативе.
если вы не хотите разбираться в куче разных фреймворков,
Просто выбираете Flutter и на первом этапе больше ничего не надо.
хотите хорошо, поддерживаемо и надолго - выбирайте натив
Вы считаете, что приложения, созданные с использованием Flutter, работают плохо, не поддерживаются и имеют недолгий срок жизни? Хотелось бы услышать более конкретные замечания по этому фреймворку. И почему натив - это хорошо и поддерживаемо?
Если вы не разбираетесь ни в нативе, ни в фреймворках - не пишите свою философскую ерунду.
Жаву в нативе сменил Котлин, обж-с сменил Свифт и куча народу бегает в поисках специалистов, которые переписали бы старый натив на новый натив. Где ж надолго Карл?
Заменили бы во flutter dart на kotlin…
Чтобы избавиться от горячей перезагрузки и получить возможность быстрее делать модельки?
Я писал года 2 на котлин. Хороший язык я не спорю. Но дарт я на котлин не променяю.
А чего вам не хватает? Скобочки не те? Ну есть немного. Или расширений и ютилити функций нет? Ну так их можно отдельной либой сделать.
Для себя я ориентируюсь на то, как к своим продуктам относятся их создатели.
Без Котлина уже трудно представить себе JetBrains. Они его создали и вкладываются. И вполне успешно.
Дарт для Google сейчас выглядит как побочный продукт. Дарт - язык неудачник. Одна из его первых задач была заменить Яваскрипт. Ну, и чтобы не пропала работа приспособили к Флаттеру. Это, конечно, не означает, обреченность и этого проекта, но, что называется, осадочек остался.
Без Котлина уже трудно представить себе JetBrains
Ну больше наверно Koltin не представишь без JetBrains, а других у JetBrains языков нет.
Дарт для Google сейчас выглядит как побочный продукт. Дарт - язык неудачник.
У Google много направлений, это откуда такая инфа? Есть не решаемые проблемы с Dart? Хотя наверно в вашем мире Flutter уже давно похоронен Google, а Flutter разработка держится только на энтузиастах из сообщества.
Я вам открою секрет, Dart и Flutter очень сильно развивается, обновления выходят чуть ли ни каждую неделю. И основным драйвером развития как раз является Google. Где вы увидели плохое отношение к Dart у Google?
Инфа про то, что побочный продукт или про язык - неудачник? Побочный продукт следует из "язык - неудачник", а про яп пытавшийся заменить JS можно и в вики найти, ну или быть живым свидетелем.
Я ни в коем случае не умоляю достоинств Flutter. Даже наоборот с энтузиазмом следил несколько лет. Но, все это время, как, вероятно, и многие другие. не могу отделаться от мысли, "ну, почему не Kotlin??"
Тут есть еще причины стилистического и синтаксического характера.
Например, фронт-енд разработчику, привыкшему к React и Typescript, интересны два варианта либо React Native либо Kotlin Compose. С Native связывает JS/TS, а с Compose синтаксически схожий с TS Kotlin. А Dart "ни то, ни сё". В этом дилемма.
Flutter vs Kotlin Multiplatform: что выбрать