Flutter — Евгений Сатуров. Введение в позицию
Представьте фреймворк, который позволяет верстать UI декларативно, получать высокопроизводительный результат и стабильные 60 fps. При этом он поддерживает шесть платформ, умеет компилироваться в Wasm и напрямую общается с платформенными API. А ещё у него функциональный туллинг, который заточен под эту технологию, и стабильно работающее моментальное применение изменений при отладке. Всё это обещает нам Kotlin Multiplatform.
И то же самое уже пять лет предлагает нам Flutter, который разработала и развивает корпорация Google. Если решение существует и развивается столько времени, значит это кому-то нужно. Приложение для миллионов водителей и курьеров Яндекс Про написали полностью на Flutter. Видеостриминговое приложение The Hole, которое работает даже на слабых устройствах с плохим интернетом, тоже создали на этой платформе. И эти примеры наглядно иллюстрируют утверждение: если что-то можно реализовать, то это можно сделать на Flutter.
Если мы посмотрим на уровень популярности этих двух технологий в русскоязычном сегменте интернета, то увидим, как Kotlin даже немного опережает Flutter. Мировой же тренд совершенно другой — здесь Flutter почти в три раза рвёт Kotlin.
Но это мы сравнили платформу с языком программирования. Kotlin Multiplatform на самом деле почти в 30 раз менее популярен, чем обычный Kotlin, и почти в 100 раз менее популярен, чем Flutter. И за последние годы интерес к этой технологии практически никак не изменился.
Ещё одна интересная метрика востребованности технологий — популярность на Stack Overflow. Она включает количество активных разработчиков, которые используют эту технологию, и количество начинающих разработчиков, которые только входят в неё. По популярности на Stack Overflow у Flutter нет равных не только в сравнении с Kotlin, но и в сравнении с другими языками программирования.
А что, если Google убьёт свою платформу, как он обычно делает со всеми своими технологиями и продуктами? Этот вопрос нам задают на протяжении пяти лет. Мы вспомнили все продукты, которые компания убила за последнее время, и обнаружили, что самый опасный возраст, когда она обычно расправляется со своими детищами, Flutter уже успешно преодолел. И чем дальше, тем меньше вероятность того, что эта участь его всё-таки постигнет.
Многие платформы уже применяют Flutter как основной инструмент для расширения функциональности. А сейчас стало известно, что операционная система Fuchsia будет использовать эту платформу как основной фреймворк для разработки приложений. И я должен констатировать факт: сегодня всё меньше причин использовать что-то, кроме Flutter, для своего следующего мобильного приложения с нуля.
KMP — Алексей Гладков. Введение в позицию
За Kotlin Multiplatform скрывается язык программирования Kotlin. И он, в отличие от Flutter, позволяет нам заглянуть куда угодно. Хотите быть физиком, бэкендером или мобайл — для всего подойдёт Kotlin. Вы можете изучить один язык и писать на нём всю оставшуюся жизнь. У вас никогда не будет проблем с работой и со всем остальным.
Kotlin — кайфовый язык, на нём очень удобно писать. Я как-то писал на Flutter, потом пришлось глаза восстанавливать. А от Kotlin получаешь настоящее удовольствие. Ещё у него очень простая функциональная зависимость, которая помещается буквально на три строчки. Всё, что вам надо, — объявить либо интерфейс, либо expect-actual, и вы в игре. Ничего не нужно делать дополнительно.
Вы сами можете выбирать, насколько глубоко хотите интегрировать KMP в ваш проект. Вам не надо переходить полностью на Flutter или оставаться полностью на нативе. Вы можете перенести одну функцию, один запрос, переписать всё, включая или не включая UI. Выбор за вами.
С Kotlin у компаний никогда не будет проблем с наймом, потому что разработчиков, которые используют этот язык программирования, огромное количество. Согласно недавним опросам, 54% JVM-разработчиков уже перешли на Kotlin, а любой разработчик на Kotlin буквально за две недели становится разработчиком на KMP — проверено уже на нескольких организациях.
Многие крупные российские компании сделали выбор в пользу KMP или хотя бы попробовали его. Среди них есть и Яндекс, который сделал несколько продуктов на этой платформе. В мире тоже большое количество компаний ушли в Kotlin Multiplatform. Например, Forbes недавно объявили, что они перенесли своё приложение на KMP. Так что желающих внедрить эту технологию много.
Google тоже поддерживает KMP. Все библиотеки постепенно перепишут на эту технологию — вы просто берёте своё интернет-приложение и запускаете его на iOS. Я считаю, это прекрасно.
KMP — Алексей Панов. Раунд кода
Давайте начнём с простого — с вёрстки. Обратите внимание, как лаконично смотрится код на Compose в отличие от кода на Flutter. В последнем мы пишем в два раза больше кода, чем на Сompose, и это только Hello, World! Представьте, что творится в продакшене проектов. Наверное, именно поэтому у них три миллиона строк кода.
Теперь посмотрим на интероп с UI. Чтобы засунуть Compose-экран в iOS, нам достаточно обернуть это в ComposeUIViewController, и всё будет работать. А чтобы интегрировать Flutter-виджет как Android View, придётся продать душу дьяволу и написать примерно миллион строк кода. И всё равно у вас ничего не получится.
Если говорить о реальном интеропе с платформой, в KMP всё шикарно работает. У нас есть механизм expect-actual, который позволяет нам переопределять поведение для разных платформ. Благодаря гибкости source sets мы можем обозначить и для всего native-таргета, и для конкретной архитектуры. Кроме того, у нас есть эстетическая типизация — если вы забудете указать что-то для конкретной платформы, компилятор даст вам по рукам, и проект даже не соберётся. А во Flutter же платформенные плагины, и если вы забудете определить этот платформенный плагин на какой-то платформе, то просто упадёте в рантайме, а не в компайл-тайм.
Многопоточность тоже довольно важное свойство для выноса вычислений на фоновый поток, чтобы наш UI не лагал. В KMP мы можем сделать всё это с помощью одного оператора, и довольно гибко. Захотели — задали последовательное выполнение на фоновом потоке, захотели — добавили несколько операторов, и выполнение стало параллельным. А чтобы сделать аналог первого метода на Flutter, придётся написать огромное количество кода. Здесь мы создаём какие-то порты, обмениваемся сообщениями, делаем специфичную обработку, и при этом у нас ещё куча ограничений.
Кодогенерация тоже важный механизм, чтобы избавиться от шаблонного кода. Рассмотрим на примере сериализации JSON. Чтобы сделать это в KMP, достаточно добавить одну нотацию и один раз подключить Gradle-плагин. Во Flutter же мы будем обращаться к сгенерированному коду и каждый раз выполнять команду, чтобы весь этот код регенерировать.
И это ещё далеко не всё. В проблемах Flutter можно упомянуть и примитивную систему сборки по сравнению с Gradle, и отсутствие устоявшихся подходов для реализации многомодельности, и непопулярный язык Dart. Так что у Flutter есть будущее только с Kotlin, но у Kotlin уже есть свой Flutter, и имя ему Compose.
Flutter — Геннадий Евстратов. Раунд кода
Flutter — это единая платформа, на которой пишут люди. А Kotlin Multiplatform — набор каких-то штучек, которые, прежде чем адаптировать под разные платформы, нужно понимать, как устроена каждая из этих платформ. Например, во Flutter мы можем сделать сложные анимации легко и всего в пару строчек. И все возможные физики прокрутки — более частая задача, чем вычисления списка простых чисел.
Об асинхронных действиях хочется сказать чуть подробнее. В Dart Flutter всё просто: есть async, есть await, и буквально в одну строку можно асинхронно что-то сделать, подождать выполнения и продолжить дальше. В KMP так не выйдет.
Если хочется чего-то более сложного, то с изолятами работа происходит не в двести миллионов строк, а в четыре строки, если мы говорим только о Dart, и в одну — если о Flutter. Тяжёлые действия выносятся на антипоток, вычисляются, и мы получаем их результат.
Самое главное — на KMP написано очень мало приложений в отличие от Dart. По последней статистике, больше 20% приложений в Google Play сделаны на Flutter. А ещё Flutter занимает третье место на GitHub среди опенсорс-проектов по количеству контрибьюшена.
И можно попробовать сделать ставку на какую-то новую, непонятную и сложную технологию, как мы сделали это пять лет назад и не проиграли. Но нужно ли это, если уже есть готовая и хорошая технология?