React в браузерах и на мобильных платформах

789c6413b98a4575a0b720d4d7fec476.png

Этот пост написан по материалам выступления Григория Петрова из компании VoxImplant на партнёрской конференции »1С-Битрикс».

Вообще говоря, наша компания Voximplant занимается созданием решений для облачной голосовой телефонии. Но на страницах этого поста я хотел бы поговорить не об этом, а о некоторых перспективных технологиях. Так получилось, что уже больше 15 лет я делаю софт, как самостоятельно, так и в роли руководителя команд разработчиков и консультанта.

За последние несколько лет индустрия создания программного обеспечения развивается просто безумными темпами. И особенно хорошо это видно на примере близких нам веб-технологий, к которым относятся все продукты »1С-Битрикс». И одним из направлений развития является перенос на мобильные платформы, с внедрением адаптивной вёрстки и многого другого хорошего и интересного. Технологии сменяют друг друга примерно раз в три месяца. Здесь же я расскажу об использовании технологии React, которая сейчас представлена в двух ипостасях: React.js и React Native.

История возникновения


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

Итак, в Facebook создали React.js — технологию, которая была призвана решить проблему с чатом. Сделать это предполагалось с помощью трёх волшебных фич:

  • Во-первых, изменение интерфейса без перерисовки. Как вы знаете, интерфейс у Facebook довольно развесистый. Там много всяких фидов и окошек, чат может появляться в трёх разных местах. В админской панели много разнообразных разделов. И всё это скролится, появляется и исчезает, выскакивают нотификации и лайки.

    Но у браузеров есть одна маленькая проблема. Они были разработаны много-много лет назад, чтобы отображать простенькую страничку: текст, заголовок, выделенный текст. Как и HTML, браузеры совершенно не были предназначены для отображения сложных интерфейсов наподобие Facebook. Например, если пользователь что-то набирает в чате, переключается на новостную ленту, а потом обратно на чат, то пропадут фокус и текущая позиция набора.

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

  • Во-вторых, у инженеров Facebook была такая мечта. Точнее, эту мечту разделяют все разработчики за последние лет 30: сделать так, чтобы можно было один раз запрограммировать кнопку для чата, а потом использовать её везде, во всех своих программах. Поэтому авторы React сказали: «Ок. Мы делаем React таким образом, что вы один раз дизайните окно чата, а затем вставляете его везде, где хотите. И у вас всё будет работать». Не работает, конечно, но попытка очень и очень хорошая.
  • Наконец, последнее, что сделали инженеры Facebook — это контроль состояний. Когда вы делаете огромную, сложную систему уровня «Битрикс24», то у вас миллион каких-то кнопочек, рычажков, pop-ap«ов, окошек. Всё это прыгает, скролится, работает. Поэтому элементы программы могут иметь очень много состояний: чат поскролен туда, чат поскролен сюда, есть сообщения или их нет, залогинен пользователь или не залогинен. Чем больше система, тем больше этих состояний, тем больше возникает неожиданных комбинаций. И в результате программа может вести себя довольно странно. Например, как чат Facebook. В React используется функциональная парадигма: он позволяет делать маленькие компоненты, даём на вход некое состояние, на основании которого они и работают.

Когда какая-нибудь компания разрабатывает новую технологию, то не знает, взлетит эта технология или нет. Или взлетит лишь часть этой технологии? Обычно угадать не получается. Facebook сначала опробовал React на чате, им понравилось, после чего код React был открыт сообществу разработчиков. Маркетологи и инженеры компании делали упор на скорость работы новинки, что обеспечивается перерисовкой маленьких кусочков страниц. Но как показала практика, это свойство оказалась мало кому нужно.

Зато программистам больше всего пришлось по вкусу то, что интерфейс собирается из небольших компонентов. До React веб-программирование представляло собой «варку лапши», когда разрабатывают сложную систему из огромного HTML и вдвое более крупного CSS, приправленную горами JavaScript.

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

Это свойство обеспечило взрывной успех React.js. Сейчас в интернете тысячи статей, посвящённых использованию этого инструмента. React.js сегодня в большой моде, на него переходят крупные компании, потому что он позволяет программистам избавиться от огромной боли «лапши» в своём коде.

React Native


Всё это время Facebook сидел в засаде. И через два года после выпуска своей разработки они заявили: «Знаете, нам так понравился React.js, что теперь мы будем делать на нём также и мобильные приложения». И выкатили React.js для iPhone, а ещё через полгода — для Android.

Это было неожиданно. Как можно технологию для создания веб-интерфейса, да ещё на JavaScript, использовать на мобильных платформах? Facebook подошёл к этому с выдумкой, использовав наработки проекта Appcelerator Titanium. Он создавался несколько лет назад, но не обрёл большой популярности. Зато все сразу стали пользоваться React Native.

Что такое React Native? Когда мы делаем веб-сайт с пользовательским интерфейсом, то всё достаточно просто. У нас есть HTML, DIV, INPUT, BUTTON. Есть дизайнер, который их раскрашивает во всякие забавные цвета, и мы всем этим пользуемся.

Но при создании приложения для мобильных платформ у нас есть отдельно Android и iOS, в которых куча своего пользовательского интерфейса. Кнопки, input«ы и drawer на Android работают не совсем так, как на iPhone. Поэтому, когда вы создаёте мобильное приложение, то можете пойти другим путём: внедрить в приложение кусочек браузера и рисовать привычный HTML.

Так делает, например, популярный PhoneGap. Преимущество этого подхода в том, что приложение выглядит совершенно одинаково на всех устройствах. Недостаток: оно выглядит одинаково уродливо. Потому что пользователи Android и iOS привыкли к характерному виду элементов интерфейса, к их красивой анимации кнопочки. И когда они видят вашу веб-страничку, запакованную в виде приложения, то немного удивляются.

Есть и третий путь: можно для каждой платформы делать свой собственный интерфейс, используя «родные», нативные элементы. Так делалось ещё в Appcelerator Titanium за много лет до появления React Native. Собственно, слово Native в названии как бы подразумевает, что мобильное приложение, использующее React, будет использовать кнопочки, текстовые поля, input«ы и все остальные элементы, характерные для данной операционной системы.

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


Работает всё это очень просто. Универсальное приложение, которое должно работать как веб-страничка на Android и iPhone, состоит из JavaScript-кода. Он отвечает за бизнес-логику: что должно делать приложение, когда пользователь нажал кнопку «Купить», как отображать элементы приложения, и т.д. Этот код одинаков для всех платформ. А код, отвечающий за пользовательский интерфейс, — то, что делает React, — разный для каждой из платформ.

7523f469338848ab97e07d186dfc85bc.jpg

React позволяет делать приложение на JavaScript, внутри которого создаются виджеты в синтаксисе XML. Выглядит это примерно вот так.

Браузер iOS Android
Общий код на JS Общий код на JS Общий код на JS

Когда вы делаете веб-приложение, то у вас есть свои виджеты, например, DIV, INPUT, BUTTON. При создании Android-приложения виджеты будут совсем другими: Android Button, Drawer«ы, Activity. Для приложения под iPhone у вас будет третий набор виджетов.

В этом и преимущество, и недостаток React. Если в вашем приложении много бизнес-логики, то основная масса кода будет совершенно одинаковой для всех трёх платформ — веба, Android и iOS. Если же приложение представляет собой пользовательский интерфейс к базе данных, то и код по большей части будет отличаться.

Многие компании, пытаясь «продать» средство кроссплатформенной разработки, обычно рассказывают истории из серии «Посмотрите, как замечательно! Мы сделали текст «Hello, world!», поле ввода, кнопочку, и оно совершенно одинаково выглядит под двадцатью платформами, и всё работает».

Но на практике мало кому нужно делать столь примитивные программы. Обычно приложения создаются для того, чтобы зарабатывать деньги и решать бизнес-задачи, так что они получаются гораздо сложнее. Иногда очень-очень сложнее. Поэтому уместно будет спросить: «Ребята, ок. А если мы попытаемся сделать приложение, где будет 50 кнопок, сотни input«ов и два десятка окошек, как это себя поведёт?».

В отличие от остальных кроссплатформенных решений, React поведёт себя хорошо. Во-первых, доступно очень большое количество компонентов для веба. Если вы используете React.js для создания приложения и хотите, чтобы оно отображалось как веб-страничка, то можете использовать готовые наборы блоков. Например, сейчас очень популярен Google Material Design. Вы просто берёте горизонтальный и вертикальный layout«ы, кнопки, поля ввода, и всё это выглядит так же красиво, как Bootstrap, но при этом не надо ничего верстать. Словно собираете кирпичики Lego.

Огромное количество компаний и энтузиастов постоянно создают новые библиотеки и пользовательские интерфейсы для React Native. Например, у Facebook на GitHub есть небольшой набор для создания приложений, которые должны работать на Android и iOS. В поисковиках вы сразу найдёте карты, биллинг, базы данных, сетки, огромное количество портированных компонентов. Правда, часть из них не работает, но это open source, очень перспективные технологии.

И наконец, многие компании делают универсальные решения, которые вы можете использовать с React как в вебе, так и на мобильных платформах. Например, если вы пользуетесь телефонией Voximplant, то можете применять наш SDK как в веб-приложениях, так и в мобильных. Скажем, реализуете приложение на React для веба, Android и iOS, при этом наш SDK также позволяет звонить или принимать звонки на этих платформах. Таким образом, ваши веб-разработчики пишут один и тот же код, а получается три разных решения.

Недостатки


Конечно, не всё так радужно. Помимо множества достоинств, у React.js и React Native есть и немного недостатков.

Самый большой из них — если вы хотите использовать React на мобильной платформе, то у вас будут нативные виджеты. Это сильно ускоряет разработку, интерфейс выглядит привычно, но вашим программистам придётся это учить. То есть взять толстый талмуд по разработке приложения под Android и посмотреть, какие элементы пользовательского интерфейса там есть, как они взаимосвязаны друг с другом, как этим всем пользоваться и правильно собирать. И когда те же разработчики попробуют сделать приложение для iOS, то придется взять ещё больший талмуд от Apple и проштудировать, чтобы результат выглядел как нормальное приложение. Это, безусловно, занимает время.

Ещё один недостаток заключается в том, что при использовании React для веба он вам не даёт вообще ничего. Вот DIV«ы, верстайте сами. Для мобильных платформ из коробки доступно порядка трёх десятков виджетов, хотя у каждой из них намного больше элементов пользовательского интерфейса, под сотню. И если вы хотите использовать что-то помимо маленького стандартного набора, то придётся либо идти на GitHub и набираться идей, либо писать самостоятельно на низкоуровневом языке вроде Java или Objective-C.

Третий недостаток связан с молодостью проекта React Native. Это пока очень сырая технология, которую пока не успели довести до ума, в отличие от React.js. Конечно, проект развивается, Facebook постоянно что-то чинит, иногда что-то ломает. И если вы хотите использовать эту технологию, то будьте готовы к тому, что у ваших разработчиков иногда что-то не будет получаться, и чтобы это починить, они будут много времени проводить на Stackoverflow.

React и Angular


В интернете много статей, в которых сравнивают эти две технологии. Angular — это большой полноценный framework, заточенный для создания веб-сайтов. Сейчас делают попытки перенести Angular на мобильные платформы, как и React Native, но это пока эксперименты.

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

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

Выводы


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

Комментарии (2)

  • 18 июля 2016 в 10:52 (комментарий был изменён)

    +2

    Недостатки

    Конечно, не всё так радужно. Помимо множества достоинств, у React.js и React Native есть и немного недостатков.

    Самый большой из них — если вы хотите использовать React на мобильной платформе, то у вас будут нативные виджеты. Это сильно ускоряет разработку, интерфейс выглядит привычно, но вашим программистам придётся это учить. То есть взять толстый талмуд по разработке приложения под Android и посмотреть, какие элементы пользовательского интерфейса там есть, как они взаимосвязаны друг с другом, как этим всем пользоваться и правильно собирать. И когда те же разработчики попробуют сделать приложение для iOS, то придется взять ещё больший талмуд от Apple и проштудировать, чтобы результат выглядел как нормальное приложение. Это, безусловно, занимает время.

    Ещё один недостаток заключается в том, что при использовании React для веба он вам не даёт вообще ничего. Вот DIV«ы, верстайте сами. Для мобильных платформ из коробки доступно порядка трёх десятков виджетов, хотя у каждой из них намного больше элементов пользовательского интерфейса, под сотню. И если вы хотите использовать что-то помимо маленького стандартного набора, то придётся либо идти на GitHub и набираться идей, либо писать самостоятельно на низкоуровневом языке вроде Java или Objective-C.

    Третий недостаток связан с молодостью проекта React Native. Это пока очень сырая технология, которую пока не успели довести до ума, в отличие от React.js. Конечно, проект развивается, Facebook постоянно что-то чинит, иногда что-то ломает. И если вы хотите использовать эту технологию, то будьте готовы к тому, что у ваших разработчиков иногда что-то не будет получаться, и чтобы это починить, они будут много времени проводить на Stackoverflow.

    The best)

    • 18 июля 2016 в 11:03

      +3

      Я думаю, что The Best находится чуть ниже)
      Если ваш бизнес заключается в конвейерном создании не очень сложных веб-сайтов, то Angular подойдёт идеально. Его главное преимущество в том, что он всё умеет делать из коробки. При этом шаг влево-шаг вправо рассматривается как попытка взлететь. Едва вы пытаетесь сделать что-то, что не очень хорошо укладывается в рельсы Angular, то будете тратить в пять раз больше времени.

© Habrahabr.ru