company_banner

Сравнение React Native и Flutter с точки зрения их применения в реальных проектах

Автор оригинала: Andréas Hanss
  • Перевод
Чем React Native отличается от Flutter, за исключением того, что речь идёт о разных фреймворках, в основу которых положены разные технологии? На что ориентироваться тому, кто не знаком с этими инструментами для разработки кросс-платформенных приложений, но хочет выбрать один из них для своего очередного проекта?



Автор статьи, перевод которой мы публикуем, говорит, что в последнее время ему попадалось множество сравнений React Native и Flutter. Во всех этих сравнениях речь шла о таких вещах, которые, на самом деле, особого значения не имеют. Например — о языках, используемых для разработки проектов, или об инструментах командной строки. Здесь будет сделано сравнение React Native и Flutter с точки зрения реального положения дел, с точки зрения того, что имеет значение для настоящих проектов. Это сравнение призвано снабдить всех желающих сведениями, которые помогут им выбрать именно то, что им нужно.

Предварительные замечания


Мне сразу хотелось бы сказать о том, что здесь я не собираюсь заниматься критикой React Native или Flutter, не собираюсь их, так сказать, троллить. То, как именно вы распорядитесь тем, что узнали, зависит от вас — от того, что вы уже знаете и умеете, от нужд вашего проекта.

Я начал использовать React Native (RN) три года назад. До этого я занимался разработкой проектов с использованием React.js и Node.js. В итоге вполне закономерно то, что я выбрал именно RN. Но мне, кроме того, очень нравится Flutter. Я наблюдал за ростом и развитием этого фреймворка, и я вполне уверен в том, что его ждёт светлое будущее. И RN и Flutter — это отличные инструменты, которые достойны того, чтобы на них обратил внимание тот, кто ищет базу для своего очередного приложения.

Хочу отметить, что с RN я работаю ежедневно, а вот о Flutter я того же самого сказать не могу. Поэтому относитесь к моим выкладкам критически. А если обнаружите, что я в чём-то ошибаюсь — дайте мне знать об этом.

Языки


Есть много сравнений, посвящённых, например, языкам Dart и JavaScript, нативным компонентам, и компонентам, код которых генерируется автоматически. Я не буду тут приводить подобные сравнения — об этом написано уже много всего. Если вам это нужно — вы можете найти соответствующие материалы самостоятельно.

Мне хотелось бы сказать лишь о том, что в языке Dart, применяемом при разработке Flutter-приложений, используется статическая типизация. Он создавался компанией Google в качестве замены JavaScript (но Google не смогла склонить других производителей браузеров к тому, чтобы они включили бы в свои проекты поддержку виртуальной машины Dart; в итоге её поддерживает лишь Chrome). В JavaScript, на котором пишут код React Native-проектах, используется динамическая типизация, но тот, кого интересует статическая типизация, может создавать JS-приложения с использованием TypeScript.

Тут можно поговорить и об IDE, и об инструментах командной строки для автоматического генерирования кода, и много ещё о чём.

Но, на самом деле, всё это особого значения не имеет. Разработчиков больше всего беспокоит свобода действий и гибкость, которую им даёт некий фреймворк в деле достижения их целей, а не то, что, на первый взгляд, может показаться интересным. Привыкнуть можно ко всему чему угодно.

Поэтому сейчас я предлагаю обсудить некоторые популярные аргументы, высказываемые в пользу того или иного фреймворка. Их можно встретить буквально повсюду. Мне доводилось читать о них, слышать их от коллег. Они далеко не всегда так однозначны, какими могут выглядеть.

Ложные аргументы, используемые при сравнении Flutter и React Native


▍Dart — типизированный язык, а JavaScript — нет. Это значит, что писать на Dart безопаснее


Типобезопасность — это важнейший аргумент в пользу того или иного языка, используемого для разработки любого приложения. В особенности — мобильного проекта, которому, прежде чем попасть на устройства пользователей, нужно пройти непростой процесс проверки в некоем магазине приложений.

Но JavaScript-код можно типизировать с использованием TypeScript или Flow. Это не даёт преимуществ в плане производительности, таких, какие есть у Dart, но в будущем ситуация может измениться. В особенности — если учитывать то, что в 2020 году ожидается выход нового движка React Native.

Правда, стоит помнить о том, что выбор динамически типизированного языка в некоторых случаях — это тоже очень даже хорошо. Иногда это помогает менять тип переменной без необходимости повторной сборки проекта. Я однажды встретился с чем-то подобным при работе над приложением, посвящённом теннису. Очки возвращались в виде целых чисел 0, 15, 30, 40 из соответствующего перечисления. Затем к этим числам понадобилось добавлять строку AD, сообщающую о преимуществе. Изначально мы эту строку к числам не добавляли. Однако мы смогли реализовать эту возможность, не выпуская новую сборку приложения. Нам в этом помогла динамическая типизация JavaScript. Мы смогли просто поменять схему GraphQL и возвращать значение в таком виде, в каком нам это было нужно. В Dart-приложении подобное привело бы к «падению» приложения или к возникновению ошибки.

▍Flutter и Dart — это разработки Google. Скоро выйдет Fuchsia — новая ОС от Google. RN, в результате, ждёт медленная смерть, так как Flutter будет гораздо лучше оптимизирован в расчёте на Fuchsia


Никто не может предсказать будущее, но кое-что можно утверждать с уверенностью: некоторые из крупнейших мировых компаний делают сейчас ставку на React Native.

Например — React Native серьёзно используется в Microsoft. Речь идёт, скажем, о CodePush и о проекте React Native for Windows, позволяющем разрабатывать нативные Windows-приложения с использованием React.

React Native пользуются и в компании Discord, которая занимается разработкой популярного мессенджера. Компания, в частности, публикует много материалов о React Native. В Discord, в RN-приложении, удалось добиться уровня производительности, близкого к уровню производительности нативных приложений.

RN, кроме того, используется в банковской сфере.

Flutter, безусловно, отлично подходит для многих проектов, сфера его использования продолжает расширяться. Однако я думаю, что бороться за первенство в ОС Fuchsia будут оба фреймворка.

Истинные аргументы, используемые при сравнении Flutter и React Native


▍Flutter отличается лучшей производительностью, чем React Native


Тут мне нечего сказать. Сейчас, благодаря тому, что Flutter-программы компилируются в нативный код, с этим утверждением можно лишь согласиться. Но и производительность RN-проектов, если их оптимизировать, оказывается на весьма приятном уровне, при этом каких-либо проблем с ними не наблюдается.

▍Flutter легче освоить тем, кто раньше занимался разработкой нативных приложений


Это, из-за типизации и логики реализации, тоже правда. Flutter ближе к внутренним механизмам Android и iOS, чем RN. Большая часть логики взята из Java, а основное отличие, например, в разработке под Android, заключается в большем уклоне в сторону декларативного подхода к разработке.

На Java, например, писали классы и вызывали функции, а применяя Flutter — пишут виджеты, используя нечто вроде свойств, которые описывают ожидаемые состояние и внешний вид приложения.

▍Инструменты разработчика Flutter очень хороши, а инструменты React Native отличаются низким качеством


Честно говоря, в этой сфере между Flutter и React Native сейчас имеется большая пропасть. Команда Flutter серьёзно поработала над интеграцией своих средств разработки с VS Code и с Android Studio. Создано множество инструментов для отладки и анализа проектов.

С другой стороны, если не учитывать пакет react-devtools и некоторые небольшие плагины, отладка RN-приложения полагается, в основном, на встроенные возможности соответствующих платформ. Компания Facebook, в стремлении изменить ситуацию, недавно выпустила отладчик для мобильных приложений Flipper. Но сейчас это — пока экспериментальный проект.

Несложно заметить, что в активе и того и другого фреймворков есть сильные аргументы. Теперь давайте рассмотрим основные различия Flutter и React Native.

Основные различия


▍Компиляция и «обновление по воздуху»


Благодаря тому, что компиляция JavaScript-кода выполняется тогда, когда его нужно выполнить (JIT-компиляция), а не заранее (AOT-компиляция), при использовании React Native можно, так сказать, «обновлять приложения по воздуху». Это, на самом деле, предельно просто реализовать. Например — с использованием Microsoft CodePush или Expo.io.

Сейчас это — основная причина того, что я не осуществляю постепенный переход на Flutter (помимо того, что мне нравится парадигма React). Это — тот фактор, который кардинальным образом меняет расклад сил, особенно тогда, когда речь идёт о неких приложениях, привязанных к каким-то кратковременным событиям. В таких условиях изменения в приложение нужно вносить очень и очень быстро. Эти приложения за короткий отрезок времени набирают очень много пользователей.

Создать React Native-приложение можно, вообще не имея среды разработки и не думая о компиляции. Например — с помощью проекта snack.expo.io. Это очень удобно для создания простых проектов, демонстрирующих доказательство работоспособности некой концепции, или проектов, которые планируется показать команде разработчиков React Native, сообщая о какой-нибудь ошибке.

Dart тоже поддерживает JIT-компиляцию, но сейчас невозможно отправлять обновления Dart-приложений «по воздуху», используя нечто вроде CodePush. Можно, конечно, инициировать вызов интента установки, но это — далеко не то же самое, чего можно достичь средствами RN.

Возможно, в будущем команда разработчиков Flutter представит нам достойный ответ на вопрос об обновлениях приложений «по воздуху», но пока не существует чего-то вроде официально поддерживаемой библиотеки, это реализующей.

▍Инструменты разработки


Flutter-разработчики могут пользоваться отличными инструментами для отладки приложений. Это — сильный аргумент в пользу удобства разработки на Flutter. Это, к тому же, сильно облегчает оптимизацию приложений.

▍Описание пользовательских интерфейсов


В React Native для описания интерфейсов используется JSX, что значительно облегчает работу. А во Flutter используются интерфейсы, основанные на виджетах. Мне такой подход кажется слишком перегруженным деталями и не особенно дружественным к разработчикам.

Разработка Flutter-интерфейсов подразумевает наличие больших объёмов шаблонного кода. Без использования IDE описание интерфейсов превращается в настоящий ад вложенных друг в друга конструкций, в котором тяжело ориентироваться. Это может усложнить ревью пулл-запросов.

Кроме того, здесь, насколько я знаю, нет нормальных средств для отделения чистого дизайна от самих виджетов. Речь идёт о чём-то наподобие библиотеки styled-components в RN, или о чём-то вроде вызова StyleSheet.create с передачей компоненту того, что получилось, через свойство style.

Использование JSX способствует созданию простых и читабельных описаний интерфейсов. Ситуацию ещё сильнее улучшают специализированные библиотеки, вроде styled-components. Всё это даёт RN хорошее преимущество перед Flutter. Разработчик, который раньше занимался веб-проектами и перешёл на React Native, способен очень быстро войти в курс дела.

Оба фреймворка хорошо поддерживают возможности по «горячей» перезагрузке материалов. Этими возможностями приятно пользоваться. Это относится и к iOS, и к Android.

Сообщество и библиотеки


Экосистема JavaScript огромна, в ней имеется огромное количество разнообразных инструментов и библиотек. Но и сообщество Dart-разработчиков выглядит неплохо, хотя оно гораздо моложе и меньше JS-сообщества.

При разработке Dart-приложений можно пользоваться множеством пакетов. Однако большинство IT-стартапов в настоящее время не предоставляет тем, кто хочет с ними работать, SDK, рассчитанные на Dart. А вот средства разработки для Node.js весьма популярны в этой среде.

Dart поддерживает то, что это — проект Google, и то, что компания, вероятно, позаботится о создании множества полезных библиотек для этого языка.

Собственно говоря, в плане поддержки сообщества и наличия библиотек, React Native сейчас обходит Flutter.

Итоги


Давайте подведём итоги и соберём всё, о чём мы говорили. Это поможет сделать правильный выбор тем, кто занимается выбором фреймворка для своего очередного мобильного проекта. Сразу хочется отметить, что на вопрос о том, какой фреймворк стоит выбрать, нет однозначно правильного или неправильного ответа. Всё зависит от особенностей проекта, а также от предпочтений и знаний команды разработчиков.

▍Flutter и Dart


Flutter и Dart — это отличный выбор для тех, кто делает ставку на будущее.

Полагаю, что тот, кто выберет этот технологический стек, ничем не рискует. Единственный риск заключается в том, что, из-за того, что Flutter и Dart — технологии сравнительно молодые, тому, кто их выберет, придётся либо очень постараться в поисках необходимых ему библиотек, либо писать их самому. В JS-среде можно найти готовое, или почти готовое решение для множества задач. В Dart-среде это не так.

Но Dart — хороший язык, который решает множество проблем, характерных для JavaScript.

В текущих условиях я порекомендовал бы выбирать Flutter тому, для кого справедливы хотя бы некоторые из следующих утверждений:

  • Вы идёте в мобильную разработку, не имея знаний в области JavaScript или React. В результате вы не сможете, выбрав не Flutter, а RN, строить новые знания на фундаменте старых.
  • Вы занимались раньше чем-то, что не связано с веб-разработкой, вы не знакомы с созданием макетов страниц средствами CSS и с чем-то наподобие styled-components.
  • У вас нет жёстких сроков сдачи проекта; проект, в плане возможностей, отличается определённым уровнем гибкости. Здесь дело в том, что, при создании Flutter-проекта, у программиста не будет доступа к такому же большому объёму наработок, доступ к которому есть у RN-разработчика. Во Flutter разработка специфических интерфейсов может оказаться сложнее, чем в RN.
  • В приложении используется простая схема навигации. Тут дело в том, что система маршрутизации Flutter сложнее, чем знаменитая система react-navigation.
  • Одно из важнейших требований к вашему приложению — высокая производительность.
  • Вы готовы к тому, что не сможете обновлять своё приложение «по воздуху», готовы полагаться на механизмы обновления, предлагаемые магазинами приложений для платформ iOS и Android. По крайней мере — вы готовы к тому, что такое положение дел будет существовать в ближайшие месяцы, или, возможно, в ближайший год.

▍React Native и TypeScript (или JavaScript)


React Native — это проект, который пользуется поддержкой Facebook и многих других компаний. Это — наиболее продвинутый фреймворк в своём классе.

Несмотря на то, что JavaScript не очень хорош в плане типизации, исправить это можно (и нужно), воспользовавшись, например, TypeScript.

Я порекомендовал бы выбрать React Native тому, для кого справедливо большинство следующих утверждений:

  • Вы уже являетесь React, Vue или Angular-разработчиком и знакомы с архитектурой приложений, основанных на компонентах.
  • Вы идёте в мобильную разработку из веб-разработки, вы знакомы с макетами, создаваемыми средствами CSS, у вас есть опыт работы с библиотеками наподобие styled-components.
  • Вы хотите полагаться на обширную экосистему вспомогательных средств, которыми можно пользоваться в собственных приложениях; вы собираетесь искать ответы на ваши вопросы на ресурсах наподобие StackOverflow.
  • Вы хотите воспользоваться возможностями обновлений программ «по воздуху» с помощью Microsoft CodePush и Expo.io, что позволит вам очень быстро исправлять ошибки в приложениях.
  • Вы хотите пользоваться популярными сервисами, которые, как правило, всегда предоставляют стандартную поддержку для Node.js.

Уважаемые читатели! Если бы сейчас вам нужно было бы выбирать фреймворк для мобильной разработки — на чём бы вы остановились? На Flutter, на React Native, или на нативных инструментах мобильных платформ?


RUVDS.com
1 524,86
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией

Комментарии 23

    0
    А что так не упомянули JS-bridge в реакте и его влиянии на анимацию?
      +1
      Для анимации уже давно создан отдельный модуль, которому через JS-bridge передаются только декларативные параметры анимации, а дальше он использует нативные средства мобильной ОС.
        0
        useNativeDriver? Он сильно ограничен в своих возможностях
      +3
      Всё это конечно хорошо, но во всех этих проектах (NativeScript, ReactNative & etc) узким местом остается мост Javascript, который вносит часто больше проблем чем удобства. Поэтому единственный плюс данных технологий — это возможность переиспользования кода с JS.
      Всё остальное становится печалью как только делается шаг в сторону нативки: надо какой то специфический компонент, надо поработать с устройством, надо как то раскрасить не так, надо просто побыстрее отображать что-то, надо как то обрабатывать Touch. Писал приложение на Cordova, NativeScript и Flutter. Так вот лучше уж на Cordova чем на этом фарше из нативки, измазанной в обертках JS, а если хочется скорости, то Flutter, там это хотя бы продуманнее, ну и нативные языки тоже никто не отменял.
        +2
        Регулярно раз в месяц делаю попытку начать писать на Flutter, и каждый раз облом. Собственно, язык Dart весьма хорош, отдельно на нем писать приятно, автовывод типов и т.д. Но флаттер… Ад вложенных колбэков, необходимость выучить все стилевые виджеты и миксины со всеми параметрами, плохая читаемость кода — приводят к тому, что опускаются руки, и я возвращаюсь к WEB. Понимаю, что модно, быстро, перспективно, вакансии есть, но… эстетически не могу принять этого продукта, какое-то внутреннее сопротивление. В свое время то же было с Go, при всем моем уважении к самой компании.
          +2
          Для того чтобы писать на Flutter надо выработать для себя стиль написания кода таким образом чтобы оно и писалось и читалось легко. Хороших уроков на эту тему я не видел, пришлось доходить своим умом.
          Для интерфейсов минимизируем вложенность через создание виджетов, которые будут принимать отличающиеся части в виде аргументов, а сам виджет это небольшая функция в 10-20 строк, если больше — думаем какие части внутри него можно вынести в отдельный виджет.
          Для реализации логики смотрим на то какой сложности нужно конечное приложение, если это одностраничная открытка, пишем как получится, не стреляем из пушки по воробьям, а если серьёзное приложение, то изучаем Redux, что само по себе будет гораздо сложнее чем изучить Flutter и Dart вместе взятые.

          В одном сообщении всего не напишешь, а суть в том, что если вы привыкли к Web, то Flutter не для вас.
            0
            Насколько я знаю гугл, если продукт взлетает, то они учитывают пожелания трудящихся, и его развивают (исключения в Go и т.д.). У Web есть громаднейший плюс это CSS, на котором можно и гриды рисовать, и модальные окошки, и фиксированные/плавающие колонтитулы, и все это не трогая верстку и код. Не знаю, есть ли в планах флаттера делать нечто подобное, в противном случае выход на большие мониторы будет затруднителен.
            PS
            Кстати занятно получилось, я читал историю, из которой следует, что производительность Flutter получилась такой замечательной именно из-за отказа от идеи CSS, где каждый селектор может быть применен к каждому элементу. Получается, что стилевые виджеты это не слабость продукта, а его сила, дающая скорость. Но верстка стала нудной, это факт.
              –1

              Нормальная классическая верстка, а не этот фарш css.

              +1
              Согласен, отсутствие паттернов это страшная вещь с одной стороны, но с другой, огромное удовольствие получаешь от выступления собственных архитектуры и паттернов. Флаттер — точно не вещь для быстрого освоения, но инструмент очень мощный, хоть и сырой в некоторых местах, связанных с взаимодействием с системными компонентами, к примеру. Вот что лично меня несколько расстроило:
              • нижняя панель, которая в каждом flutter приложении вместо того, чтобы «лететь», просто фейдится, так еще и не сразу в нужный цвет (вот, что я имею в виду). И черт его знает, как это пофиксить.
              • не очевидное с первого взгляда и мало документированное взаимодействие с темой панели уведомлений и системной нижней панели навигации + нету встроенного транзишена от одной темы к другой

                скудные инструменты по созданию раутов, пришлось изобретать что-то такое, и применять это вот так. Выглядит криво и не особо расширяемо, но это то, что я смог придумать для хоть какого-то адекватного контроля над анимациями раутов.
                баги виртуальной машины, несколько часов дебажил это, не понимая, почему код в функции не выполняется, при этом само приложения работает без крашей и ошибок. Это, я так понимаю, происходит из-за того, что этот код находится callbackmethodChannel'а. В любом другом месте подобная попытка каста выдает ошибку

                малая кастомизируемость доброй части виджетов библиотеки. Это не такая уж и большая проблема, ведь всегда можно просто скопировать и добавить, что нужно, но все-таки не понятно, чем это вызвано. У них на гитхабе постоянно создаются исшу с просьбами расширить функциональность тех или иных виджетов.


                –1

                Можете подкинуть им идею сделать кастомизацию как в $mol, где любой компонент по умолчанию максимально кастомизируем и его разработчику не приходится писать для этого в 10 раз больше кода.

            +2

            В RN постоянно что-то отваливается после обновления xcode, попытки развернуть сторонний проект… Как с этим у flutter?

              0
              Безусловно RN более привлекателен для меня, ведь зная React мне гораздо проще писать на React native. А с точки зрения карьеры или работы по flutter — dart пока немного возможностей.
                  +1
                  Веселят рассуждения разных блогеров и СМИ о фуксии, которая ещё даже не вышла из экспериментальной. Как будто её выход перевернёт весь мир с ног на голову и надо срочно ставить её на все смартфоны по причине «плохой android». Будет ли на ней популярен flutter или react: так как flutter продвигается гуглом — ответ очевиден.
                    0
                    Может просто хромиум сделают оболочкой, гугл его тоже продвигает, гугл вообще все продвигает, примет ли сообщество и рынок — непонятно. Полимер вот не взлетел, и не жалко.
                    0

                    RN, Flutter… Будущее за PWA и уже активно делают приложения в этой концепции. При том делают фронтендеры и не надо изучать ни RN ни flutter.

                      0
                      Может и к полноценному системному API у них есть доступ?) Я не говорю про тот куцый API который им доступен, а именно настоящий, полноценный API. Не спорю, что для REST-like приложений во времена, когда программист и время ценнее выходящего продукта — PWA подходящий кандидат. Но для чего-то более серьёзного даже Cordova куда лучше, не говоря уже про kivy, xamarin, flutter, RN и прочее. Да, производительность у них может быть не всегда у чисто нативных, но как кросс-платформенный вариант сгодится.
                        0

                        PWA легко и в кордову завернуть, когда потребуется что-то специфическое.

                          0

                          Да это и к обычному SPA применимо. PWA от него только сервис-воркером с кешированием и манифестом отличается.

                      0

                      У меня вопрос по поводу изменений по воздуху, разве нельзя взять флатер и у него webview и то что необходимо быстро обновлять выносить в вебвью, а остальное держать во флатере?

                        0
                        Cовсем не тот уровень — в RN я могу по сути любые баги исправлять и бизнес-логику патчить в обход публикации в сторах. Единственное условие — «не должно быть существенного изменения функционала приложения», но это ограничение не технологическое, а самих сторов, чтоб не забанили.
                          0
                          Более того, есть плагины, которые по json рисуют формы и виджеты. Conditional рендеринг во всей красе
                          0
                          Мне хотелось бы сказать лишь о том, что в языке Dart, применяемом при разработке Flutter-приложений, используется статическая типизация. Он создавался компанией Google в качестве замены JavaScript (но Google не смогла склонить других производителей браузеров к тому, чтобы они включили бы в свои проекты поддержку виртуальной машины Dart; в итоге её поддерживает лишь Chrome)


                          Не-а.
                          Только для разработки там Dart. Только для этих целей.
                          После того, как вы завершили отладку, Dart преобразуется в обычный JS.

                          И в разговоре ReactNative vs Flutter — при чем тут браузеры.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое