Инструменты 27/10/2022

Почему реклама сыграла с React Native злую шутку: преимущества и недостатки фреймворка

iOS Developer в NIX

Название статьи провокативно, и в этом кроется маленькая хитрость. Ответ на этот вопрос, как мне кажется, неочевиден. Попробуем разобраться вместе.

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

Для начала расскажу краткую историю возникновения React Native. Это позволит вам понять, почему фреймворк был создан именно так, как мы видим. Пройдемся по принципам его работы, преимуществам и недостаткам. Отдельно я упомяну мифы о React Native, распространенные среди разработчиков, аналитиков и заказчиков.

Facebook взялись за разработку еще в 2010 году…

Через год стартовый проект превратился в FaxJS, а затем трансформировался в React и стал опенсорсным. Зачем вообще понадобился React?

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

В начале 2010-х Facebook захотел основательно выйти на рынок мобильных приложений. Сначала компания выбрала для этого HTML5 и WebView.

Позже в своих интервью Марк Цукерберг назвал это решение самым худшим за годы существования Facebook.

При использовании WebView возникло немало проблем:

Отсутствует киборд API. Это существенное препятствие для разработки.

Нет корректного способа хендлина тачей и жестов. В WebView не хватало кода для обработки мультижестов. Любые onClick-события медленнее нативных событий.
Отсутствует управление изображениями. В отличие от браузеров, в мобильных браузерах кэш не позволял узнать, загружено ли изображение.

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

Но у Native было несколько критических для Facebook недостатков:

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

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

В результате девелоперы Джордан Волкер и Кристофер Чедо реализовали возможность генерации нативных UI-элементов из JS-очереди. Это явилось предпосылкой создания React Native. В 2013 году на хакатоне в Facebook разработчики показали первую версию. Дебют полноценного React Native состоялся в 2015 году. Через несколько месяцев его уже поддерживали iOS, Android, Windows Mobile и Tizen.

Learn Once, Write Anywhere — стало лозунгом React Native. Так начали привлекать внимание веб-разработчиков по всему миру к мобайл-разработке.

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

Как устроен React Native

Он похож на React, но вместо веб-компонентов использует нативные. Некоторые могут подумать: раз знаешь React, то разберешься и с React Native. Но недостаточно разбираться в первом, чтобы свободно программировать на React Native. Так что углубляемся дальше…

React Native состоит из следующих компонентов:

Yoga framework
JavaScript Virtual Machine
Native ModulesBridge

Yoga framework

Yoga framework — это кроссплатформенный UI-двигатель, написанный на С++. Его главная задача — стандартизировать UI, чтобы независимо от платформы код был одинаков.

Благодаря этому UI у React Native полностью нативен. Вся система работает на флексбоксах. Впрочем, этот двигатель не имплементирует весь функционал CSS Flexbox. К примеру, в нем отсутствуют non-layout свойства, отвечающие за цвет.

Хотя Yoga — часть React Native, он может существовать и использоваться отдельно. С этим поможет YogaKit для нативной разработки. Подробнее советую почитать по этой ссылке.

Хочу упомянуть и крутой плейграунд на сайте Yoga. С его помощью вы можете изменять разные блоки и параметры и лучше разобраться, как все работает. Например, изменить расположение элементов с горизонтального на вертикальное и убрать падинги.

Виртуальная машина JavaScript

В разных статьях о React Native можно встретить множество названий этого компонента: JavaScript Virtual Machine, JSVM, JavaScript Engine, JavaScripCore. Он обрабатывает JS-код, благодаря чему удается запускать его на разных платформах.

Но есть один аспект. JavaScripCore также двигатель для браузера Safari. В iOS-приложениях по причине безопасности JavaScripCore не отрабатывает JIT-компиляцию (Just-in-Time). Так происходит, потому что Apple не позволяет запускать какие-либо third-party процессы, выполняющие динамический код.

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

Bridge

Этот элемент едва ли не стратегический объект в React Native. Я люблю шутить, что Bridge — как инь и ян или Альфа и Омега всего фреймворка. Он позволяет нивелировать препятствия между нативной и JS-частью кода.

Если следовать официальной документации, то Bridge дает возможность двунаправленного асинхронного неблокирующего общения между очередями.

Чтобы понять принципы работы Bridge, взглянем на схему. Здесь изображен базовый уровень без дополнительных интерпретаций:

Bridge — некий мост, по которому файлы JSON ходят из JS-очереди в нативную.
В потоке JS Thread работает JSVM, как раз JavaScript Runtime.
С другой стороны, в текущей реализации React Native есть три очереди: Main Thread, Shadow Thread и Native Modules.
Main Thread — основной поток, в котором выполняется код, связанный с UI-частью.
Shadow Thread — место расположения Yoga framework. Здесь происходят калькуляции лейаута и передача параметров в основную очередь, где и проходит рендеринг.
Native Modules могут создавать свои очереди при необходимости.

Из-за асинхронности и двунаправленности Bridge — как сильная, так и слабая сторона текущей архитектуры React Native. До определенного момента это позволяет держать хороший перформанс. А если же сменить коммуникацию с асинхронной на синхронную, то будут блокироваться даже незначительные операции, требующие обратной связи.

Например, при нажатии на кнопку поток будет блокироваться до тех пор, пока не получит коллбек из UI-части в JS для дальнейшей обработки. В этом и заключается компромиссная гениальность решения из Bridge.

Предлагаю разобрать еще одну схему. На ней изображены три блока: Native, Bridge и JavaScript. Это тоже самое, но с другой интерпретацией.

Представьте, что пользователь нажимает на экран гаджета. В нативном блоке создается ивент, превращающийся в определенный payload и попадающий в Bridge. Тот со своей стороны отправляет payload в JS-часть. Она все это процессует, чтобы потом вызвать определенные методы внутри JS-кода. В результате запускается обратный процесс, приводящий к обновлению UI. В обоих направлениях все проходит через Bridge.

На следующей иллюстрации — типичный JSON, ходящий через «мостик».

Хочу отметить один немаловажный момент. Текущая архитектура React Native… устаревшая. Так, еще в 2018 году было объявлено о перестройке фреймворка. Новая версия вышла в начале 2022-го, но пока сыровата для продакшена. Ее можно всячески испытывать в тестовом режиме и на pet-проектах. Прошлая архитектура работает по следующей схеме:

Обратите внимание на Bridge с его двунаправленными стрелками. Так обозначено соединение нативной и JS-части кода.

А здесь уже приведена новая архитектура, над которой разработчики работали 4 года. Есть несколько перемен и главная — нет Bridge! Его место занимает JavaScript Interface.

Это абстрактный лейер для JavaScript Runtime. Если Вы знакомы со Swift или TypeScript, то JSI можно воспринять как обычный протокол. При его реализации нативные объекты будут доступны по JS-коду.

Например, если у вас есть UI View, доступ к этому нативному компоненту будет иметь без мостов. При этом механизм работает в рантайме. То есть глобальный скоуп JavaScript будет сохранять ссылку на нативный элемент, и вы сможете вызвать методы напрямую из JS-кода.

Преимущества React Native

Декларативный UI

Наверное, каждый, кто работал с React Native или Swift UI, согласится: это удобный подход к написанию UI. Например, приведу фрагмент из моего тестового проекта. Это обычный Login-скин: с двумя текст-филдами и кнопками Login и SignUp. Фрагмент содержит небольшое количество кода. При этом нет указания, как создавать эти элементы или как они связаны между собой. То есть я не прописываю это кодом, что экономит усилие и время.

Hot Reloading

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

Code push

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

Stories & Storybook

Предоставляет возможность создавать библиотеки UI-компонентов (текст-филды, баттоны, свитчеры) и хранить их в любом хранилище. К веб-интерфейсу будут подтягиваться все созданные компоненты. И в нем же сможете интерактивно изменять их параметры. Полезно в случае будущих модификаций в дизайне продукта.

Большое сообщество пользователей React Native

Сегодня это самый популярный гитхабный репоз — у него 105 000 звездочек! Фактически развитие React Native держится именно на этом сообществе.

Недостатки React Native

Зависимость от сообщества

Комьюнити — как преимущество, так и недостаток этого фреймворка. Ведь его развитие достаточно хаотично. Я неоднократно встречал крутые UI-библиотеки, которые нельзя было использовать, потому что их последнее обновление было несколько лет назад. Такие моменты сильно удручают разработчика.

Это до сих пор бета-версия

Значительное ограничение, не позволяющее полностью быть уверенным в React Native. У фреймворка нет единого центра разработки, который бы держал процесс под контролем. Facebook апрувит перемены и иногда предлагает улучшение.

Необходимость вмешательства в нативный код

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

Перфоманс

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

Мифы о React Native

Facebook и Instagram написаны на React Native

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

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

Веб-разработчики быстро освоят React Native

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

В такие моменты разработчики понимают: React Native сильно отличается от React.

Конечно, знания React помогут относительно быстро научиться писать UI под React Native. И все остальное придется учить с нуля.

Два приложения по цене одного

Некоторые заказчики считают, что с React Native смогут едва ли не вдвое сэкономить на разработке приложений для разных ОС. Это почти невозможно. Иногда удается сэкономить. Но на бюджет проекта влияют особенности конкретного продукта, его функционала и процесса разработки. Например, если приложение небольшое, то использование React Native действительно ускорит работу. Сегодня большинство приложений сложны и объемны. Поэтому экономия не так уж существенна.

Крутый инструмент для MVP

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

Безусловно React Native — отличный инструмент, но для определенных задач. Вы можете забивать гвоздь отверткой, но зачем, когда есть молоток? Вы добьетесь цели, но будете страдать в процессе. Результат не оправдает ожиданий. Так же с React Native. Учите и практикуйте его возможности. Знания дают понимание, где целесообразнее использовать фреймворк.

Что касается вопроса в заголовке статьи, то здесь интересная ситуация. С одной стороны, маркетинговый ход привлек внимание к React Native. Вокруг него сформировалось мощное сообщество разработчиков, которое дало толчок для развития фреймворка. С другой же — маркетинг сыграл с ним злую шутку. Появилось немало мифов, мешающих правильно понимать возможности инструмента. А хитрость заголовка состоит в том, что он не дает альтернативы и ограничивает выбор только в отношении противоположных мнений. Хотя есть и третий ответ: выводы делайте сами 😉

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.