(После постов от airbnb, в которых они отказались от RN, фейсбук выкатил пост в котором обрисовал текущую ситуацию. Этот перевод поможет вам лучше понять, стоит ли использовать react native в 2018м году)
Прошло некоторое время с тех пор, как мы в последний раз опубликовали информацию об статусе React Native.
В Facebook мы используем React Native больше, чем когда-либо, во многих важных проектах.
Одним из наших самых популярных продуктов является Marketplace, одной из вкладок верхнего уровня которого каждый месяц пользуется 800 миллионов человек. С момента создания в 2015м году, все Marketplace были построены при помощи React Native, включая более сотни полноэкранных view в разных частях приложения. (
Мы также используем React Native для большинства новых частей приложения. Если вы смотрели F8 keynote в прошлом месяце, вы узнали о Blood Donations, Crisis Response, Privacy Shortcuts и Wellness Checks — словом, обо всех новых фичах, созданных с React Native.
На проектах за пределами основного приложения Facebook также используется React Native. Новый шлем виртуальной реальности Oculus Go VR включает «в качестве компаньона» мобильное приложение, которое полностью написано на React Native, не говоря уже о React VR «дающем жизнь» многим функциям в самом устройстве.
Естественно, мы также применяем и многие другие технологии. Litho и ComponentKit — библиотеки, которыми мы активно пользуемся в наших приложениях; обе предоставляют React-подобный компонентный API для создания нативных экранов (native screens).
Перед React Native никогда не стояло задачи заменить собой все другие технологии — мы ориентируемся на то, чтобы сделать React Native лучше, но нам нравится наблюдать, как другие команды берут идеи React Native, например, [мгновенную перезагрузку] кода без JavaScript.
Архитектура
Когда мы начинали проект React Native в 2013 году, мы разрабатывали его, чтобы иметь единый «мост» между JavaScript и native, который был бы асинхронным, сериализуемым и «batched» (пакетным).
Подобно тому, как React DOM превращает обновления состояния (state) React в императивные, мутированные вызовы DOM API, например как, document.createElement(attrs) и .appendChild(), React Native был разработан для возврата одного сообщения JSON, в котором перечислены мутации для выполнения, например [["createView", attrs], ["manageChildren", ...]].
Мы разработали полноценную систему, чтобы никогда не полагаться на получение синхронного ответа и гарантировать, что все в этом списке может быть полностью сериализовано в JSON и обратно. Мы сделали это для гибкости, что дало нам возможность создать такие инструменты, как отладка Chrome, асинхронно запускающая весь код JavaScript через соединение WebSocket.
За последние 5 лет мы обнаружили, что эти изначальные принципы сделали разработку новых «фич» сложнее.
Асинхронный мост (asynchronous bridge) подразумевает, что вы не можете интегрировать JavaScript-логику напрямую со многими нативными API, ожидающими синхронных ответов.
Пакетный мост (Batched Bridge), который ставит в очередь нативные вызовы, означает, что будет сложнее использовать приложения React Native для функций, которые были реализованы ранее.
Сериализуемый мост (serializable bridge) привносит ненужное копирование вместо прямого обмена памятью между двумя мирами.
Для приложений, которые полностью собраны на React Native, эти ограничения обычно терпимы. Но для приложений со сложной интеграцией между React Native и существующим кодом приложения — нет.
Мы работаем над крупномасштабной архитектурой React Native, чтобы сделать фреймворк более гибким, удобным, чтобы он лучше интегрировался с нативной инфраструктурой в гибридных JavaScript/нативных приложениях. Мы применим то, чему мы научились за последние 5 лет, и постепенно сделаем нашу архитектуру более современной.
Мы переписываем многие «внутренности» React Native, но большинство изменений находятся под капотом: существующие приложения React Native будут продолжать работать с небольшими изменениями или без изменений.
Чтобы сделать React Native более легким и лучше вписываться в существующие нативные приложения, предлагается три основных внутренних изменения в архитектуре.
Во-первых, мы меняем модель потоковой передачи. Вместо обновления каждого пользовательского интерфейса, необходимого для работы над тремя разными потоками, можно будет делать синхронные вызовы на JavaScript на любом потоке для высокоприоритетных обновлений, сохраняя при этом работу с низким приоритетом основного потока, чтобы поддерживать ответную реакцию.
Во-вторых, мы включаем асинхронный рендер возможностей в React Native, чтобы позволить множественный рендер первоочередных задач и упростить асинхронную обработку данных.
Наконец, мы упрощаем наш мост, чтобы сделать его более быстрым и легким; прямые вызовы между native и JavaScript более эффективны и упрощают создание технологий дебаггинга вроде кросс-языковых трассировок стека (cross-language stack traces).
Как только эти изменения будут завершены, возможна более тесная интеграция. Сегодня без сложных хаков невозможна интеграция нативной навигации и обработки жестов или нативных компонентов, как UICollectionView и RecyclerView. После наших изменений в модели потоковой обработки подобные функции будут доступны. Более подробную информацию об этой работе мы опубликуем ближе к ее завершению в конце года.
Сообщество
Наряду с сообществом в Facebook мы рады, что у нас есть процветающая популяция пользователей React Native и участников вне Facebook. Мы хотели бы больше поддерживать сообщество React Native, как для более эффективного использования React Native, так и для облегчения разработки самого проекта.
Так же, как наши изменения в архитектуре помогут React Native взаимодействовать более ясно с другой нативной инфраструктурой, так и React Native должен быть более «изящным» на стороне JavaScript, чтобы лучше сочетаться с экосистемой JavaScript, что включает в себя возможность замены VM (виртуальной машины) и bundler (сборщика). Мы знаем, что может быть сложно «идти в ногу» с темпами критических изменений, поэтому мы хотели бы найти способы, чтобы иметь меньше «мажорных» (основных) релизов. Наконец, мы знаем, что некоторые команды ищут более подробную документацию по таким темам, как оптимизация первоначальной загрузки, где наш опыт еще не столь богат. Ожидайте релиза некоторых из этих изменений в течение следующего года.
Если вы используете React Native, вы — часть нашего сообщества. Продолжайте, пожалуйста, давать нам ревью, как мы можем улучшить React Native для вас.
React Native — это всего лишь один инструмент в обойме инструментов для мобильных разработчиков, но один из тех, в который мы очень верим — и мы улучшаем его каждый день, с более чем 2500 коммитами за последний год от 500 контрибуторов.
Перевод: freemasons
Оригинал: запись в блогe React Native
