*...and it is not true.
Привет! Совсем недавно мой друг, и по совместительству - React Native разработчик, поделился со мной одной статьей, про React Native [RN] и Flutter [FL]. Там подробно объясняется, почему RN лучше FL, но делается это в формате "сравнения". На самом деле, конечно, эта статья - никакое не сравнение, а попытка показать RN в лучшем свете, чем он есть на самом деле, а также привнести некоторого скепсиса по поводу FL.
Чтож...я написал своему другу короткий (в сравнении с этой заметкой) ответ, но меня гложило чувство несправедливости. "Как вообще можно сравнивать эти две технологии? Это как сравнивать лошадь из 18 века и самый самый современный автомобиль - и на том и на другом можно доехать до точки назначения, но путь, который вы проделаете, будет отличаться разительно". Поэтому я и решил написать данную статью - рассказать своему другу (и всем сомневающимся) в таком формате, почему именно ему стоит слезть со своей JS-иглы и присмотреться к "вражеской" технологии.
Также, перед прочтением данной статьи я очень рекомендую вам прочитать статью, с которой все началось. Так как я буду обращаться к пунктам из оригинальной статьи, используя их как единую логическую опору.
Disclaimer
Прежде чем начать, я напишу несколько важных дисклеймеров - я не испытываю никакой неприязни к JS или React, ровно как и к React Native или людям, которые используют эти инструменты. Также, я не имею ничего против автора оригинальной статьи - у всех людей свой вкус, в том числе и в технологическом выборе. Также, я попрошу человека из Facebook или Microsoft, который будет читать эту статью, рассматривая мою кандидатуру на предмет трудоустройства в их компанию - не принимать все тут написанное близко к сердцу, и последнее - я абсолютный фанат Flutter, я создаю классные приложения на нём с 2018 года и делаю это с огромным удовольствием. Я очень люблю этот инструмент и те возможности, что он дает, поэтому я не могу быть объективным на 100%, но я постараюсь аппелировать только к фактам (но буду позволять себе иногда съязвить - проронив колкую шутку). Теперь, поехали! Статья будет в формате "Пункт из оригинальной статьи - ответ".
Уже практически дописав статью я решил добавить еще одно предупреждение - в статье будут встречаться иностранные слова, которые можно было бы написать и на русском, но написаны они на английском. Считайте это авторским стилем, а если вас это бесит - прошу сначала хорошенько поколотить боксерскую грушу, и только после этого писать гневные граммар-нацци комменты ????
Содержание
Hiring
Автор оригинальной статьи указывает, что проблема с наймом разработчиков сейчас (а когда нет?) стоит очень остро. Но, якобы, можно просто взять и заставить обычного React-разработчика (коих много) писать на React Native. Что же...если представить, что любой React-разработчик заведомо согласен менять свой стек (переходить из web-разработки в mobile) - то что помешает ему перейти и на Flutter? На этом пункте я бы сделал следующее - провел опрос среди React-разработчиков, которые готовы перейти в кроссплатформенную мобильную разработку:
Переходя в кроссплатформенную разработку, какую из предложенных технологий вы бы хотели использовать в будущей работе, если бы вам дали время на её изучение?
- React Native
- Flutter
- Xamarin
Xamarin я добавил случайно ????
В целом, моя мысль в этом пункте следующая - если вы относитесь к своим сотрудникам (настоящим или будущим) исключительно как к ресурсу, который будет делать все, что вы скажете - это одно. Если же вы планируете собирать обратную связь о ваших процессах и технологиях - это другое и технологический выбор тут тоже важен. Вдруг, внезапно, выяснится, что даже ваши закоренелые React Native разработчики с удовольствием бы перешли на синюю сторону, а мешает им ипотека и ваше нежелание давать своим разработчикам развиваться.
Sharing Code, Knowledge, and Developers
В этом пункте автор пишет, что лучше всего, когда меньше всего кода - с этим утверждением невозможно не согласиться, но дальше начинается много "но":
Чтобы переиспользование было вы должны использовать оригинальный React для Web
Ваш Backend должен быть на Node.js
При этом, на примере моего друга - в их проекте около 1000 строк кода, переиспользуемого между Node.js и React Native. Что же...ради 1000 строк кода действительно стоит отдавать предпочтение одной из технологий. Но что если backend не на Node.js? А так бывает? А если web не на React? И так тоже бывает? Столько провокационных вопросов, а ответов нет.
Один из простых ответов будет в том, что, возможно, вы напишите меньше кода на Flutter, чем на React Native, чем сэкономите эту тысячу строк кода несколько раз (во Flutter есть отличная кодогенерация). А кроме того, для Flutter вам не придется писать эту 1000 строк кода с нуля - она у вас уже написана на Node - просто перепишите её на Dart.
Также, хочу сделать очень жирную ремарку - наличие в вашем штате 10 React разработчиков, 10 React Native разработчиков и 10 Node.js разработчиков не равно тому, что у вас есть 30 разработчиков, способных сделать качественный продукт на любом из трех упомянутых инструментов. А с Node.js я вообще обращаю ваше внимание на то, что это backend. И взять и посадить frontend-разработчика (web или mobile - не важно) и просто поручить ему писать backend - безответственно. Это требует куда более глубокого знания алгоритмов и структур данных, а цена ошибки может быть существенно выше. Плюс, добавим backend-специфичные hard-skills. Так что все ваши 30 человек не являются абсолютно переиспользуемыми "юнитами", которых можно легко перетаскивать из одного проекта в другой, как в какой-нибудь стратегии.
Под конец этого пункта автор пишет, что на StackOverflow есть множество ответов на вопросы по React Native, React. и просто JavaScript. Честно говоря, я не совсем понял, что это мне должно сказать. Ну про Flutter и Dart там тоже много ответов. Крайне маловероятно, чтобы новичок во Flutter столкнулся с такой проблемой, решения которой еще нет.
Developer Experience
В этом пункте автор оригинальной статьи объективен, хоть и пытается выставить RN в лучшем свете, чем есть на самом деле, упоминая Expo. Что же, а я заострю ваше внимание на этом пункте!
Опыт использования инструмента, на мой взгляд - крайне важная и очень тонкая материя, которая может очень сильно влиять на бизнес-показатели, и перечеркнуть все ваши старания по созданию "универсальной команды JS-еров". К чему приводит негативный пользовательский опыт в разработке?
Во первых - это простой. Разработчик может тратить часы драгоценного времени на то, чтобы просто ждать, пока пересоберется ваш проект. А баги? "Черт, опять все зависло и не работает".
Второе - выгорание. Когда у вас постоянно что-то не работает или работает не так, как должно или что-то еще - это раздражает. Когда вы каждый день раздражаетесь от своей работы, рано или поздно она надоедает и это влияет на перформанс. А в конце концов это приводит к срывам сроков, нервам и смене статуса на "В активном поиске" и речь, отнюдь, не о личной жизни. А вы же помните, что найти разработчика тяжело, а хорошего - очень? Если вы не верите мне, просто почитайте отзывы к XCode.
Главный вывод в этом пункте - если разработчик тратит время не на борьбу со своим "молотком", а на его продуктивное использование - то он становится счастливее, "преданнее" и продуктивнее.
Performance
Мое любимое ????...
Если кратко пересказать слова автора, то получится примерно следующее:
Сравнивать производительность сложно. Если писать хорошо - то все будет хорошо, а плохо написать можно на любой технологии. Иии дааа...React Native сейчас вроде как медленнее, но это пока! Вот скоро, совсем немного надо подождать, и скоро в React Native завезут новый движок и все как залетает!
Что же...кажется настало время язвить :)
Первое - то мы собираемся легко свитчить React разработчиков в React Native (тут я напомню, что JavaScript != Java, а React != React Native). То нам нужны опытные разработчики, которые умеют писать "правильно", чтобы ничего не тормозило.
Второе - оригинальная статья опубликована в марте 2022 года и там говорится про "новый движок", сейчас середина октября 2022 года. У меня вопрос - прилетело уже обновление? Много сил ушло, чтобы его использовать? А тормозить и правда все перестало или не совсем и пора искать более опытных разработчиков? :)
Далее автор пишет, что в RN тоже можно использовать Skia и получить ту же производительность, что есть и у Flutter. Но погодите-ка, а как же тогда быть с главным "плюсом" RN - возможностью отрисовки платформенных компонентов? Странно, странно.
В целом, кто бы что не говорил, но едва ли наступит тот день, когда "среднее по больнице" приложение, написанное на RN вдруг станет работать быстрее, чем такое же, но написанное на Flutter. Можете скриншотить.
А может зададимся вопросом - а зачем нам вообще какая-то там "производительность"? Юзер вон уже какой год хавает лагучий скайп, у которого боковая шторка открывается с секундной задержкой, и ничего! Предлагаю спросить это у ваших пользователей. Если, конечно, они смогут дождаться, когда отрендерится опросник в вашем RN-приложении ????
Unified UI Experience
Мне очень понравился этот пункт. Автор обыгрывает идею, что любое приложение должно выглядеть только так. как выглядит платформа, и только. Чтож - вынужден согласиться. Если ваша задача - сделать унылый интерфейс из стандартных системных компонентов, то React Native - ваш выбор. На нем это будет действительно проще. Но если! вы хотите добавить плавных и "сочных" анимаций, продуктовой айдентики, кастомных форм и очертаний к тому, что пользователь видит и трогает на экране своего устройства...Flutter! И только он (тут мы говорим про кроссплатформу, нативщики, еще рано ставить минус). Сколько я слышал разных "историй" о том, как непросто делать анимации в RN или как они отъедают драгоценные кадры в секунду. Но ни разу не доводилось слышать или самому сталкиваться с подобным за все мои годы (4+) работы с Flutter.
Объективным минусом Flutter в данном пункте будет его "инаковость". Он пытается быть похожим на нативную платформу (если вы решили делать интерфейс в нативном стиле), но у него это не совсем получается. Какие-то микро-взаимодействия будут работать не так, где-то физика скролла будет не такой и так далее и тому подобное. Поэтому если вам действительно надо сделать "нативно" - то может вообще использовать Swift или Kotlin?
Native Integrations
Снова прибегну к видоизмененному цитированию автора оригинальной статьи:
Во Flutter инструментарий для взаимодействия с нативной платформой отличный. В React Native - не очень. Но вот скоро, совсем чуть-чуть, и новая архитектура RN позволит избавиться от большой части недостатков и вот тогда заживем!
Опять я ехидничаю, но даже не пишу, что начал это делать. Что поделать. Пожалуй я еще добавлю одну монетку в копилку Flutter и перестану избивать эту тряпичную куклу.
Вот хотел же перестать, но не могу не раскрыть мысль немного подробнее: в отличие от RN, Flutter работает и на Desktop и в Web, и вообще "на любом устройстве, у которого есть экран". И интегрироваться он может с любой "нативной" платформой. Есть отличные инструменты, которые позволяют уменьшить количество кода, которое надо для этого написать практически до нуля. Кроме того, уже сейчас можно использовать как "язык хоста" - C, C++, Go, Rust. Ну и стандартные Swift / Objective-C, Java / Kotlin. А RN все ждет новую архитектуру. Ну ок.
Internationalization
Честно - не знаю, как это устроено в RN, но во Flutter это сделано так просто, как только может быть. Меня очень позабавила фраза из статьи автора:
However, React Native’s third-party i18n support is getting pretty good these days.
То есть она лишь становится хорошей, не была всегда, с самого начала, а только становится. И да, если создатели сторонних решений решат перестать поддерживать свои решения (сори за тавтологию), то вы останетесь один на один с этим решением, которое было решено не поддерживать. Вы же не думали, что только Google бросает свои проекты?
Built-In Navigation (& more)
Опять же, я не силен в том, как устроена навигация в React Native. Попрошу вас, если вы пишете на RN - не затоплять комментарии своими слезами. Там могут быть другие люди и я не хочу, чтобы они утонули. Возможно я не прав, и, вопреки всему, навигация в RN очень приятная и легкая. Но как бы то ни было - именно такой она является во Flutter. Положа руку на сердце - эта статья является вопрощением моей прокрастинации, так как написана вместо другой статьи, которую я не могу закончить и в которой я пытаюсь рассказать о том, какой же выбрать навигатор для Flutter, выбирая из двух, не побоюсь этого слова - идеальных библиотек.
"Библиотек"? Что? Автор оригинальной статьи написал, что во Flutter есть встроенная навигация! Зачем библиотеки? Ответ прост - эти библиотеки являются очень приятными в эксплуатации абстракциями над новым, шикарным и чрезвычайно приятным низкоуровневым API для навигации во Flutter, также именуемым Navigator 2.0. А что с 1.0? Нууу...давайте перелистнем эту страницу.
Если не лить воду, не писать шуточек за 200, то в сухом остатке будет следующее - во Flutter есть отличная встроенная декларативная навигация, позволяющая реализовать любую прихоть, поверх которой есть невероятнейшая библиотека, с помощью которой сделать это будет еще проще, приятнее и быстрее (к этому пункту мы еще вернемся ниже). И, бонус! У вас не будет выгорания. Кажется, я сейчас спойлернул часть из своей недописанной статьи, но, думаю, когда я ее допишу - вы все забудете.
Web Support
А вот это больно! Или нет? Сейчас проверим.
But their approach to web is very much “let’s use a canvas and draw on it” rather than using the native DOM.
Автор часто упоминает ...native...native...native, как будто хочет загипнотизировать своего читателя - native это хорошо, а не native - плохо. Позвольте не согласиться. Во первых - Canvas - это тоже native. И его использование для отрисовки интерфейса и для веба - более чем приемлемо, если удовлетворяет поставленным целям. Но так же не принято! А как же SEO? Опять больно! Вот что пишут сами создатели фреймворка:
In general, Flutter is geared towards dynamic application experiences. Flutter’s web support is no exception. Flutter web prioritizes performance, fidelity, and consistency. This means application output does not align with what search engines need to properly index. For web content that is static or document-like, we recommend using HTML—just like we do on flutter.dev, dart.dev, and pub.dev. You should also consider separating your primary application experience—created in Flutter—from your landing page, marketing content, and help content—created using search-engine optimized HTML
Мне показалось или только что был слышен стук молотка по последнему гвоздю гроба, в который затолкали кричащий "зачееем ваааам SEEEOOO???" Flutter? Well. Буду честен и с самим собой - интернет-магазин на Flutter, скорее всего, я бы писать не стал. Возможно...проведя несколько недель за глубоким ресерчем, как решить "проблему", но точно не сразу. Но что если делать не интернет-магазин? Что если это будет действительно web-приложение? Полноценное приложение, но для запуска из браузера? То есть вам не нужно индексирование каждой божей страницы вашего продукта. Давайте попробуем сравнить решения.
Что предлагает React Native?
В теории есть React Native for Web (как-то так), который позволяет почти не писать или совсем не писать код для веба (поправьте, пожалуйста, меня в комментах, если эта штука позволяет вообще не писать ничего, чтобы завести все в вебе). Если же мои предположения верны, которые основаны на анализе инструментария в целом - то это будет кривоватая вещь, код для которой писать таки придется. Недаром же автор все время говорит о переиспользовании кода между React и React Native, а не пишет "вы можете все написать один раз на React Native и не париться"? - то лучшим выбором будет React. Из этого следует, что весь UI слой вам придется написать заново. А вы же помните, что React Native рисует "нативные компоненты"? А в вебе их, как бы, нет. Поэтому вам понадобится дизайнер, который сделает макеты для веба (в том числе и мобильной версии веба). А затем вам - придется просто заменить UI. Или нет? А может придется еще потратить N-е количество времени на то, чтобы сделать вашу логику полностью переиспользуемой в разных проектах? А хорошо ли вы отделили UI от логики? Если везде все ок - отлично. Едем дальше. Мобильная версия для web ????. Интересно, в каком виде она будет реализована? Как на iOS? Или как на Android? Или, может быть, кастомно? А будет ли отличаться от приложения на React Native? А если кастомно и должно быть одинаково с приложением? То получается - придется делать кастомные элементы и в React Native? Бороться с инструментом, который для этого и не создавался? Конечно же нет! Я просто подтруниваю над React Native разработчиками. Всем известно - в React Native легко и просто реализовать красивый, живой интерфейс, который будет выглядеть одинаково на обоих платформах нет;
А что предлагает Flutter?
Хмм... Вы можете. Просто. Написать. Приложение. Один раз. И оно будет работать везде - в вебе, на iOS, Android, Windows, MacOS, Linux, RaspberryPI, Car Play, и, может быть - чем нибудь еще. Не хочу, чтобы меня обвинили в кликбейте, поэтому добавлю - "гарантированно всё будет работать на всём, кроме Raspberry и Car Play".
А что с производительностью? Нуу...its depends, как говорится. Честно говоря - оно может подтормаживать на 4K экранах в Fullscreen (речь про web). Может подтормаживать даже и не на 4K. Но может и не тормозить совсем. Я использую прием автора статьи и скажу - "если все делать хорошо, то и тормозить ничего не будет". Вот вам пример песочницы с темами для Flutter, где можно настроить любой аспект внешнего вида для всего приложения, и он немного лагуч. И вот другой пример - упомянутой выше либы для навигации, где и тормозить то нечему - все летает.
Выводы тут я бы сделал следующие - я не ослепленный фанатик, и, конечно же, технологии, созданные для веба изначально (React, Vue, Angular, etc.) - лучше и производительнее, чем, конкретно, Flutter (по крайней мере - в большинстве случаев). И во Flutter могут быть потенциально непреодолимые барьеры для использования в вебе (SEO). Поэтому, использовать ли Flutter для веба - зависит от того, что за продукт вы делаете. Формула тут такая (на мой личный взгляд) - выбирая Flutter, вы сделаете лучше вашему приложению, и, возможно, хуже вашему сайту. Выбирая же React Native - вы сделаете хуже вашему приложению, и, возможно, лучше вашему сайту.
Third-Party Libraries
Смешное. Я процитирую TLDR автора и пройдусь по этому пункту дальше:
Flutter and Dart have some high-quality built-in tools, but the third-party ecosystem is a React Native advantage, as it’s almost impossible to replicate a robust ecosystem like JavaScript/React in an isolated community like Dart/Flutter.
В целом автор тут уповает на то, что у JS-community очень много решений, на все случаи жизни, которые отлично заходят и для React Native. Отлично. Особенно с этим спорить я не буду. Но, также, автор пишет, что в Dart / Flutter, якобы, может быть дефицит с качественными third-party решениями от community. Он не говорит это прямо, но подразумевает. Что же. Официально заявляю - я не знаю ни одного "пакета", который был бы реализован для RN, но не реализован для FL. Вернее сказать - ни одной функциональности. Возможно, есть что-то очень специфическое, что сделал какой-то бедолага для RN, но этого нет для FL. Но шанс, и вам понадобится тоже самое, крайне низок, да и вы уверены, что то, что есть для RN вас устроит?
Другой тезис, уже высказанный моим друже - "для RN (и JS, в целом) всего больше, чем для Dart / Flutter", мол есть из чего выбирать. А "у вас - достаточно двух видов колбасы". Эх, если бы мы действительно выбирали колбасу... Давайте так. Вот есть задача - сделать навигацию. И вы будете реализовывать ее в нескольких приложениях. Вы нашли библиотеку, которая отлично вам подходит и решает все ваши задачи. Вы что, в первом приложении ее используете, а во втором - нет? Будете "гулять по рынку и выбирать другую колбасу"? По моему мнению, эта фаза должна вычлениться в ресерч, перед тем, как делать самое первое приложение. И это касается всех кусочков функциональности, которые вы будете затаскивать к себе извне. Выбираешь лучшее в рамках ресерча, а затем используешь это до тех пор, пока в хоче очередного ресерча не наткнешься на что-то еще более подходящее (через время всегда появляется что-то еще лучше).
Исходя из этого, пункт про, якобы, какое-то преимущество RN в области решений, созданных участниками community, считаю несостоятельным и популистким (у нас больше, чем у вас).
Companies Using React Native vs. Flutter
И я снова процитирую TLDR автора:
Advantage to React Native, with some additional nuance that can’t be captured in one sentence.
А теперь это:
With that said, Flutter has done a good job of doing their development in the open, fully open-source and driven by continuous community engagement and feedback — which is different from the general feeling that React Native, where it’s driven by what Meta/Facebook needs first, and done privately before eventually it becomes available externally.
Что-то тут не сходится ????. Ладно, если честно, последняя фраза "вырвана из контекста", поэтому предлагаю вам самостоятельно с ним ознакомиться, чтобы сделать свои выводы.
А теперь к фактам:
React Native - это кожура от того, что Facebook (Meta) [Роскомнадзор, ????] делает для себя (меня уже смущает такой подход, когда мега-корпорация скидывает "объедки", называя это Open Source'ом)
Google, с технологической точки зрения, является намного более технологически развитой компанией, чем Facebook (Meta) [Роскомнадзор, снова ????] (Этот пункт не является прямым подтверждением того, что конкретный продукт гугла будет лучше конкретного продукта другой компании, но в общем и целом, когда одна компания является более продвинутой, чем другая, это склоняет к мысли, что все или почти все её решения будут также, более продвинутыми. Если вы задаетесь вопросом - а в чем именно Google более технологичен, чем Facebook? - Welcome в комменты, с удовольствием поделюсь ссылками; Ах да, я еще не писал, что являюсь фанбоем Google? Вот теперь и написал)
Google - разработал Flutter, Dart, а еще и продолжает его разрабатывать в тесном тандеме с community
Что-то здесь не сходится, вам не кажется? Факты говорят, что процесс разработки, как минимум, за Flutter. Я забыл! Пункт ведь про то, как компании используют конкретные фреймворки. Ну ок. Вот вам одна ссылочка, про один показательный пример.
А еще можете сравнить эти два списка, и сами сделать свои выводы ????
Dynamic Updates (Code Push, etc)
И снова больно! Да, во Flutter нет обновлений в обход сторов. Или есть? Но, строго говоря - это не очень то и законно. А не хотите ли вы, часом, заняться чем-то не очень честным? Например - заменять одно приложение другим спустя какое-то время... Ну ладно, сдаюсь. Да, у RN есть реальная возможность как-то криво-косо обновлять приложения в обход сторов, а у Flutter и этого нет. Но, мое личное мнение, если успешность вашего бизнеса зависит от такого очень зыбкого функционала, из-за которого ваше приложение так и вовсе могут навсегда удалить - вы что-то делаете не так. Но это, на мой взгляд - единственный безальтернативный, без всяких "но" плюс за RN.
Выводы
Автор делает нейтрально-правильный вывод - "все зависит от вас самих". Вам и только вам решать, что использовать. Но я не буду совсем инертным и напишу кое-что конкретное:
Чтобы определиться с тем, на чём будет зиждиться ваш продукт следующие несколько лет, стоит потратить хотя бы несколько недель и сделать глубокий ресерч - нанять двух первоклассных разработчиков для React Native и Flutter, изолировать их друг от друга (чтобы не подрались) и заставить сделать одно и то же - простенький прототип того, что вы и собираетесь делать
Посмотреть, кто сделает прототип первым. Оценить, насколько результат будет вас устраивать
Последнего в этой гонке можно выгнать на мороз, а технологию первого и сделать основной
или
Продолжать разрабатывать два приложения параллельно, собирая метрики о количестве багов, удовлетворенности пользователей и сотрудников, скорости разработки с учетом всех нюансов - вечный A|B тест
Через, хотя бы год, собрать все полученные данные воедино и выгнать на мороз проигравшую команду
Что? Вы - стартап, и у вас нет на это времени? Нужно еще вчера? Хмм...никогда такого не было и вот опять. Что же, со всей ответственностью заявляю - моя ставка на Flutter, сделанная весной 2018 года - выиграла. Flutter технологически превосходит RN на порядок. Он гибче, быстрее, комфортнее и просто мощнее. Это как сравнивать Таноса, когда он только что унизил Халка и Железного человека, когда он вышел из пещеры (будем считать, что Танос - хороший). И с вероятностью 99% Flutter подойдет вам намного больше и доставит намного меньше проблем, чем RN. А если вы входите в оставшиеся 1% - то вам не нужны мои жалкие советы, да и эта статья в принципе, вы и сами знаете, что вам нужно.
Я искренне желаю оказаться в мире, где Flutter займет если не главный трон, то как минимум - трон справа от Короля, и эта статья - мой небольшой вклад в это дело. И хочу я этого не потому, что выбрал Flutter. Отнюдь - я выбрал Flutter, потому что он обязательно окажется на этом месте (если, конечно, гугл его не бросит ???? ). А если вы топите за RN - спросите у себя (или своей команды):
Комментарии (34)
site_trouble
28.10.2022 21:56+1Все конечно круто в Flutter, кроме того, что оно до сих пор лагает на ios.
alphamikle Автор
28.10.2022 21:56site_trouble
28.10.2022 22:03+2И что? Вот вы пишите:
В целом, кто бы что не говорил, но едва ли наступит тот день, когда "среднее по больнице" приложение, написанное на RN вдруг станет работать быстрее, чем такое же, но написанное на Flutter. Можете скриншотить.
По факту приложение на Flutter лагает из коробки. А приложение на RN - нет.
Alexufo
28.10.2022 22:28+1Модель на которой лагает? Я работал с нативной частью и в RN и FL реализуя один функционал. Могу сказать чтобы перегнать 300kb (json + изображение)с натива в RN нужно ставить прелоадер, потому что тормоза. Во FL это абсолютно незаметно.
В целом, в RN приятно потому что знакомый JS. Потому что можно приложение обновлять без стора - это киллер фича, блин! Просто киллер фича! В остальном флаттер стабильнее и куда шустрее.
Может быть RN получит второе дыхание когда во всю реализует турбомодули, работу с нативом по новому, но это поломает кучу готовых пакетов.У вас может залагать приложение RN когда вы реализуете все что хотели, потому что может быть потолок по FPS для вашего макета. Демка конечно важная часть, но вы можете тикет завести с проблемой FL в гитхабе, записать и залить скрин видео, там в течение двух суток ответ прилететь может.
site_trouble
28.10.2022 22:30IPhone 12 Pro
NowebNolife
29.10.2022 01:03+1Недавно выпустили Impeller. Решает проблемы на раз.
https://github.com/flutter/flutter/wiki/Impeller
alphamikle Автор
29.10.2022 01:51site_trouble
29.10.2022 09:47Почему issue не закрыто, раз проблема решена?
alphamikle Автор
29.10.2022 22:27Не ко мне вопрос, но, предположу, что фикс конкретной проблемы (как я понял, проблема не в производительности как таковой, а в сочетании скорости обновления экрана и анимаций или отправке дебаг-эвента) - еще не влит в stable / не протестирован / еще что-то.
Mox
29.10.2022 04:29+1Ну ок, статья написана любителем Flutter, но честно говоря - какая-то вода.
Что не так со сборкой? C Expo? Он хоть понимает сколько времени экономится, когда обновления pull-requests раскатываются по воздуху за несколько десятков секунд, а не сборка бинарей на каждый чих?
Добавление возможности SKIA сделало инструмент менее гибким или более гибким? Нативные контролы никуда не делись, появилось больше возможностей.
Нативная навигация во Flutter не работает, и это видно.
Особенно странно читать про компактность Dart vs JS/TypeScript. Непонятно
Шаринг компентенций и кода работает, хотя конечно не так что любой человек делает что угодно.
React/TypeScript разработчики отлично вкатываются в RN, при условии что в мобильной команде есть мобильный лид, который ообъяснит про платформу и разницу между роутерами и навигаторами.
Alexufo
29.10.2022 05:11Что за сборка бинарей? Флаттер аналогично реакту налету отрисовывает ваш макет. Так же есть возможность его отладки, тыкая мышкой Аля девтулс.
Нативная навигация во флаттер не работает? Что имеется ввиду? Можно внедрять флаттер в приложение постепенно, оставляя сложные экраны на нативе, переписывая другие на дарт.
Mox
29.10.2022 17:24По поводу бинарей
Я имею ввиду не 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 навигация.
Alexufo
29.10.2022 20:19+1И js компилируется, просто очень быстро. Дарт вроде бы тоже не так долго. То что обновление приложения по воздуху не из стора, это да, это офигенно. Я рендерил идентичный список listview и в rn и fl с нативной платформы из json. Визуально разница была ооочень заметной. В fl это просто пуля, ui точно был шустрее. Потом я отказался от json и выводил с натива структурами, которые реакт сам умеет понимать типа примитивов map. В RN начала срабатывать оптимизация, отрисовка стала ленивой. Стало шустрее, но по мере первого скролла данные визуально начали подгружаться. Первый слайд вниз медленный. Может конкретно у вас что то было на ios, но у fl общение с нативом крайне шустрое.
alphamikle Автор
29.10.2022 22:35Как я и упомянул, единственный (по моему мнению) объективный плюс RN - CodePush. Этот плюс у него есть и относительно нативных способов разработки, но значит ли это, что из-за этого плюса нативная разработка более не применима? Если нет - то это не значит того же и относительно Flutter. Потом, процесс тестирования (именно во время разработки) в случае с Flutter не является сколь бы то ни было сложным или долгим (с любых точек зрения) - если есть CI, то на любой чих можно сделать билды сборок, автоматически доставляемые в интересующий вас канал (например - Firebase Distribution), которые доступны для тестировщиков в течение нескольких минут. Поэтому разница в этом аспекте по сравнению с RN будет заключаться только в том, что тестировщику RN-приложения достаточно будет лишь открыть уже установленное приложение для тестов, а тестировщику Flutter-приложения - установить новую версию поверх старой (~ 1 минута - максимум).
Относительно публикации обновлений приложения "без сторов" - круто, все так, но зыбко. И я, с точки зрения бизнеса, не стал бы делать ставку на какую угодно технологию, полагаясь на серую зону и то, что она никогда не станет черной.
slonopotamus
29.10.2022 20:33я абсолютный фанат Flutter
Фанат технологии X рассказал почему она лучше чем Y, после чего пришёл фанат технологии Y с опровержением. Никогда такого не было, и вот опять.
По мне так тут классическая аксиома Эскобара.
amberv
29.10.2022 22:37+1Я работаю с 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/, и не то, чтобы было много альтернатив.
alphamikle Автор
29.10.2022 22:52+1Есть "из коробки", работающие хорошо. Плюс появляются интересные сторонние решения (первое попавшееся).
Воспользуюсь аргументом автора оригинальной статьи: "Вот impeller зарелизится, тогда заживем! ????". Если по существу - да, бывают "какие-то баги", которые визуально выглядят как лаги, к сожалению у меня нет iOS устройства под рукой, чтобы как-то погрузиться в причину там происходящего и оправдать Flutter более аргументированно, поэтому просто отвечу - ну ок, есть вот такой вот лаг при такой вот анимации на iOS
Вот у меня тоже есть ощущение (по крайней мере мой опыт именно такой) что почти все делают все кастомное, и это и есть стихия Flutter - на нем не нужно прикладывать усилий, чтобы все выглядело везде одинаково (кастомно), на RN я пока не писал, но есть ощущение, что на нем придется прикладывать дополнительные усилия, чтобы все выглядело одинаково.
amberv
29.10.2022 23:08+1Про e2e это однозначно плюс. Вот даже то первое попавшееся выглядит вполне прилочно (если оно действительно запускает скомпилированное приложение, а не просто юнит-тестит, наподобие jest).
Не, на RN вообще не надо никаких усилий прикладывать для одинакового внешнего вида. Ведь, по сути, всякие View и TouchableOpacity выглядят одинаково, как и свои применяемые стили. Единственное различие из того, что приходит в голову, - Android не поддерживает box-shadow, поэтому приходится извращаться с elevation.
LabEG
На самом деле крайне не корректно сравнивать Xamarin с RN и FL. Xamarin это платформа нативной разработки. С многопоточностью и прямым доступом к API операционной системы. У RN и FL надо писать нативные прослойки для прямого доступа к API операционок, а многопоточность в принципе отсутствует из-за скриптовой природы движков. Dart и V8 близкие родственники.
А если уж и добавлять в сравнение то MAUI. Это перезапуск фреймворка Xamarin Forms. Который позволит писать единый интерфейс + плюшки Xamarin.
Сам выбираю React Native для мелочевок, т.к. активно переиспользую код с вебом и Xamarin для чего то серьезного. Во flutter я ни код переиспользовать не могу, ни нативных плюшек нет.
alphamikle Автор
Добавленный сюда Xamarin - это стёб. Опять же, ничего не имею против, и это может быть тем, что когда-то выстрелит, но сейчас это совершенно не конкурент ни для Flutter, ни для React Native.
А вот с "невозможностью" переиспользования кода во Flutter - интересно. Какие у вас кейсы, что для веба Flutter не пригоден? И какие именно нативные плюшки вам нужны?
Alexufo
Для веба флаттер не очень пригоден пока(по мне), точнее если хотите быть бетатестером, не важна оптимизация по ресусрам (хз что там генераторы натворят) то велкам.
slavap
Какие генераторы? На выходе чистый js практически. Единственная проблема размер этого js - тут меньше 1.5-2 мегабайт никак.
qrKot
Дык, этот чистый JS же откуда-то берется. Генерится, видимо?
george3
писал на flutter в основном для web ~ 2 года, когда он еще был то ли в бете, толи еще в чем. медленно работал в 3-4 х(чем если б на js), либы flutter в основном не подходили для web, js либы тоже не подключишь, качество кода middle-web было таким, что переделал половину элементов. криво-косо работали, вменяемый саппорт отсутствовал. плюнул и ушел на vue, когда новый dart сломал совместимость с написанными и используемыми либами. vue и web тоже не мед, но то было пыткой.
slavap
"новый" Dart с null safety - это было болезненно, но реально полезно - сейчас уже практически всё на pub.dev устаканилось и поддерживает null safety.
alexshipin
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: я отношусь одинаково ко всем решениям: знаком с каждым из них не понаслышке, и я сделал свой выбор в пользу одного из них, но говорить о нём не буду :)
LabEG
Вы видимо путаете Xamarin и Xamarin Forms.
Xamarin это набор компиляторов. Сейчас занимает долю 50% всех мобильных 3D игр. Ведь Unity3D работают именно на нем. Ближайшие конкуренты юнити тоже. В обычных приложениях он тоже отлично себя проявил в таких компаниях как боинг, аеробус и банках.
Xamarin Forms это кроссплатформенный фреймворк для интерфейса. Вот с ним действительно было все плохо. Но Майкрософт его выкупила вместе с Xamarin, переписала, переименовала в MAUI и вот вот он выйдет в свет.
Таким образом Xamarin не конкурирует с RN и FL, он конкурирует с нативными языками Kotlin/Swift. А с RN и FL будет конкурировать MAUI (бывший Xamarin Forms).
Alexufo
А чего вам не хватает то из API прослоек, всеж давно прослоилось то за вас, разве нет? Многопоточность вам для чего в UI слое? Соскучились по решению головоломок?)) Есть фоновые процессы, там выполняйте тяжелые вещи.
LabEG
Например стриминг с камеры на свой сервер с нужными параметрами. Реализуется только нативно через камера апи 2.
Никакие фоновые процессы не заменят простоту, гибкость и удоство шарпового многопоточного async/await.
Alexufo
Async await есть и в дарте и в js. Как там система рулит процессы, потоки или евент луп, ее дело.