Как стать автором
Обновить

Комментарии 24

Я бы не стал так обобщать. Реакт очень удобен для создания мелочей вроде мобильного клиента какого-либо сайта, плюс с минимальным количеством нативного кода можно неплохой функционал реализовать, так какой смысл писать полностью нативное приложение с тем же функционалом? Как пример — работа с bluetooth, конечно, ради нее можно все приложение писать дважды — под андроид и яблоко, а можно набросать шаблон на реакте, а само взаимодействие с bluetooth реализовать в виде небольшой подключаемой нативной либы, чем плох подобный подход?

если приложение простое — то верстка двух окон займет меньше времени, чем сборка либы и настройка мультиплатформенного приложения.
если приложение сложное — больше времени займет подгон отображения под единый вид и борьба с багами на платформах.
Я не спорю с вами, вы по-своему правы, однако скажу по себе — мне для описания интерфейса гораздо проще использовать универсальные инструменты для разметки и потом отловить пару багов на конкретной платформе, чем осваивать разметку под IOS и под Android отдельно, плюс опять же — если писать для каждой платформы полностью нативное приложение — это растягивает процесс разработки. Как по мне — этот холивар бессмысленнен, каждый выбирает те инструменты, которые ему удобней в данной конкретной ситуации и не более)
Возможно. Я в сумме потратил по паре месяцев на каждую платформу для изучения специфики верстки. Те же констреинты это большой плюс, а не минус — их как раз и ввели для быстродействия и уменьшения кол-ва элементов на экране. Однозначно это те вещи, которые нужно изучить, если хочешь писать эффективные программы.
Я еще ни одного «сладкого хлеба» в разработке не встречал, за который не пришлось бы чем то расплачиваться. В РН это отлов багов, ограниченность средств разработки и общая нестабильность.
Так никто и не спорит что везде есть минусы, не бывает идеального инструмента, но для лентяев вроде меня РН в принципе неплохой вариант)
Разработка мобильных приложений как бизнес-задача может быть поставлена по принципу «у всех есть, нам тоже надо» или как проверка маркетинговой идеи, рабочий прототип: станет популярен, хотя бы сравним с количеством заходов на сацт с мобильных — начнём вылизывать, а нет -так закроем вообще. Тут заставлять того же фронтендера тратить несколько месяцев на освоение платформ или нанимать спеца или двух может оказаться не очень разумным ходом.
Кроилово всегда ведет к попадалову.
не подходит для проектов, выходящих за границу “отправил запрос — получил ответ”, немного примеров: фоторедактор, плеер, работа с Bluetooth, AI, ML, соц. сеть, мессенджер;

На ReactNative еще не писал. Почему не подходит для плееров? Объясните подробнее, пожалуйста.
Потому что для взаимодействия с тем же системным декодером нужна нативная либа под конкретную платформу, а реакт ее не предоставляет. Хотя есть способы написать нативную либу и обернуть ее в модуль под React Native, но смысл такого действия сомнительный — все равно вы по сути пишете один и тот же функционал под разные платформы. Тут надо скорее смотреть на конкретный сценарий использования инструмента. Если вы пишете один условный плеер, то вам нет разницы на чем писать — в любом случае будете под каждую платформу большую часть функционала реализовывать нативными средствами. Но если у вас фирма, которая пишет условные плееры на заказ, тогда вам имеет смысл оформить базовый функционал в виде модулей под реакт для последующего использования)
Правильно ли я понимаю, что нужно написать две нативные либы для работы со звуком и обернуть их? Таким образом, в данной ситуации выгода использования ReactNative – это общий код UI и бизнес логики, верно?
Ну типо того, плюс набор багов на каждой конкретной платформе, которые надо фиксить
Полтора месяца разрабатывал на RN. Нерешенные на сегодняшний день проблемы:
  • никакущая стабильность.Заставить приложение не падать — большой квест, особенно когда у тебя больше 5 экранов. Обновление версии языка — игра в русскую рулетку.
  • сборка. Добавляешь одну либу — тянется десяток зависимостей — перестает собираться вообще все. Начинаешь выставлять зависимости — обнаруживаешь, что либы ссылаются на самые нестабильные ветки — беты, эксперименталы и пр. Запускаешь билд на другой платформе (скажем, тестировал на иос, собираешь андроид) — повторяешь квест. И так можно до бесконечности
  • само по себе наличие библиотек в бете (впрочем, как и самого языка) — отсутствие гарантий в разработке релизных продуктов
  • графические артефакты и уникальные для платформы фичи. Сколько бы разговоров о мультиплатформе не было, текстовые поля отображаются по разному, в отрисовке теней вечно возникают артефакты. Верстать что-то простое можно, но ни об идентичности, ни о сколько-нибудь приемлемом виде верстки из коробки для сложных приложений речь даже не идет.
  • отсутствие нормальной связки с железом и особенностями оси. Да, все можно прикрутить в качестве либ, но тогда теряется время разработки, ухудшается стабильность. В итоге выйгрыша в сравнении с нативной разработкой уже нет.
никакущая стабильность.Заставить приложение не падать — большой квест, особенно когда у тебя больше 5 экранов. Обновление версии языка — игра в русскую рулетку.

Не могу согласиться. Бывают проблемы на этапе сборки, но в рантайме, как правило, все хорошо. За последний месяц у нас 100% crash-free users. Экранов уже десятки.
NativeScript не рассматривали? Или, может, кто-нибудь может поделиться собственным опытом? Непросто найти отзывы о реальном применении в более-менее серьезных задачах.

Вопрос к тем, кто активно работал с React Native. Я читал, дескать, там неплохо реализована поддержка FlexBox. А как насчёт inline + inline-block? Для одного из проектов, которые моя контора планирует реализовать на RN это очень критично. Т.е. нужна удобная возможность иметь строчную и строчно-блочную вёрстку. Условно это когда содержимое одного <span/> может начинаться в произвольном месте одной строки, занять ещё 3, и на 5-ой закончиться где-нибудь в середине, и при этом в этом же контексте могут быть блочные элементы. В общем речь про display: inline & display: inline-block.


Ещё вопрос: а как там с поддержкой SVG? Есть сложные интерактивные графики функций, с drag-n-drop-ом, установкой точек на канве, и прочими штуками, которые не во всех браузерах поддерживаются.

В нем плохо реализована поддержка ВСЕГО. Язык до сих пор именно поэтому в бете.

У React Native огромное сообщество, которое постоянно растет и реализует различные библиотеки, в том числе подходящие под Ваши задачи. Первое, что приходит в голову, это рендерить html, например используя следующий компонент: https://github.com/jsdf/react-native-htmlview


Что касается SVG, то тут посложнее, но, думаю, найдется и что-то подобное. Опять-таки никто не мешает написать нативно и обернуть в JavaScript.

Спасибо за ссылку. Увы, в таком случае проще сразу взять WebView или весь проект писать на Cordova. HTML не годится. Нужна именно полноценная поддержка inline-layout-ов.

Я читал, дескать, там неплохо реализована поддержка FlexBox

Это не вполне так, за лейаут в RN отвечает yoga у которой нет цели реализовать спецификацию CSS flexbox. Он похож, но не совсем. Такого понятия как display: inline в нем не существует. Разве что заворачивать каждое слово в свой контейнер и ставить flex-wrap.

Ещё вопрос: а как там с поддержкой SVG?

Паршиво, из коробки нет даже базовой поддержки, только растр. Через либы можно вставлять иконки, а вот живые графики вряд ли. Canvas можно поставить через сторонние библиотеки, но непонятно насколько он хорошо будет работать.
Кордова еще не умерла? В одной конторе, где я работал разработчиком Xamarin, проект раньше был написан на Cordova, но код был отправлен в помойку и переписан на Xamarin

Просто недавно как раз увидел вопрос на тостере, там рекоменловал в тч такой вариант. Ну а по мануалам на офсайте всё, вроде бы, не сложно.

Cordova имеет еще больше ограничений, чем ReactNative. И хуже производительность. Там же WebView под капотом. А по мануалам на оф.сайте — так это любой фреймворк прекрасен!

Для мобильного с Vue есть смысл попробовать nativescript-vue, если хочется именно приложение.
Либо делать на нём PWA, которое будет работать в WebView без Cordova.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий