Название статьи провокативно, и в этом кроется маленькая хитрость. Ответ на этот вопрос, как мне кажется, неочевиден. Попробуем разобраться вместе.
Этот материал для тех, кто хочет иметь под рукой структурированную информацию о React Native и знать возможности этого инструмента.
Для начала расскажу краткую историю возникновения React Native. Это позволит вам понять, почему фреймворк был создан именно так, как мы видим. Пройдемся по принципам его работы, преимуществам и недостаткам. Отдельно я упомяну мифы о React Native, распространенные среди разработчиков, аналитиков и заказчиков.
Через год стартовый проект превратился в FaxJS, а затем трансформировался в React и стал опенсорсным. Зачем вообще понадобился React?
Как объясняли в Facebook, на тот момент их продукты было тяжело масштабировать. Поэтому работа над новыми фичами замедлилась, а выполнение кода с его каскадным обновлением и ререндерингом стало непредсказуемым. Разработчики уже не могли гарантировать, что обновление данных не приведет к ошибкам в разных частях приложения. Начали искать новое решение…
В начале 2010-х Facebook захотел основательно выйти на рынок мобильных приложений. Сначала компания выбрала для этого HTML5 и WebView.
Позже в своих интервью Марк Цукерберг назвал это решение самым худшим за годы существования Facebook.
При использовании WebView возникло немало проблем:
Разработчики убедились, что им нужны нативные приложения. Это может гарантировать хороший опыт пользователей.
Но у Native было несколько критических для Facebook недостатков:
В результате девелоперы Джордан Волкер и Кристофер Чедо реализовали возможность генерации нативных UI-элементов из JS-очереди. Это явилось предпосылкой создания React Native. В 2013 году на хакатоне в Facebook разработчики показали первую версию. Дебют полноценного React Native состоялся в 2015 году. Через несколько месяцев его уже поддерживали iOS, Android, Windows Mobile и Tizen.
Learn Once, Write Anywhere — стало лозунгом React Native. Так начали привлекать внимание веб-разработчиков по всему миру к мобайл-разработке.
React Native — это кроссплатформенный фреймворк. Тот, кто хорошо им владеет, может писать приложения под разные платформы. Хотя и здесь есть некоторые ограничения, о которых расскажу дальше.
Он похож на React, но вместо веб-компонентов использует нативные. Некоторые могут подумать: раз знаешь React, то разберешься и с React Native. Но недостаточно разбираться в первом, чтобы свободно программировать на React Native. Так что углубляемся дальше…
React Native состоит из следующих компонентов:
Yoga framework — это кроссплатформенный UI-двигатель, написанный на С++. Его главная задача — стандартизировать UI, чтобы независимо от платформы код был одинаков.
Благодаря этому UI у React Native полностью нативен. Вся система работает на флексбоксах. Впрочем, этот двигатель не имплементирует весь функционал CSS Flexbox. К примеру, в нем отсутствуют non-layout свойства, отвечающие за цвет.
Хотя Yoga — часть React Native, он может существовать и использоваться отдельно. С этим поможет YogaKit для нативной разработки. Подробнее советую почитать по этой ссылке.
Хочу упомянуть и крутой плейграунд на сайте Yoga. С его помощью вы можете изменять разные блоки и параметры и лучше разобраться, как все работает. Например, изменить расположение элементов с горизонтального на вертикальное и убрать падинги.
В разных статьях о React Native можно встретить множество названий этого компонента: JavaScript Virtual Machine, JSVM, JavaScript Engine, JavaScripCore. Он обрабатывает JS-код, благодаря чему удается запускать его на разных платформах.
Но есть один аспект. JavaScripCore также двигатель для браузера Safari. В iOS-приложениях по причине безопасности JavaScripCore не отрабатывает JIT-компиляцию (Just-in-Time). Так происходит, потому что Apple не позволяет запускать какие-либо third-party процессы, выполняющие динамический код.
Поэтому виртуальная машина работает в замедленном моде интерпретирования. Поэтому все проходит не совсем так, как должно быть. Причина кроется в конструкции JSVM. Он состоит из частей, отвечающих за парсинг, интерпретацию и т.п.
Этот элемент едва ли не стратегический объект в React Native. Я люблю шутить, что Bridge — как инь и ян или Альфа и Омега всего фреймворка. Он позволяет нивелировать препятствия между нативной и JS-частью кода.
Если следовать официальной документации, то Bridge дает возможность двунаправленного асинхронного неблокирующего общения между очередями.
Чтобы понять принципы работы Bridge, взглянем на схему. Здесь изображен базовый уровень без дополнительных интерпретаций:
Из-за асинхронности и двунаправленности 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 или Swift UI, согласится: это удобный подход к написанию UI. Например, приведу фрагмент из моего тестового проекта. Это обычный Login-скин: с двумя текст-филдами и кнопками Login и SignUp. Фрагмент содержит небольшое количество кода. При этом нет указания, как создавать эти элементы или как они связаны между собой. То есть я не прописываю это кодом, что экономит усилие и время.
Дает возможность вносить изменения в код, которые мгновенно отображаются на девайсе или симуляторе без рекомпиляции измененных файлов.
Этот облачный сервис позволяет развертывать обновления приложений непосредственно на устройствах пользователей без прохождения ревью. Правда, это оправдано только при изменениях в JS. При обновлении нативного кода ревью все же потребуется. Также можно сделать rollback к предыдущей версии.
Предоставляет возможность создавать библиотеки UI-компонентов (текст-филды, баттоны, свитчеры) и хранить их в любом хранилище. К веб-интерфейсу будут подтягиваться все созданные компоненты. И в нем же сможете интерактивно изменять их параметры. Полезно в случае будущих модификаций в дизайне продукта.
Сегодня это самый популярный гитхабный репоз — у него 105 000 звездочек! Фактически развитие React Native держится именно на этом сообществе.
Комьюнити — как преимущество, так и недостаток этого фреймворка. Ведь его развитие достаточно хаотично. Я неоднократно встречал крутые UI-библиотеки, которые нельзя было использовать, потому что их последнее обновление было несколько лет назад. Такие моменты сильно удручают разработчика.
Значительное ограничение, не позволяющее полностью быть уверенным в React Native. У фреймворка нет единого центра разработки, который бы держал процесс под контролем. Facebook апрувит перемены и иногда предлагает улучшение.
Может, для кого-то это дополнительный плюс, но помните: React Native представляется как простой переход от веб-разработки к мобильной. Поэтому веб-разработчики могут воспринять работу с нативной частью с большой досадой.
Продуктивность React Native на достаточном уровне. Но со специфическими задачами могут возникнуть проблемы. У меня уже был опыт проектов со сложной обработкой видео, где React Native совсем не справился.
Это очень успешный маркетинговый ход. Он привлекает много интереса к инструменту. Ведь у разработчиков вроде бы есть возможность работать с фреймворком, на котором созданы такие мощные приложения.
На самом деле разработчики Facebook и Instagram когда-то создали на React Native только отдельные модули. Они до сих пор есть в приложениях, но это React Native, интегрированный в нативную среду.
Как правило, все зависит от навыков конкретного специалиста. У фреймворка много понятных для веб-разработчиков элементов и принципов, но когда-то все равно придется работать с нативной частью.
В такие моменты разработчики понимают: React Native сильно отличается от React.
Конечно, знания React помогут относительно быстро научиться писать UI под React Native. И все остальное придется учить с нуля.
Некоторые заказчики считают, что с React Native смогут едва ли не вдвое сэкономить на разработке приложений для разных ОС. Это почти невозможно. Иногда удается сэкономить. Но на бюджет проекта влияют особенности конкретного продукта, его функционала и процесса разработки. Например, если приложение небольшое, то использование React Native действительно ускорит работу. Сегодня большинство приложений сложны и объемны. Поэтому экономия не так уж существенна.
Создать MVP с помощью React Native — почему бы нет? Спешу вас предостеречь. При разработке прототипа должен быть подробный роадмап приложения с перечнем запланированного функционала. Если такого списка нет, впоследствии могут быть добавлены фичи, которые проблематично реализовать через React Native. Придется тратить много времени, чтобы все поправить. Надеюсь, что с новой архитектурой фреймворка эта ситуация изменится.
Безусловно React Native — отличный инструмент, но для определенных задач. Вы можете забивать гвоздь отверткой, но зачем, когда есть молоток? Вы добьетесь цели, но будете страдать в процессе. Результат не оправдает ожиданий. Так же с React Native. Учите и практикуйте его возможности. Знания дают понимание, где целесообразнее использовать фреймворк.
Что касается вопроса в заголовке статьи, то здесь интересная ситуация. С одной стороны, маркетинговый ход привлек внимание к React Native. Вокруг него сформировалось мощное сообщество разработчиков, которое дало толчок для развития фреймворка. С другой же — маркетинг сыграл с ним злую шутку. Появилось немало мифов, мешающих правильно понимать возможности инструмента. А хитрость заголовка состоит в том, что он не дает альтернативы и ограничивает выбор только в отношении противоположных мнений. Хотя есть и третий ответ: выводы делайте сами 😉
If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…
