×

Плюсы и минусы платформ React Native и Real Native: сравниваем приложения

Статья создана в соавторстве с Шармин Хаят, Data Specialist, и с помощью Андрея Горобца, Front-end Developer.

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

Очевидно, что React Native имеет свои плюсы и минусы. Несмотря на то, что профессиональные веб-разработчики по-прежнему предпочитают работать с нативными инструментами, существует огромное количество начинающих разработчиков, которые рассматривают React Native как основу для своих проектов. Хотя не стоит рассматривать React Native как промежуточную ступень в развитии.

Этот пост предназначен для освещения как теоретических, так и практических аспектов использования React Native в сравнении со Swift. Для теста, мы взяли два почти идентичных приложения в обеих структурах: React Native App, Swift App.

Мы постарались максимально упростить эти приложения, чтобы было легче сравнивать между важными аспектами обеих платформ. Ниже вы найдете подробный анализ приложений, разработанных на Swift и React Native, разницу в нагрузке процессора, графического процессора и памяти. Давайте исследовать!

Приложение включает в себя вход в систему Facebook, получение его профиля, а также Tab Bar контроллер. Мы написали подобное приложение на Swift и React Native и будем использовать реальное устройство для оценки производительности. Путем точного анализа мы сможем понять, какая платформа покажет себя лучше.

Swift vs React Native

Swift

В отличие от других языков, Swift достаточно приятен в работе, особенно если сравнить его с предшественником Objective C. XCode, безусловно, является отличной IDE, и значительно упрощает разработку в сочетании со Swift.

React Native

По правде говоря, изучить JavaScript намного проще, чем Swift. В отличие от iOS, где вам приходится настраивать все самостоятельно, React Native позаботился об удобстве своих пользователей. Мы запустили приложение почти на всех версиях iPhone и знаете что? Никаких проблем с разметкой и расположением элементов — все четко :)

Полезно будет узнать о производительности React Native изолированно. Обратите внимание на официальную статью от Facebook.

Пришло время сопоставить наши приложения, чтобы выяснить, кто же все-таки круче :) Как уже упоминалось ранее, для тестирования приложений мы будем использовать реальное устройство и профайлер в xCode. Три категории, на которых мы сосредоточимся: нагрузка на процессор, графический процессор и объем потребляемой памяти.

Когда мы перемещали позицию на карте и выполняли ее масштабирование, приложение на React Native лагало больше, чем соперник на Swift. По данным Energy Usage Log, приложение на Swift расходовало меньше энергии в течение всего теста по-сравнению с React Native. В общем, в моем приложении есть всего 4 вкладки — страница логина Facebook, просмотр страницы, Page view и Карта.

CPU

CPU Profiler на экране карты

CPU Profiler на to-do list

Давайте рассмотрим каждую категорию отдельно.

1. Профиль пользователя Facebook

С точки зрения использования ЦП, React Native оказался более эффективен (на 1,21%), чем Swift.

2. To-do list

Во второй вкладке React Native снова стал победителем с эффективностью 0,66%. Выполняя задачу, пики потребления ЦП были записаны в то время, когда мы включили/удалили элемент из списка.

3. Просмотр страницы

На этот раз Swift определенно стал победителем (на 5,55% эффективнее, чем React Native). Выполняя эту задачу, мы отмечали падение производительности и пик потребления ЦП во время перехода на другую страницу в режиме просмотра.

4. Карты

Swift снова побеждает в этой категории, более рационально загружая CPU (на 9,7%). Следует отметить, что при выполнении этой задачи скачок в потреблении процессора появляется именно во время перехода на вкладку «Карты».

Своего рода ничья.

GPU

Следующий анализ, который мы проведем, это измерения GPU. Вертикальная ось достигает 60 кадров в секунду. Для оценки результатов мы будем использовать инструмент «Core Animation».

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

1. Профиль пользователя Facebook

С разницей в 1,08 фрейм/сек, Swift едва ощутимо лидирует. Результаты были зафиксированы при нажатии на вкладку «Войти в Facebook».

2. To-do List

Здесь React Native практически подтверждает свое превосходство, работая на 6 фреймов/сек выше, чем Swift. Замеры были произведены точно в момент добавления/удаления элементов из списка.

3. Просмотр страницы

Swift превосходит React Native на 1,37 фрейм/сек на вкладке просмотра страницы. Наблюдая за цифрами, мы обнаружили, что фрейм/сек увеличиваются до 50, если быстро перемещаться по страницам.

4. Карты

Swift здесь явный лидер, так как работает на 3,6 фрейма/сек быстрее, чем React Native. Данные получены во время нажатия на кнопку «Карты».

Что ж, с результатом 3-1 побеждает Swift!

Memory Usage

Теперь сравним Swift и React Native по количеству используемой памяти. Мы выполнили по одной задаче на вкладку и построили график с памятью (%) по оси y.

1. Профиль пользователя Facebook

В этой категории Swift является победителем, потребляя памяти на 0,07% меньше. Хотя таким отклонением можно даже пренебречь. Скачок по памяти был записан в момент нажатия на кнопку «Войти в Facebook».

2. To-do List

В этой категории React Native превосходит Swift, используя на 0,35% памяти меньше. Пики потребления памяти были записаны при включении элемента в список. При удалении элемента произошел спад в использовании памяти.

3. Page view

Вновь React Native обошел Swift, затрачивая на 0,07% памяти меньше. При переключении между страницами всплесков памяти не наблюдалось.

4. Карты

React Native здесь твердый лидер, оставил Swift позади с массовым использованием памяти в 36,02% для этой категории. Всплеск памяти записан в момент нажатия на кнопку «Карты».

Стоит отметить, что карта работает более плавно на Swift. Скорее всего, это связано с более жестким кэшированием, что мы и видим в результатах.

Выбор платформы

Тестируемые приложения на React Native и Swift очень схожи между собой. Из этого эксперимента мы можем заключить, что хотя React Native показал себя лучше в категории памяти, Swift эффективно использует процессор и графический процессор. В заключение можно сказать, что React Native довольно близок к Swift, и это радует. Однако со счетом 2-1 наряду с высоким потенциалом по памяти Swift по праву становится победителем. К слову, тестировали на iPhone 7.

Популярность React Native меня совсем не удивляет, поскольку с его помощью мы сможем создавать приложения для нескольких платформ параллельно (повторно используя практически весь код приложения). Да, именно так :) Поскольку React Native напрямую зависит от JavaScript, вам почти не нужно разбираться в каких-либо других языках, в большинстве случаев, для создания приложений на iOS и Android отдельно. Кому интересны внутренние процессы выполнения Javascript кода на мобильных устройствах и как работает React Native, обратите внимание на статьи Bridging in React Native, JavaScript Environment.

Но возникает вопрос, так ли эта система подходит для всех видов проектов? Конечно, нет. Перед окончательным решением необходимо принять во внимание множество факторов: ваши текущие навыки программирования, объем вашего приложения и продолжительность проекта — все это нужно учитывать, прежде чем делать выбор.

React Native: плюсы

Повторное использование кода

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

Платформа: «Все включено»

Рассматривая React отдельно, это JavaScript библиотека для построения пользовательских интерфейсов, которая через работу с виртуальным DOM эффективно обновляет и рендерит компоненты. Она отлично делает свою задачу, но в то же время ничего другого не содержит.

Это как готовить целое блюдо из одного ингредиента. Невозможно создать целое приложение, используя только React. Определенно, вам понадобится webpack для сборки кода, подобие CSS для стилизации, что-то похожее на Firebase для обслуживания данных и много чего другого.

Ну а если ваш объем работы ограничен только веб-разработкой, то может быть достаточно и одного React. Однако если вы также занимаетесь разработкой дизайна мобильных приложений, невозможно добавить полный набор инструментов, которые будут универсальны. Вот почему React — это библиотека, а React Native — это фреймворк.

Что предлагает React Native

  • React :)
  • Вспомогательные средства для Android и iOS;
  • Flexbox для стилизации пользовательского интерфейса;
  • Различные виджеты и анимации.

И многое другое...

import React, { Component } from 'react';
import propTypes from 'prop-types';
import { View, Text } from 'react-native';
import { infoMessageStyles } from './styles';

export default class InfoMessage extends Component {
  static propTypes = {
    text: propTypes.string.isRequired,
  }

  render() {
    return (
      <View style={infoMessageStyles.wrapper}>
        <Text
          allowFontScaling={false}
          style={infoMessageStyles.text}
        >
          {this.props.text}
        </Text>
      </View>
    );
  }
}

Интегрируемые нативные компоненты

Вы когда-нибудь задумывались, почему в React Native добавлено слово Native? Такие вещи, как ускорение прокрутки, анимация и предпочтения клавиатуры, значат очень много для конечного пользователя, и с этим невозможно поспорить. Приложения React Native позволяют использовать нативные элементы интерфейсов из операционной системы, одновременно поддерживая парадигму React в JavaScript.

React Native предлагает ряд интегрированных компонентов, что позволяет разработчикам быстро и эффективно выполнять основные задачи. Некоторые из них включают:

  • Текст: используется для отображения текста
import React, { Component } from 'react';
import { AppRegistry, Text, StyleSheet } from 'react-native';

export default class TextInANest extends Component {
  constructor(props) {
    super(props);
    this.state = {
      titleText: 'Nest',
      bodyText: 'This looks like a birds nest.',
    };
  }
  
  render() {
    return (
      <Text style={styles.baseText}>
        <Text style={styles.titleText} onPress={this.onPressTitle}>
          {this.state.titleText}{'\n'}{'\n'}
        </Text>
        <Text numberOfLines={5}>
          {this.state.bodyText}
        </Text>
      </Text>
    );
  }
}
const styles = StyleSheet.create({
  baseText: {
    fontFamily: 'Cochin',
  },
  titleText: {
    fontSize: 20,
    fontWeight: 'bold',
  },
});
  • Вид: используется для проектирования пользовательского интерфейса
class ViewColoredBoxesWithText extends Component {
  render() {
    return (
      <View style={{flexDirection: 'row', height: 300, padding: 300}}>
        <View style={{backgroundColor: 'green', flex: 0.3}} />
        <View style={{backgroundColor: 'blue', flex: 0.5}} />
        <Text>Greetings !</Text>
      </View>
    );
  }
}
  • Текстовый ввод: позволяет пользователям вводить текст
import React, { Component } from 'react';
import { AppRegistry, Text, TextInput, View } from 'react-native';

export default class PizzaTranslator extends Component {
  constructor(props) {
    super(props);
    this.state = {text: ''};
  }

  render() {
    return (
      <View style={{padding: 10}}>
        <TextInput
          style={{height: 40}}
          onChangeText={(text) => this.setState({text})}
        />
        <Text style={{padding: 10, fontSize: 43}}>
          {this.state.text.split(' ').map((word) => word && '🍕').join(' ')}
        </Text>
      </View>
    );
  }
}
  • Кнопка
<Button
  onPress={onPressLearnMore}
  title='A Basic Button'
  color='#841589'
  accessabilitylevel='A beautiful button'
/>

Например, вы можете создать простую кнопку в базе Native, используя исходный код.

React Native: минусы

Ограниченный API

Хотя React Native поддерживает огромное количество API-интерфейсов, все еще существует потребность в использовании других API через встроенные модули. Эти модули в основном являются частью кода, написанного на native языке, после чего интегрированного в существующий код. Несомненно, это отличный способ решить проблему, но вам нужно обладать достаточным опытом в отношении native языка и владеть его инструментами. Возможно из-за этих ограничений вам все же будут нужны профессиональные программисты, которые специализируются на необходимом вам нативном языке, чтобы через мосты делать связки с React Native компонентами.

Различия платформ

Android и iOS используют различные принципы проектирования. Это означает, что с помощью React Native придется включить множество if-statements вместе с отдельным кодом, чтобы укладываться в рамки размещения графических элементов. В дополнение к этому, создание высококачественного пользовательского интерфейса также исключает парадигму React, и мы были вынуждены писать Swift библиотеки при разработке этого приложения. И мы уже не говорим о том, что нужно сопровождать сразу несколько конфигурационных групп.

Относительно низкая производительность

Если вы планируете разрабатывать сложное приложение, такое как редактор изображений или видео, React Native вам не подойдет.

Real Native: плюсы

Нет API ограничений

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

Разнообразие ресурсов для выбора

Разработка в native среде дает доступ к большому количеству сторонних библиотек. Благодаря этому вы сможете создавать более функциональные приложения.

Real Native: минусы

Требование к разработке двух отдельных приложений

Специфичность платформы, — безусловно, самый большой недостаток native. Придется разработать отдельные коды для Android и iOS, и ни один из них совместно использовать не получится.

Сравнение React Native и Real Native Apps

Создание приложения на React Native

Если вы создаете приложение для iOS или Android, вам следует знать три важные вещи:

  • предпочтительный язык программирования;
  • подходящие инструменты;
  • интерфейс программирования (API).

Что касается разработки на React Native, вы вынуждены использовать JavaScript или его суперсет JSX. К счастью, у вас сходу будет отличный набор инструментов. А вот что касается API — будет немного в новинку. Конечно, с помощью React Native вы не сможете сделать все.

Создание Native Android / iOS приложения

Objective-C и Swift — необходимые языки для создания native приложения в iOS. Для Android вам понадобится знание Java. Что касается инструментов, можно использовать IDE для отдельной платформы, а также представить, как IDE и соответствующий debugger помогут вам создать систему.

Что проще выучить

Конечно, JavaScript намного легче изучить, а также отладить, чем Swift, Objective-C и Java. Javascript — это чуть ли не единственный язык, на котором начинают писать еще до того момента, как изучат его, — вследствие его гибкости. Но имейте в виду, всему есть цена. Поскольку JavaScript — довольно простой язык, всегда есть большой риск ошибок в вашем коде.

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

Таким образом, React Native более легкий в изучении, но он приходит с проблемами JavaScript. Более того, как и с любой другой кросс-платформенной парадигмой, вам нужно принять парадокс «написать один раз, развернуть под каждую платформу отдельно».

Выводы

Отлично! В этой статье мы рассмотрели немало важных вещей. Выбор React Native или Swift зависит от ваших личных предпочтений и требований. Мы бы сказали, что если ваше приложение не сложно и не включает в себя сравнительно последние функции, такие как сложные анимации или редактирование видео, остановите свой выбор на React Native, хотя вы всегда можете написать часть кода на нативном языке.

Однако, если вы новичок в мире программирования, вначале мы бы порекомендовали запуск на одной платформе с использованием нативного языка. Старайтесь наблюдать за тем, как это работает. В будущем сможете подойти к изучению других платформ.
Как думаете, React Native — это будущее разработки гибридных приложений? Какая платформа, по вашему мнению, более практична?

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




49 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Коментар порушує правила спільноти і видалений модераторами.

Пробовал. Разрабатывать под андроид было лажево на react native. Вы из-за этого не сравнивали?)) Вообще, не думаю, что реально нужно метаться туда пока все так сыро и версия даже до 1.0 не дошла.

— Чому не згадуеться shouldComponentUpdate, та скільки саме реакт робив render?

— Де приклад з андроідом?

React Native: минусы
Ограниченный API

Тільки якщо програміст обмежений, бо завжи можно facebook.github.io/...​s/native-modules-ios.html

Не читайте это.

Почему никто не упомянул про уязвимости безопасности у React Native. Слышала, что у нативных приложений с безопасностью проблемы.

Можливо крім вас ніхто не знає, то ж доповніть.

Слышала, что у нативных приложений с безопасностью проблемы.

Якесь ОБС вийшло (tinyurl.com/yd62zx6q). Де приклади?

Стоило конечно указать, что вы сравнивали именно производительность, а не цикл разработки. Если не ошибаюсь, то результаты почти не играют роли, но хорошо что почти равные..

Еще хотелось бы посмотреть на benchmark для Андроид. Будет?

По поводу самого сравнения, сорян, но вы сравниваете на очередном примитиве. Сравнивайте на реальных приложениях с красиывми анимациями, инфинит скроллами, кешированием, обработкой изщображений, локальной бд. И вот тут оказывается, что чтобы написать фиговый POC времени тратится на 30% меньше на RN чем написать два натива. Зато, когда вы начинаете вылизывать, то вдруг оказывается, что написать два натива в 1.3-1.5 раза дешевле, чем одно RN приложение. Это кроме того, что вам в команде кроме жсеров прийдется на постоянной основе держать нативщиков, т.к. вам прийдется писать кучу нативных модулей, чтобы оно нормально работало.

Swift достаточно приятен в работе, особенно если сравнить его с предшественником Objective C

Очередные неосиляторы? Ок.

Язык по сложности приближающийся к крестам против простого динамического языка с возможностями рантайм метапрограммирования. Хмм... Что же выбрать?

XCode, безусловно, является отличной IDE, и значительно упрощает разработку в сочетании со Swift.

Ну дял джаваскриптизеров, может и упрощает. Т.к. из идешек один вебсторм. А так хкод — фекалия с отваливающейся в свифте подсветкой синтаксиса, автоподсказкой и постоянными зависаниями.

там вообще феерическая проблема присутствует — автосгенеренный код при сборке вываливает ошибки компиляции. если набрать тоже самое руками — все работает

Javascript — это чуть ли не единственный язык, на котором начинают писать еще до того момента, как изучат его,

вот для кого этот маразм пишут?

А почему — маразм? Всё правильно написано; довольно часто какой-то довольно простой код на JS пишется задолго до того, как человек погружется во все нюансы языка.

маразм, потому, что промоутится как достоинство.

Питон в этом смысле промоутится даже больше, как мне кажется...

питон обычно промоутится как язык для прототипирования и несложных скриптов. никто в своем уме на нем не будет писать более менее сложные приложения в продакшн. а вот формошлепов-апологетов жабаскрипта приставка «скрипт» не останавливает

никто в своем уме на нем не будет писать более менее сложные приложения в продакшн.

Це чому? Що такого є в пітоні, що заважає писати складні проекти?

ээ. интерпретатор? отсутствие меори менджмента? скриптовая натура? за одни табы прибить надо

за одни табы прибить надо

Ось тут рекомендують spaces vs tabs: stackoverflow.blog/...​aces-make-money-use-tabs

Як інтерпретатор заважає писати складні проекти? А скриптова натура?

писать не мешает, но поддержка превращается в ад

Чому? Яка саме підтримка?

А что конкретно понимается, например, под «memory management»? А то так-то и Java с C# ручное управление памятью несвойственно.

С точным пониманием того, что такое «скриптовая натура», тоже неплохо бы определиться. Есть какие-то объективные признаки, которые делают язык «скриптовым», кроме интерпретируемости?

В случае Питона, насколько я помню, интерпретируемый он в случае дефолтной реализации CPython (и то кэшируется в виде байт-кода), а в том же Jython прекрасно компилируется в байт-код JVM.

никто в своем уме на нем не будет писать более менее сложные приложения в продакшн.

Это глупости простите.

Питон «промоутится» не как «для несложных скриптов» а как «для несложных умов» в этом основной поинт.

если «несложный ум» возмется писать сложный проект на питоне, будет бяда

вот и я говорю пусть на сях пишут на худой конец на плюсах гыгыгы

а на чем же еще?!?

Я тоже так считаю! К тому же люди, которые пишут/поддерживают такой проект как TensorFlow, просто напросто обладают «несложными умами», иначе как объяснить то, что они толком и программировать то не умеют — только матрицы свои считают (перемножают), сравнивают веса на входах нейронов с входными сигналами и дифференцируют целевые функции на графах вычислений. Вот и всё! Фу фу фу!

Истинно вам говорю всё можно написать на питоне!!!

An in-depth look at Google’s first Tensor Processing Unit (TPU)

Тру. Там больное место лично мне непонятное но уже неоднократно встреченное реализованное на практике

писать еще до того момента, как

— мы тут прототип накидали но что-то не работает...
— ну давайте глянем код а питончик ну ок пусть будет питончик (которого я не знаю но это же ж всё равно язык) хм странно гляну ка я в доку стоп чуваки у вас тут в одну сторону бинарные данные едут всё честно а обратно почему-то уже текстом отвечают...
— не может быть вот же ж функция тут всякие целые числа бла-бла-бла!
— чуваки это функция форматирования в строку...
— а ну ок мы будем думать...
— чо там думать чуваки я уже доку почитал вот функция сериализации в бинарный вот так оно будет работать и вот оно уже работает.
— а ну ок.
(к)

При общении с фронтенд обычно js основная проблема понять что они делают потому как чаще сами объяснить они не могут. Это реальная жопоболь потому как есть вариант развития когда из них выходят начальники либо уже их начальники и начинают распространять это (якобы «подход») на всё остальное включая появление на проекте странных людей которые

писать еще до того момента, как

Причём на ролях где-нибудь «архитекторов» туда же ж приближённых к начальству

— хм чуваки тут у вас нарисовано оно как бы боль оно работать так не будет а если и будет мы никак это не осилим в нарисованные же ж 2 недели (до Рождества гыгыгы) а вы так и вообще не осилите это никогда... (ну ок последнее обычно прямо не говорится)
— но мы уже презентовали эту архитектуру верховному командованию и всё утвердили!
— ...
(к)

ЗЫ: кстати вариант последнего похоже и «нарисовано» в данной «статье» ))

Можно подумать, на любом другом языке программирования нельзя творить подобную фигню :)

С другой стороны, вы меня простите, пожалуйста, но, кажется, что мыслить в духе «сложные и серьёзные проекты можно писать только на С/C++» в 2017 году могут только IT-романтики, ибо практика реальной коммерческой разработки говорит совсем о другом.

С другой стороны, вы меня простите, пожалуйста, но, кажется, что мыслить в духе «сложные и серьёзные проекты можно писать только на С/C++» в 2017 году могут только IT-романтики, ибо практика реальной коммерческой разработки говорит совсем о другом.

Думаю я что-то пропустил причём тот самый неловкий момент когда я таки пропустил что-то что было таки у меня сказанное.

Пардон, это было, скорее, в адрес Vlad Stelmahovsky

Так это правда, просто красивыми словами написали то, что остальные называют «говнокодить»

По порівнянню не досить зрозумілий фінальний результат перфомансу. Підбір метрик і аналіз досить хиткий. Але! Можу на власному досвіді додати ’+’ в сторону React Native. Працював і працюю з RN, замовники завжди були задоволені. Дійсно є трабли, які більше пов’язані third party libraries, а не самим RN. Зрідка консультували Android деви. Але фреймворк вже відносно зрілий у порівнянні з 2 роками назад. Довелося інтегрувати багато фіч з перефірії або ж нативних фіч на RN, а саме: камера, баркод сканінг, геолокація, робота зі звуком, AsyncStorage (андроїд) і т. д. і все працює. RN це більше альтернатива або business solution якщо хочете для спрощення розробки, але не заміна нативному.

Статья создана в соавторстве с Шармином Хаятом, Data Specialist и с помощью Андрея Горобца, Front-end Developer.

Два чувака, которые не имеют опыта в мобильной разработке сравнивают JS фреимворк и язык программирования.... WAT ???
А замер использования памяти вообще прекрасен — интересно, какие выводы они сделал на основе этого теста?
А так-то да — в борьбе языка и фреимворка проигрывает здравый смысл

Странно, что аксиому Эскобара ещё никто не упомянул.

Эта теорема применима при сравнении React c Cordova

Удивило сравнение

Swift vs React Native

 — Язык программирования vs Framework :)

Mike Gerasimenko верно упомянул, что в тестах нет ничего «что может показать производительность». Одной из сильных сторон React Native является возможность создания нативных контролов, используя скрипты JavaScript (которые крутятся в виртуальной машине). Например, создав элемент «карта» вы никак не сравнили производительность двух разных подходов к разработке, т.к. React Native создает все тот же нативный элемент на экране

но при этом они умудрилсь у свифта нсчитать потребление памяти в 2 раза больше, что делает эту статью похожей на рекламу от фейцбука (или кто там промотит этот эректнаив)

Действительно, некоторые метрики большого смысла не несут. Компоненты очевидно разные, но в конечном счете они оба нативные. Такие цифры по потреблению памяти у одного компонента связаны с более агрессивным кэшированием.
Тут уже не кто быстрее и производительнее, — это очевидно не React Native должен быть, а сколько будет потеряно ресурсов и стоит ли вообще о них париться, если работать с некоторыми участками проекта удобнее. Похоже на демагогию о JIT и статических компиляторах.
Кому-то удобно часть кода на react native писать, например instagram, airbnb, — другим оно не нужно.

На простеньких примерах всё конечно работает практически одинаково, но вот если создать (или хотя бы попробовать) создать полноценное приложение на реакте и на джаве (речь конечно про андроид), то реакт останется далеко позади, по всем показателям. Это я из личного опыта говорю. Единственный гипотетический плюс — возможное ускорение разработки и то далеко не факт.

Я не совсем понял смысла/необходимости сравнения производительности. В ваших примерах как мне кажется ничего чему требуется производительность не делается. Мне кажется в данном случае выполняется 99% кода iOS, и производительность должна быть сравнительно одинаковая (что мы и видим).

Конечно, JavaScript намного легче изучить, а также отладить, чем Swift, Objective-C и Java.

Легче отладить? Це не жарт і це все серйозно ви кажете?

Отлаживать действительно может быть легче благодаря отличной поддержке hot reload в React Native.

Вместо двух приложений нужно делать полтора, с тормозами и ограничениями? Ну такое... Для формошлепства и Cordova/Ionic хватает, а это зачем — не понятно.

Ну например если бОльшая часть логики приложения — это общение с какими-нибудь Веб-сервисами (именно эта часть при использовании RN пишется ровно один раз), и при этом пользовательский интерфейс, всё же, посложнее банальных формочек, и не очень подходит для web view.

Ну сферическое приложение в вакууме я себе тоже могу представить, но разве весь выигрыш в итоге не нивелируется объемом костылей для прикручивания логики к кардинально разным вьюшкам?

Был продакшен опыт с RN. Делали ios и web приложение практически одинаковые по функционалу. Вьюшки совсем разные, но много удалось вывести в модули и импортировать. Серебряной пули, думаю, не будет. Интересно было бы узнать, как поддерживать параллельно и android, и ios.

Баги критические были в самом RN. Один до сих пор не исправили — рандомно вываливалась загрузка внешнего изображения, если нужно было сразу его рендерить, например аватар. На github уже тысячи комментов, но ничего не правят..

Если мы говорим о написании одного приложения для двух платформ, то обычно логика приложения будет одна, а визуальная часть может отличаться, т.к. у каждой платформы есть свои гайдлайны и т.п.
В РН есть несколько способов сделать кастомный код под платформу, кроме простого if (platform === ’adnroid’), любой JS файл можно сделать в платформенном варианте, просто создаешь вместо component.js два файла component.android.js и component.ios.js и делаешь различные реализации. Этот подход работает на любой js файл, не только на визуальные компоненты.
Ну и с точки зрения написания на РН (hot reload вместо 5минутных компиляций) и последующей поддержки одного кодбейза вместо двух (внесение изменений, фикс багов), из моего опыта РН эффективней в 2-3 раза, чем нативная разработка. Ну и одна команда лучше чем две, меньше коммуникаций, синхронизаций.

Підписатись на коментарі