Комментарии 39
На самом деле крайне не корректно сравнивать Xamarin с RN и FL. Xamarin это платформа нативной разработки. С многопоточностью и прямым доступом к API операционной системы. У RN и FL надо писать нативные прослойки для прямого доступа к API операционок, а многопоточность в принципе отсутствует из-за скриптовой природы движков. Dart и V8 близкие родственники.
А если уж и добавлять в сравнение то MAUI. Это перезапуск фреймворка Xamarin Forms. Который позволит писать единый интерфейс + плюшки Xamarin.
Сам выбираю React Native для мелочевок, т.к. активно переиспользую код с вебом и Xamarin для чего то серьезного. Во flutter я ни код переиспользовать не могу, ни нативных плюшек нет.
Добавленный сюда Xamarin - это стёб. Опять же, ничего не имею против, и это может быть тем, что когда-то выстрелит, но сейчас это совершенно не конкурент ни для Flutter, ни для React Native.
А вот с "невозможностью" переиспользования кода во Flutter - интересно. Какие у вас кейсы, что для веба Flutter не пригоден? И какие именно нативные плюшки вам нужны?
Для веба флаттер не очень пригоден пока(по мне), точнее если хотите быть бетатестером, не важна оптимизация по ресусрам (хз что там генераторы натворят) то велкам.
писал на flutter в основном для web ~ 2 года, когда он еще был то ли в бете, толи еще в чем. медленно работал в 3-4 х(чем если б на js), либы flutter в основном не подходили для web, js либы тоже не подключишь, качество кода middle-web было таким, что переделал половину элементов. криво-косо работали, вменяемый саппорт отсутствовал. плюнул и ушел на vue, когда новый dart сломал совместимость с написанными и используемыми либами. vue и web тоже не мед, но то было пыткой.
Добавленный сюда Xamarin - это стёб. Опять же, ничего не имею против, и это может быть тем, что когда-то выстрелит
Xamarin был признан несколько мертвым решением для multiplatform, вместо него пришёл MAUI, не то, чтобы официально, но во всяком случае MAUI принес много благ для этого (https://github.com/dotnet/maui/wiki/Xamarin.Forms-vs-.NET-MAUI)
Замечания по поводу использования словосочетаний "написано на Flutter" и "написано на React Native" - я бы, будь я на вашем месте, поправил на "написано на Dart" и "написано на JS". Так как FL и RN не языки, а библиотеки/фреймворки для языков. то есть, правильно использовать можно только в словосочетаниях "написано во Flutter" и "написано в React Native".
Да будет Holy War, снова.
Если говорить о самих Flutter и React Native, то для каждого решения (продукта) необходимо правильно выбирать путь его достижения. Flutter не может быть (и не является) путем достижения покрытия 100% потребностей, как и React Native не может быть (и не является). Поэтому, если говорить полностью объективно: React Native is not better than Flutter but Flutter is not better than React Native.
И сравнение их может быть только в рамках одного определенного продукта, который могут реализовать как Flutter (на языке Dart), так и React Native (на языке JS) со стопроцентным покрытием. И то, даже в таком случае, рассматривать стоит не со стороны автора другой статьи, а со стороны всего процесса разработки и решения определённых бизнес задач:
Нужно быстро - RN
Нужно качественно - Flutter
Нужно быстро и качественно - ни один из них, насколько бы большой и/или опытной не была команда. Большая команда не равно качественный продукт быстро - всегда будет тот, кто где-то что-то сломает/опоздает/не так поймет и тд. Огромный опыт не равно качественный продукт быстро, так как опыт понятие относительное, и можно разбираться в одной области языка, но быть профанов в другой его части, а найти того, кто разбирается во всём - вопрос финансовый, и стоить будет дороже самого решения, для которого и требуется данный специалист.
Вопрос о библиотеках для RN/FL - есть решения что там, что там, но не всегда эти решения подойдут к тому или иному вопросу, который они решают. Рассматривая, как пример, то огромное число библиотек для JS, где даже популярные решения не смогут решить свой же вопрос в рамках несколько отличительных особенностей использования (примечание как пример: очень популярный PDF.js не будет работать в полностью OFFLINE режиме)
И множество множества других вопросов, о которых можно поговорить, но тогда статья превратится в отдельную книгу с названием:
React Native is not better than Flutter
but Flutter is not better than React Native
И, если говорить коротко, то React Native и Flutter - это очень хорошие библиотеки/фреймворки для решения задач с multiplatform, но они будут проигрывать друг другу в том или ином сегменте при разработке какого-либо определенного продукта.
PS: для решения multiplatform можно использовать RN, FL, MAUI, Java Crossplatform, Xamarin, Apache Cordova и множество других решений, и все они будут лучше друг друга, но и хуже друг друга в тоже самое время :)
PPS: не хочется углубляться в более подробные моменты, может будет тот, кто действительно выпустит подобную статью/книгу, где будет всё полностью и подробно расписано: "где, когда, как и какое решение лучше использовать, где, когда, как и какое решение лучше не использовать, где, когда, как и какое решение можно использовать практически наравне с другим решением (и как выбрать чуть более правильное)"
PPPS: я отношусь одинаково ко всем решениям: знаком с каждым из них не понаслышке, и я сделал свой выбор в пользу одного из них, но говорить о нём не буду :)
Вы видимо путаете Xamarin и Xamarin Forms.
Xamarin это набор компиляторов. Сейчас занимает долю 50% всех мобильных 3D игр. Ведь Unity3D работают именно на нем. Ближайшие конкуренты юнити тоже. В обычных приложениях он тоже отлично себя проявил в таких компаниях как боинг, аеробус и банках.
Xamarin Forms это кроссплатформенный фреймворк для интерфейса. Вот с ним действительно было все плохо. Но Майкрософт его выкупила вместе с Xamarin, переписала, переименовала в MAUI и вот вот он выйдет в свет.
Таким образом Xamarin не конкурирует с RN и FL, он конкурирует с нативными языками Kotlin/Swift. А с RN и FL будет конкурировать MAUI (бывший Xamarin Forms).
А чего вам не хватает то из API прослоек, всеж давно прослоилось то за вас, разве нет? Многопоточность вам для чего в UI слое? Соскучились по решению головоломок?)) Есть фоновые процессы, там выполняйте тяжелые вещи.
Например стриминг с камеры на свой сервер с нужными параметрами. Реализуется только нативно через камера апи 2.
Никакие фоновые процессы не заменят простоту, гибкость и удоство шарпового многопоточного async/await.
А может кто написать немного про Kotlin Multiplatform? Является ли конкурентом эта платформа?
Вполне, сам не щупал так как слишком новое, не хочется быть бетатестером.
Так как технология весьма новая, сейчас сказать однозначно сложно. А учитывая, что новым считается то, чему меньше хотя бы 10-ти лет, то тут только время покажет. Еще ведь .NET MAUI вышла, как замена Xamarin, однако кроме замены Xamarin в мире мобильной разработки ей, к сожалению, еще не нашли применения
Все конечно круто в Flutter, кроме того, что оно до сих пор лагает на ios.
И что? Вот вы пишите:
В целом, кто бы что не говорил, но едва ли наступит тот день, когда "среднее по больнице" приложение, написанное на RN вдруг станет работать быстрее, чем такое же, но написанное на Flutter. Можете скриншотить.
По факту приложение на Flutter лагает из коробки. А приложение на RN - нет.
Модель на которой лагает? Я работал с нативной частью и в RN и FL реализуя один функционал. Могу сказать чтобы перегнать 300kb (json + изображение)с натива в RN нужно ставить прелоадер, потому что тормоза. Во FL это абсолютно незаметно.
В целом, в RN приятно потому что знакомый JS. Потому что можно приложение обновлять без стора - это киллер фича, блин! Просто киллер фича! В остальном флаттер стабильнее и куда шустрее.
Может быть RN получит второе дыхание когда во всю реализует турбомодули, работу с нативом по новому, но это поломает кучу готовых пакетов.
У вас может залагать приложение RN когда вы реализуете все что хотели, потому что может быть потолок по FPS для вашего макета. Демка конечно важная часть, но вы можете тикет завести с проблемой FL в гитхабе, записать и залить скрин видео, там в течение двух суток ответ прилететь может.
IPhone 12 Pro
Недавно выпустили Impeller. Решает проблемы на раз.
https://github.com/flutter/flutter/wiki/Impeller
Наконецто однодумцы!)))
Ну ок, статья написана любителем Flutter, но честно говоря - какая-то вода.
Что не так со сборкой? C Expo? Он хоть понимает сколько времени экономится, когда обновления pull-requests раскатываются по воздуху за несколько десятков секунд, а не сборка бинарей на каждый чих?
Добавление возможности SKIA сделало инструмент менее гибким или более гибким? Нативные контролы никуда не делись, появилось больше возможностей.
Нативная навигация во Flutter не работает, и это видно.
Особенно странно читать про компактность Dart vs JS/TypeScript. Непонятно
Шаринг компентенций и кода работает, хотя конечно не так что любой человек делает что угодно.
React/TypeScript разработчики отлично вкатываются в RN, при условии что в мобильной команде есть мобильный лид, который ообъяснит про платформу и разницу между роутерами и навигаторами.
Что за сборка бинарей? Флаттер аналогично реакту налету отрисовывает ваш макет. Так же есть возможность его отладки, тыкая мышкой Аля девтулс.
Нативная навигация во флаттер не работает? Что имеется ввиду? Можно внедрять флаттер в приложение постепенно, оставляя сложные экраны на нативе, переписывая другие на дарт.
По поводу бинарей
Я имею ввиду не hot reload в процессе разработки, это и так понятно. Я имею ввиду невозможность во Flutter следующего workflow
Я создаю бранч с задачей, делаю pull requst
Делаю публикацию "по воздуху" полученного JS бандла, получаю ссылку. В принципе это вообще автоматизируется через github actions
QA заходит по ссылке, JS бандл скачивается ему в Expo/актуальную сборку
Оставляет комментарии, если нужно
Я коммичу / публикую обновления - JS обновления подтягиваются QA за десятки секунд
Это очень ускоряет процесс, когда не надо ничего компилировать/загружать куда-то для того чтобы показать изменения другим участникам команды.
Также, используя эту фичу, можно "по воздуху" разливать исправления каких-то багов, минуя публикацию в апп стор
Это работает потому что RN сделан на JS, а не компилируется, соответственно - есть несколько реализаций "обновлений по воздуху" - инструмента, который проверяет наличие "в облаке" более свежих версий JS бандла, и, если они есть - то скачивает и запускает уже обновленную версию. В реале все чуть сложнее чем "более новая версия" - есть версии приложения и релиз каналы, но это как раз следствие реальных процессорв разработки
Это похоже на то, как если бы у вас на каждый pull-request разворачивался бы на сервере докер именно с этой веткой.
По поводу навигации - наверное так можно, но для этого нужно писать уже "нативное" приложение, с подключенным Flutter View, на react-navigation вы не покидаете уровень react-native, описываете декларативно всю навигацию как компоненты, и она рендерится платформой - все эти правильные свайпы "назад" на iOS c затемнением, при желании - анимации заголовков, и так далее. Когда я изначально смотрел на Flutter - там с этим было совсем тоскливо с попыткой воспроизвести это на SKIA, в 3.3 - не знаю, но всегда было видно что это какая-то анимация, а не нативная для iOS навигация.
И js компилируется, просто очень быстро. Дарт вроде бы тоже не так долго. То что обновление приложения по воздуху не из стора, это да, это офигенно. Я рендерил идентичный список listview и в rn и fl с нативной платформы из json. Визуально разница была ооочень заметной. В fl это просто пуля, ui точно был шустрее. Потом я отказался от json и выводил с натива структурами, которые реакт сам умеет понимать типа примитивов map. В RN начала срабатывать оптимизация, отрисовка стала ленивой. Стало шустрее, но по мере первого скролла данные визуально начали подгружаться. Первый слайд вниз медленный. Может конкретно у вас что то было на ios, но у fl общение с нативом крайне шустрое.
Как я и упомянул, единственный (по моему мнению) объективный плюс RN - CodePush. Этот плюс у него есть и относительно нативных способов разработки, но значит ли это, что из-за этого плюса нативная разработка более не применима? Если нет - то это не значит того же и относительно Flutter. Потом, процесс тестирования (именно во время разработки) в случае с Flutter не является сколь бы то ни было сложным или долгим (с любых точек зрения) - если есть CI, то на любой чих можно сделать билды сборок, автоматически доставляемые в интересующий вас канал (например - Firebase Distribution), которые доступны для тестировщиков в течение нескольких минут. Поэтому разница в этом аспекте по сравнению с RN будет заключаться только в том, что тестировщику RN-приложения достаточно будет лишь открыть уже установленное приложение для тестов, а тестировщику Flutter-приложения - установить новую версию поверх старой (~ 1 минута - максимум).
Относительно публикации обновлений приложения "без сторов" - круто, все так, но зыбко. И я, с точки зрения бизнеса, не стал бы делать ставку на какую угодно технологию, полагаясь на серую зону и то, что она никогда не станет черной.
я абсолютный фанат Flutter
Фанат технологии X рассказал почему она лучше чем Y, после чего пришёл фанат технологии Y с опровержением. Никогда такого не было, и вот опять.
По мне так тут классическая аксиома Эскобара.
Я работаю с React Native с 2017 года.
Вопрос по Flutter - как дела с e2e тестами? Для RN есть Detox и работает очень даже хорошо.
Из того, что я понял, с Flutter легко делать всякие крутые анимации (конечно, есть https://docs.swmansion.com/react-native-reanimated/, но все же). Поэтому подумал, чтобы попробовать посмотреть в его сторону, но очень смутила упомянутая выше ветка https://github.com/flutter/flutter/issues/103847, где у людей приложения из стора внезапно начинают тормозить. В RN с таким не сталкивался.
Насчет пункта про то, чтобы приложение выглядело по-разному на разных платформах. Как-то на практике не приходилось такого делать, и как раз проще реализовывать именно одинаковый дизайн как для ios, так и для android.
Делал крупное приложение для веба и мобильных девайсов, с тем самым React Native Web. Да, скорее всего, благодаря ему мы смогли зарелизиться гораздо быстрее. Но из-за того, насколько ужасно выглядит сгенерированный DOM, у меня теперь реакция "ни-ни, больше я такого не хочу". Большинство компонентов действительно легко переиспользовать, но вот когда нужно делать адаптивный дизайн, вместо простых media query приходится топать в JS, и это удручает.
Насчет навигации. Де-факто стандарт это https://reactnavigation.org/, и не то, чтобы было много альтернатив.
Есть "из коробки", работающие хорошо. Плюс появляются интересные сторонние решения (первое попавшееся).
Воспользуюсь аргументом автора оригинальной статьи: "Вот impeller зарелизится, тогда заживем! ?". Если по существу - да, бывают "какие-то баги", которые визуально выглядят как лаги, к сожалению у меня нет iOS устройства под рукой, чтобы как-то погрузиться в причину там происходящего и оправдать Flutter более аргументированно, поэтому просто отвечу - ну ок, есть вот такой вот лаг при такой вот анимации на iOS
Вот у меня тоже есть ощущение (по крайней мере мой опыт именно такой) что почти все делают все кастомное, и это и есть стихия Flutter - на нем не нужно прикладывать усилий, чтобы все выглядело везде одинаково (кастомно), на RN я пока не писал, но есть ощущение, что на нем придется прикладывать дополнительные усилия, чтобы все выглядело одинаково.
Про e2e это однозначно плюс. Вот даже то первое попавшееся выглядит вполне прилочно (если оно действительно запускает скомпилированное приложение, а не просто юнит-тестит, наподобие jest).
Не, на RN вообще не надо никаких усилий прикладывать для одинакового внешнего вида. Ведь, по сути, всякие View и TouchableOpacity выглядят одинаково, как и свои применяемые стили. Единственное различие из того, что приходит в голову, - Android не поддерживает box-shadow, поэтому приходится извращаться с elevation.
React Native is better than Flutter*