что такое react native и зачем он нужен
React Native — одного JS мало
Итак, пришла пора быстро погрузиться в тему. Для усиления эффекта, использую разные техники преобразования информации в знания. В частности, представляю конспект доклада Алексея Андросова (старшего разработчика интерфейсов, Yandex).
React Native — это фреймворк для разработки кроссплатформенных приложений для iOS и Android:
Первый ли он? Нет!
Инструменты разработчика
React Native: взгляд сверху
React Native: взгляд изнутри
Write once, run everywhere? Нет! Вместо ожидаемых предположений, что один и тот же код будем использовать многократно на разных платформах. Learn once, write everywhere. Одинаковая архитектура приложения (React для построения интерфейса, Redux для круговорота данных).
Немного философии
Все нативно, поэтому забудьте про полную кроссплатформенность. Платформы разные, поэтому и компоненты разные. У них разная логика и механика взаимодействия. Можно писать все на JS и выкинуть понятие native, но вы этого не хотите. Native — это ваше преимущество!
На примере приложения Vine в iOS. Что принято делать в iOS? Внизу TabBar, в нем принято переключать экраны: главная, профиль, поиск. Сверху NavigationBar, и в нем принято писать название и кнопки слева-справа (слева обычно back стоит, а справа — какое-нибудь действие). А в Android все не так. Есть тоже NavigationBar, но он другой, в нем не принято кнопки делать. Для этого есть отдельный компонент, называется ToolBar-ом. В Android-е принято делать SegmentedActivity — она сверху, очень похожа на iOS TabBar, но механика работы у него абсолютно другая. Если в TabBar-е мы не можем свайпом переключать экраны, то в Android-е это можно делать, и это принято делать, и именно так оно и работает.
Кроссплатформенность
Из чего состоит приложение?
Компоненты
Приложение строится из компонент платформы — это нативные модули, завернутые в React-компоненты
[Вот так это выглядит, реальный код]
Интересно, что кнопок нет! Для вас любая кнопка — это просто стилизованная область, у которой есть обработчик нажатия. Никакой механики кнопки нет. И поэтому в React-е есть вот эти touchable-элементы, вы оборачиваете всё, что угодно и у вас всё что угодно становится кнопкой по сути (есть обработчик onPress). Scroll-ы — отдельный компонент. Это сегментированный вид. Он рендерит только то, что находится на экране, и с ним нужно работать чуть по другому. Потому ScrollView тут тоже отдельный. Отдельная механика, если используется клавиатура. Потому отдельное свойство есть — чего с ним делать. Отдельно свойство refreshControl. Если кто-то знает, как разрабатывать на iOS, то это очень похоже.
[Вот как выглядит текстовое поле]
Какие-то свойства совпадают с привычным HTML-input-ом, а другие — нет.
CSS не настоящий — это полифил
Компонент PixelRatio преобразует значения из density points в настоящие пиксели для разных экранов (Retina и прочее).
Вот это пример с flex-ом. Хватает минимального набора, чтобы верстать.
Болванка приложения
[Пример кода приложения]
Navigator
Во многом, проблемы решаются с помощью redux.
Чтобы запушить какой-нибудь роут, или сделать back (перемотать на другой экран) — надо сделать ссылку на Navigator, а потом эту ссылку получить. Причем изначально её не будет, т.к. Navigator-а еще нету.
[Интерфейс выглядит, как связанные компоненты]
[А на самом деле всё выглядит вот так]
NavigationBar или зачем нужен redux
В декабре 2015 Eric Vicenti организовал проект navigation-rfc, с помощью сообщества, попытался решить проблемы Navigator. В феврале 2016 проект переехал в мастер React Native под название NavigationExperimental и теперь развивается силами Facebook. А старый Navigation больше не будет поддерживаться.
NavigationExperimental — что сделано
[Пример кода навигации]
Анимации
[Пример кода анимации]
Работает очень плавно, можно комбинировать последовательно/параллельно, и делать довольно безумные штуки.
Нативные модули
React Native реализует основные, но не все. Если модуля нет:
Как подключить нативные модули
Используйте rnpm — React Native package manager:
Кроссплатформенность компонент
Неправильный путь — разложить все по папкам:
и подключать их в зависимости от платформы
Правильный путь — разложить все по папкам:
Для платформо-зависимых компонент (ComponentIOS, ComponentAndroid) удобно класть рядом пустышку, и не испытывать проблем, что какой-то компонент не найден на платформе.
Как написать нативный компонент
Коллега скинул ссылочку на Weex — две недели назад Alibaba передал проект Apache.
И опять внутри Vue. Что-то оно все время путается у меня под ногами.
Только проникся идеями React+Redux, бегаю с ними, как сумасшедший с бензопилой, в попытках везде применить. А тут что получается — разворачивай дебаркадер?!
Будет очень интересно почитать сравнение, может кто возьмется — тема на Хабре новая.
React Native с точки зрения мобильного разработчика
Статья ориентирована на iOS и android разработчиков, которые уже достаточно хорошо разбираются в своей области и поглядывают в сторону React Native.
Впервые узнав про React Native, я воспринял его как повод для веб-разработчиков вторгнуться на мою территорию (нипазволю!) и заодно испортить хорошо работающий crash-free-60-fps продукт. Так оно и произошло. Конец. Реальная история оказалась длиннее.
Отрицание
JavaScript в мобильном приложении? В голову приходило всего пара библиотек с использованием JavaScriptCore на iOS (эти же библиотеки были причиной 90% падений приложений, в которых использовались) и гибридные приложения “старого образца” (ну это вообще атас).
Гибридные приложения подавали надежду до того момента как ты их попробуешь, после чего начинаешь бежать от них сломя голову и как можно дальше.
Вспоминая неудачные потуги в освоении Xamarin 3 года назад я быстро отказался от идеи использовать React Native.
Стоит отметить что я всегда с радостью воспринимал новые способы написания нативных приложений (от ObjC к Swift, от Java к Kotlin, от Eclipse к Android Studio). Уже много лет занимаюсь iOS и android разработкой в качестве хобби и профессионально. После перехода на новый язык (внутри одной ОС) или IDE я редко возвращался к предыдущему. Казалось бы React Native — логичный следующий шаг, ещё одна новая ступень вверх. Или это шаг назад?
К чему мне учить упрощённый вариант, когда я уже знаю как делать это “по-настоящему”?!
На этот вопрос мне ещё предстояло найти ответ когда компания поставила задачу полного редизайна одного из приложений (в тот момент доступного только на iOS) и выпуска его на android.
Как сделать сразу два дела и написать меньше кода? Напрашивались решения вроде: тонкий клиент, библиотеки на C с вызовом из Swift / Kotlin кода, React Native?
React Native выглядел довольно перспективно из-за возможности сделать библиотеки и затем использовать их сразу на трёх платформах (iOS / android / web).
Торги
Перспективно для кого угодно, но только не для меня. Я точно не был счастлив такому повороту. Чувствовал что нахожусь на пике способности к развитию iOS и android и тут меня попросили выбросить все эти знания, как будто я свежий выпускник и опыта у меня 0. Ещё больше я сомневался в том что с React Native можно создать качественный продукт.
Депрессия
Сомнение были обоснованными. Главные проблемы:
Принятие
И конечно React Native — это не только минусы. Есть много хорошего, пишется это намного проще и работает из коробки лучше чем тоже самое на конкретных платформах.
Если отбросить очевидные проблемы, вроде падений и скудных доков, то вот примеры того, с чем пришлось столкнуться:
JavaScript
Ничего удивительного. Это первое с чем придётся идти рука об руку через кровь, пот и слёзы.
Когда я начал вспоминать свой предыдущий опыт frontend-разработчика (до мобильных приложений занимался сайтами), у меня начался вьетнамский синдром: Джонни, JavaScript нас окружает!
Если решите писать приложения на React Native, то рекомендую пройти один из свежих курсов по JS. Необязательно чтобы они были по React или React Native.
В последние несколько лет с выходом стандартов ES6, ES7 и ES8 способ написания кода сильно изменился.
И он стал очень даже ничего.
Статическая проверка
В первые месяцы очень недостаёт статического анализатора, который есть во всех нативных мобильных языках.
Есть разные утилиты, которые сглаживают его отсутствие, выполняя часть функций
Вёрстка элементов
Самым большой вызов здесь будет для начинающих iOS разработчиков.
Этот вызов — отсутствие визуального редактора интерфейса.
Всё делается в коде с помощью JSX-разметки. Технически, эта разметка не обязательна, она помогает увидеть иерархию компонентов. Android-разработчики будут в своей тарелке, заметив сходство с XML.
Одновременно есть понятный вид вьюшек и потенциал для переиспользования.
В iOS нет либо одного либо другого, зависит от того какой метод выбрать (вёрстка в коде или в Interface builder). Да, обе эти проблемы решаемы, но приходится писать приличное количество кода.
В React Native нет этой проблемы.
В Android, кстати, её тоже нет.
Зато Android-специалисты оценят способ передачи параметров из внешних компонентов во внутренние прямо в разметке.
Базовые View здесь — аналог LinearLayout (android) и UIStackView (iOS) с примесью констрейнтов одновременно. Довольно простой способ (по сравнению с констрейнтами) позиционирования элементов.
UIViewController и Activity
В React Native нет ни того ни другого.
Конечно они есть под капотом. Напрямую взаимодействовать с ними не получится. Да это и не нужно.
Жизненный цикл всех React Native компонентов полностью отличается от iOS и android, сложно провести какие-то параллели. Если сосредоточиться на отличиях от нативных систем, то:
Время сборки / Live Reload / Hot Reload
Большая скорость достигается за счет инкрементальной сборки — пересобираются только измененные модули, а не весь бандл.
Все изменения в JS-коде видны сразу видны в симуляторе. Колоссально ускоряет разработку!
Отсутствие нативного функционала в JS
В JS-части React Native из коробки доступно не всё что нужно.
Можно написать нативную часть на обе платформы, сделать JS-обёртку и вызывать её как остальной код. Ничего сложного нет.
Есть большое количество готовых модулей, написанных сторонними разработчиками.
Все модули подключаются через npm (аналог CocoaPods для iOS и Gradle для android), в которых есть нативный код с нужным функционалом.
Универсальные и глубокие ссылки
Функционал реализован силами Facebook.
Работает хорошо и консистентно.
Обработка сторонних Intent’ов
Как частный случай предыдущего пункта.
Самая большая проблема на android — обработать Intent, отличный от диплинка в приложение.
Зависит, конечно, от Intent’а и что необходимо сделать при его получении.
На эту тему можно написать отдельную статью. Стартовая точка — добавить метод createReactActivityDelegate в MainActivity.
Производительность
Довольно просто получить 60 FPS при прокрутке длинных списков со сложными ячейками.
Производительность всего остального (например — нажатие на кнопку, печать текста в поле) ниже. Заметно при анимированной смене состояния у большого количества элементов. С этим можно легко бороться. Хороший раздел в документации Using Native Driver for Animated.
А ещё из коробки нельзя получить нормальное управление жестами и их связывание с анимацией.
Нестабильность
Часто проект просто прекращает собираться, например после:
Нестабильность сторонних зависимостей
Самой большой проблемой на iOS было и есть повсеместное желание npm-модулей использовать method swizzling.
Множество нативных модулей подключается бинарниками. Понять что несколько независимых модулей свиззлят один и тот же метод не так просто.
Сборка происходит в несколько этапов и на каждом из них может что-нибудь пойти не так.
Нестабильность при обновлении сторонних зависимостей
Одни npm-модули зависят от других npm-модулей и так далее. Если два модуля завязаны на разные версии третьего модуля, то мы сразу получаем warning при установке, в лучшем случае. А в худшем случае warning’a нет, но ничего не работает.
Аналогичная проблема, если npm-модули полагаются на нативные Android-модули с разными версиями.
После чистки кеша могут тихо подгрузиться новые версии. Вроде ничего не делал, а работать перестало.
Unit и UI-тестирование
Очень лёгкий механизм тестирования через библиотеку Jest, идёт в комплекте к React Native. Удобный анализ покрытия тестами — показывает какие строки в тестируемой функции не вызывались ни разу.
Есть библиотеки для UI-тестирования. Пока на деле не пришлось использовать.
Заключение
Спустя 13 месяцев работы с React Native могу с уверенностью сказать:
Если считаешь что разобрался в теме и у тебя хорошо получается, то пожалуйста, пожалуйста, попробуй себя в роли нативного разработчика.
React Native: плюсы и минусы фреймворка в 2021 году. UPD
Время чтения: 4 минут
Привет, я Саша Пуртов, тимлид команды React Native разработки в Purrweb. Рассказываю, как фреймворк показывает себя в бою — на реальных проектах.
Без красивых историй про то, как «Facebook перевернул мобильную разработку, подарив миру универсальную технологию». Это понятная статья «в лоб» о том, какие у React Native плюсы и минусы. Идея рассказать про особенности фреймворка пришла ко мне ещё год назад — теперь есть желание обновить информацию.
А теперь давайте к сути. 🙂
Преимущества React Native
Общая кодовая база. Фактически вы разрабатываете 2 отдельные версии приложения (под iOS и Android). Да, две версии приложения, но код в них на 65-70% одинаковый.
Общий код минимизирует количество багов по ходу разработки (объем кода будет почти в 2 раза меньше) и значительно упрощает поддержку продукта в будущем. Для стартапов это выливается в дополнительные дни и недели, которые можно потратить на активности со «звездочкой» — например, на проработку маркетинговой стратегии, анализ способов монетизации и планирование будущих итераций развития продукта.
Максимально похож на нативный. В отличие от других кроссплатформенных решений, вроде Cordova, Ionic или Titanium, которые имитируют среду браузера (все равно, что сайт, который притворяется мобильным приложением), React Native использует нативные API.
Нет никаких проблем с табами и скроллированием, а интерфейс ведет себя так же отзывчиво, как и в классическом приложении — без WebView и схожих инструментов под капотом
Говоря о том, какой перворфманс можно получить с React Native, предлагаю посмотреть на экраны приложения, которое мы разработали в Purrweb:
Сервис аренды жилья PAD. Свайп выглядит так, как если бы вы разрабатывали на Java/Swift
Различные наборы компонентов и библиотек для React Native (преимущество всех хороших фреймворков) помогают закрывать performance-задачи по ходу разработки продукта. Нужно только убедиться, что библиотека, которую планирует использовать ваш разработчик, достаточно часто обновляется и поддерживается сообществом.
Кстати, раз уж говорим про плюсы и минусы React Native, давайте поговорим и про сообщество.
Большое комьюнити. Жирный плюс в том, что фреймворк начинает обрастать «проверенными» библиотеками от сообщества React Native https://github.com/react-native-community
. Такие либы очень хорошо поддерживаются, для них гораздо быстрее выходят багфиксы и патчи под новую версию фреймворка. Также есть репозиторий https://github.com/react-native-community/upgrade-support
, в котором можно получить помощь, если что-то не заладилось с обновлением версии React Native.
К слову о комьюнити: в середине 2020-го официальная команда поддержки фреймворка выпустила большой патч с апдейтами всей документации.
И многое другое. Подробности читайте тут https://reactnative.dev/blog
А ещё хочется упомянуть Reddit https://www.reddit.com/r/reactnative/
— здесь можно найти огромное количество обсуждений проблем и советов от разработчиков с приличным опытом разработки на React Native.
Поддержка TypeScript. Статическая типизация = меньше багов + простая поддержка проекта и возможность легко создать приложение из шаблона. Сейчас мы используем TypeScript на всех наших проектах, уж очень он хорош.
Быстрый поиск подрядчика. Тратить уйму времени на поиск Swift и Java разработчиков не придется. Достаточно отыскать того, кто знает JavaScript, и можно стартовать. Если найдете того, кто разбирается в React (тот же RN, только для веба), будет еще лучше.
Вот еще несколько плюшек:
Останавливаться на одних лишь позитивных моментах в статье «React Native: плюсы и минусы» не буду — при таком раскладе я стану походить на человека, который ломится к вам в дом и пытается что-то впарить. Как правило, это какая-то дичь, которую подают под соусом «уникальности». Обсуждать плюсы и минусы React Native — важно. А он, как и любая другая технология, никакая не серебряная пуля.
Недостатки React Native
Молодой фреймворк. Это (пока) не версия 1.0.0, поэтому некоторые компоненты все еще отсутствуют и сама технология довольно часто обновляется.
Для разработчика «незрелость» React Native означает, что ему нужно следить за версией как самого RN, так и библиотек зависящих от него. Продукт нельзя отложить на год, а потом начать добавлять новые фичи — потребуется время на обновление фреймворка.
Cейчас эта процедура занимает значительно меньше времени, чем два года назад, так как появились удобные сервисы, показывающие где и что конкретно нужно изменить
Сложно адаптировать под все андроиды — cлишком большой пул девайсов, очень много разных разрешений и оболочек. По факту, это скорее проблема разработки под андроиды, нежели самого React Native.
Где использовать?
О плюсах и минусах React Native я рассказал. Разрабатывать на этом фреймворке или нет — выбор напрямую зависит от специфики вашего проекта. Чтобы как-то это все подытожить, пара слов о том, где эта технология работает на 5 с плюсом.
Минимально жизнеспособный продукт (MVP). Если планируете тестировать бизнес-гипотезу и нужно функциональное решение с крутой визуализацией, React Native — это отличный выбор. Возможность одновременного выхода на Android и iOS-рынки позволит быстро собрать первую обратную связь.
Какой MVP можно получить на выходе?
Все, о чем я здесь рассказал, включая плюсы и минусы React Native — опыт, полученный за время реализации десятков проектов. Текущих и тех, что успешно зарелизились и перешли в фазу поддержки. За React Native я #топлюибудутопить, тут же старался дать максимально честную и четкую картинку того, что имеем по факту. Надеюсь, получилось 🙂
Хотел, чтобы статья про плюсы и минусы React Native была полезной и для коллег по цеху. Господа-разработчики, охотно делюсь списком must-have ресурсов для разработки на React Native:
React Native: очередная «серебряная пуля» для кросплатформенной разработки?
Есть революции, которые происходят незаметно. Когда разработчики Facebook выпустили фреймворк React Native, никто не захватывал мосты и телеграфы. Новому подходу к кроссплатформенной разработке мобильных приложений удалось взять в плен самое ценное – мозги нативных программистов. Рассказать о центральной идее React Native, его преимуществах, перспективах и недостатках мы попросили Владимира Иванова.
Владимир более шести лет занимается разработкой под Android, обладает опытом создания приложений под iOS и Windows Phone. Последний год он увлекся React Native и начал двигать культуру кроссплатформенного кода в EPAM Systems.
— За что Вы не любите платформенный код? Какие недостатки видите в нативной разработке?
Владимир Иванов: Когда заказчик говорит, что хочет мобильное приложение под все платформы, он не понимает, что Android, iOS и Windows — это принципиально разные вещи. Разработчикам программного обеспечения приходится повторять один и тот же код, одну и ту же бизнес-логику на двух или трех платформах.
Сами платформы тоже имеют многообразие. В iPhone на iOS могут быть варианты по версиям, возможностям, по размеру экрана. А в Android это достигает катастрофических масштабов: нужно поддерживать не только версии, начиная с 2.3, но и огромное количество устройств. Это превращает нативную разработку в довольно утомительное занятие.
Приведу пример. У меня на Github лежит образовательный проект Flick Feed на React Native. Там порядка 100 строчек кода суммарно для двух мобильных платформ. И есть подобный проект на BitBucket на Android, который я делал несколько лет назад. Там кода до чертиков, на порядок больше, и это только приложение под Android! Вот смотрите:
Это верстка одного элемента из фида, здесь 36 строк, и нет логики. Нужно еще посмотреть в Activity, там будет код, который ищет вьюхи, ставит в них значения. Еще inflate нужно для элемента написать.
Этот же элемент в RN занимает 21 строку, причем логика установки значений уже есть, а inflate вообще не нужен, смотрите
— Попытки создать удобный кросс-платформенный фреймворк для мобильной разработки идут уже несколько лет. Ни явного лидера, ни «серебряной пули» так и не появилось. Почему?
Владимир Иванов: С момента появления Android и iOS существует приличное количество решений, которые пытаются решить проблему шаринга кода. Это PhoneGap, Titanium и другие.
Я вижу в своей практике, что люди используют такие фреймворки только для проверки бизнес-идеи. Они позволяют понять, что приложение действительно может быть рабочим, им удобно пользоваться, бизнес-идея нормальная. Если все так, то дальше все делается заново по-нормальному в нативной разработке.
Эти фреймворки по сути предоставляют WebView и возможность написать на html + css + js то, что будет в этом WebView крутиться. Соответственно, вы понимаете, что качество самих приложений, User Experience, которое это решение может предложить, не самое лучшее. Точно не то, что вам может дать сама платформа.
— Чем React Native отличается от других фреймворков?
Владимир Иванов: React Native лучше тем, что у вас нет никакого WebView. Он использует родные компоненты пользовательского интерфейса Android, iOS и Universal Windows. Такая реализация позволяет раскрыть всю мощь платформ: интерфейс не тормозит и выглядит нативно, что предполагает качественный UХ.
React Native вырос из ReactJS, который в свою очередь появился потому, что разработчикам Facebook было не очень удобно в традиционных средствах веб-разработки поддерживать свои приложения. Особенность ReactJS — наличие слоя рендерера, позволяющего промежуточный язык JSX отрендерить в HTML, который уже воспринимается браузером.
В какой-то момент ребята из Facebook поняли, что для своих мобильных приложений они могут использовать точно такой же подход. Архитектура React позволила добавить нативный рендерер, который превращает JSX в нативные компоненты платформы. Таким образом, они эволюционным путем получили React Native, не ставя себе изначально задачу создания какого-то необычного фреймворка, а придя к нему естественным путем.
— В React Native есть такая штука, как виртуальный DOM. Это и правда классное решение, которое ускоряет разработку приложений?
Владимир Иванов: React построен таким образом, что главное занятие его компонентов — только отобразить состояние. Метод render(), который есть у компонента, смотрит в State и рисует содержимое на его основе. Когда State меняется, React пересоздает целиком дерево своих компонентов. Вот это дерево называется виртуальным DOM.
То есть когда у вас меняется состояние, необходимо перерисовывать всю страницу заново. Но это плохо с точки зрения перформанса. Что делает React? Он в своей памяти хранит старое и новое дерево компонентов виртуального DOM, вычисляет разницу и на реальном DOM применяет только ее. В виртуальном DOM происходит полная перерисовка, а в реальном — только частичная. Рендеринг происходит очень быстро, а код пишется просто.
— Как соотносятся элементы, которые используются в React Native и в нативной разработке?
Владимир Иванов: Некоторые элементы похожи на нативные. Например, текстовый ввод. Но мощь React Native в том, что вы можете создать собственные компоненты под свои нужды. Вы всегда можете написать обертку над нативными средствами для своего React Native и продолжать в JavaScript считать, что у вас кросс-платформенное приложение.
Очень много вещей так и работают, например, Push-нотификации. Существует решение, которое имплементируется в Java-код для Android, в Objective-C для iOS. Дальше этот NPM-модуль подключается к вашему проекту, и у вас появляется JavaScript-интерфейс для Push-нотификаций. Если нужен доступ к низкоплатформенным вещам, вы всегда сможете их обеспечить.
— Какие недостатки есть у React Native?
Владимир Иванов: Если у вас есть строгие требования к интерфейсу для разных платформ, и он сильно отличается в разных версиях, вам придется дублировать значительную часть UI.
Но бизнес-логику вы все равно сможете оставить кросс-платформенной. То есть, используя какие-то внешние хранилища для стейта и создав правильную архитектуру для React Native, вы все равно сэкономите большое количество усилий.
Конечно, не стоит забывать, что React-Native — технология молодая и без «косяков» не обойтись. Например, крупный такой «косяк» — навигация. Несмотря на то, что RN прошел уже 4 стадии переделки навигации (Navigator, NavigatorIOS, NavigationExperimental, … ), пристойного решения так и нет. Обещают, что следующая навигация уж точно будет хорошей, но, как известно, обещанного ждут три года.
— Что надо изучить, чтобы начать работать с React Native?
Владимир Иванов: Разработчику в первую очередь нужно знать JavaScript и его стандарт ES6. Вся мощь Babel нужна, чтобы не писать везде React.createClass и остальной Boilerplate. Поэтому рекомендую изучить ES6.
А со всем остальным человек знакомится достаточно быстро. В течение месяца, прочитав материалы и прослушав обучающие курсы, которых полно в интернете, можно быстро начать верстать более-менее нормальный UI.
Конечно, есть сложные темы — внешний State, валидация форм, использование контекста в React Native. Про эти вещи я расскажу на Mobius 2017, так что можно прийти послушать.
Желающим изучить React Native нужно читать Getting Started от Facebook. Также рекомендую курс на Udemy. Кроме того, стоит следить за гуру, которые занимаются React. Я рекомендую твиттер Дэна Абрамова, он достаточно много пишет про React Native.
Конечно, есть целая печалька в том, что если вы приходите из области, в которой мобильных приложений ни разу не касались, то вам нужно проходить этот квест про установку родных сдк, поднимать эмуляторы, выкачивать гигабайты сдк, и это все более-менее ручной процесс. В итоге вам все равно нужна экспертиза по мобильной разработке, иначе даже не начать. Но буквально неделю назад на React Conf представили аналог create-react-app для React Native: create-react-native-app. Для мобильного разработчика это конечно шок: как, мобильное приложение без приложения! Но для старта это пожалуй идеальный вариант: скрипт вам все сам настроит и поднимет, никаких сдк качать не надо, приложение можно сразу увидеть на телефоне.
— Чем вас так увлек React Native?
Владимир Иванов: Как разработчика, вау-эффект меня накрыл от того, что подход к разработке мобильного приложения, UI целиком другой. В Android, iOS вы сталкиваетесь с императивным программированием, то есть «Эй ты, сделай это, скрой кнопочку, вот здесь помигай» — ты отдаешь команды UI, что ему делать. А в React Native подход совсем другой, нужно немножко поломать себе мозг, чтобы на него перейти. Это полная смена модели разработки, она меня приятно шокировала.
Я думаю, вся индустрия начнет в ближайшее время мигрировать на эти инструменты, потому что они реально хорошие. Тем более, что React Native – это опенсорсное решение, вокруг которого активно формируется крутое сообщество. Вот UberEats опубликовали, как они использовали React Native в своих продуктах, они и пишут: не беремся утверждать, что пуля серебряная, но нам отлично подошла.
О том, как в React Native создавать полноценные коммерческие проекты, Владимир Иванов расскажет в докладе «React Native: Уроки выживания» на конференции Mobius, которая состоится 21-22 апреля 2017 года в Санкт-Петербурге.