*...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 - спросите у себя (или своей команды):
